在传统的web项目中，防止重复提交，通常做法是：后端生成一个唯一的提交令牌（uuid），并存储在服务端。页面提交请求携带这个提交令牌，后端验证并在第一次验证后删除该令牌，保证提交请求的唯一性。

多环境是最常见的配置隔离方式之一，可以根据不同的运行环境提供不同的配置信息来应对不同的业务场景，在SpringBoot内支持了多种配置隔离的方式，可以激活单个或者多个配置文件。

ApiBoot Logging会为每一个请求都对应创建链路编号（TraceID）以及单元编号（SpanID），用于归类每一次请求日志，通过一个链路下日志单元的Parent SpanID可以进行上下级关系的梳理。

通过ApiBoot Logging可以将每一条请求的详细信息获取到，在分布式部署方式中，一个请求可能会经过多个服务，如果是每个服务都独立保存请求日志信息，我们没有办法做到统一的控制，而且还会存在日志数据库与业务数据库不一致的情况出现（可能会用到多数据源配置），正因为这个问题ApiBoot Logging提供了一个Admin的概念，将客户端采集到的的每一条日志都进行上报到Admin，由Admin进行分析、保存等操作。

ApiBoot Logging通过集成minbox-logging来进行管理每一次请求的日志信息，包含头信息、参数、主体内容、路径、发生的服务器相关信息等，根据接口的响应状态还可以记录响应的头信息、响应的内容以及发生异常时的堆栈信息。

最近经常在项目或是社区里听到大家谈论微服务架构，但谈论的焦点更多集中在微服务拆分，分布式架构，微服务门槛，DevOps配套设施等话题上。

但是在我眼里，真正能称之为微服务架构的少之又少。原因也很简单，我所见到的很多所谓的微服务架构项目，大多都没有做到微服务架构的一个基本要求：服务的独立部署（交付）。

在本篇文章中我们在SpringCloud环境下通过使用Seata来模拟用户购买商品时由于用户余额不足导致本次订单提交失败，来验证下在MySQL数据库内事务是否会回滚。

阿里巴巴自从跟SpringCloud共同发起创建微服务开源社区时，开启了SpringCloud Alibaba分支，而且在生态内提供了一款适用于分布式应用程序（Dubbo、SpringCloud等）的事务框架Seata，该框架经过多个大版本的发布，已经支持MySQL、Oracle这两种数据库事务回滚（Rollback）以及提交（Commit）控制，每次发版都会修复一些用户反馈的Issue以及添加一些新特性。