应用服务器的分布式事务支持
我们先看一下分布式事务的需求是如何产生的，以及应用服务器是如何支持分布式事务管理的。
- 单体应用
首先看单体应用，所有的模块部署在一个应用服务器上，业务数据都保存在单个数据库中，这种场景本地事务就可以满足需求。
- 数据库水平拆分
如果数据库按照业务模块进行水平拆分，完成一个业务请求会涉及到跨库的资源访问和更新，这时候就需要使用应用服务器的JTA进行两阶段提交，保证跨库操作的事务完整性。
- 应用模块拆分
应用按照业务模块进一步拆分，每一个模块都作为EJB，部署在独立的应用服务器中。完成一个业务请求会跨越多个应用服务器节点和资源，如何在这种场景保证业务操作的事务呢？当访问入口EJB时JTA会自动开启全局事务，事务上下文随着EJB的远程调用在应用服务器之间传播，让被调用的EJB也加入到全局事务中。
这就是应用因拆分而遇到分布式事务的问题，以及应用服务器是如何解决这个问题的。
分布式事务中间件
微服务时代，没人再使用沉重的EJB，都是将Spring Bean直接暴露为远程服务。完成一个业务请求需要跨越多个微服务，同样需要面对分布式事务的问题。这时就需要引入分布式事务中间件。我们以蚂蚁金服开源的Seata为例，看看它是怎么解决微服务场景下的分布式事务问题。
将上一小节跑在应用服务器上的业务，使用微服务 Seata的重构后，部署架构如下：
上图中黄色方框（RM，TM，TC）是Seata的核心组件，它们配合完成对微服务的分布式事务支持。可以看出，和应用服务器的EJB方案架构上类似，只是多了一个独立运行的TC组件。
我们再看看Seata各组件的具体作用。
Seata的架构
Seata由三个组件构成：
- Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
- Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
- Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
Seata vs. 应用服务器
Seata和应用服务器的分布式事务支持主要有以下四个差异：
Seata和应用服务器都可以实现业务无侵入分布式事务支持。但应用服务器的XA方案实现的是实时一致性，而Seata的AT 模式实现的是最终一致性。Seata引入了独立运行的Transaction Coordinator，维护全局事务的运行状态。而应用服务器的访问入口节点承担了维护全局事务状态的职责。Seata自己实现了Resource Manager，不需要依赖数据库的XA driver。这样就有可能将没有实现XA接口的资源加入的分布式事务中，例如NoSQL。同时，RM的实现要比JTA中的XAResource复杂很多。RM需要拦截并解析SQL，生成回滚语句，在事务rollback时自动进行数据还原。XAResource是对XA driver的包装，资源参与分布式事务的能力，都是由数据库提供的。- 事务上下文的传播机制不同。应用服务器使用标准的
RMI-IIOP协议进行事务上下文的跨节点传播。Seata是对各种RPC框架提供了插件，拦截请求和响应，事务上下文随着RPC调用进行跨节点传播。目前Seata已经支持了dubbo、gRPC、Motan和sofa-rpc等多种RPC框架。
Seata和应用服务器都支持在分布式场景下的全局事务，都可以做到对业务无侵入。Seata实现的是最终一致性，因此性能比应用服务器的XA方案好很多，具备海量并发处理能力，这也是互联网公司选择它的原因。由于Seata不依赖数据库的XA driver，只使用数据库的本地事务，就完成了对分布式事务的支持，相当于承担了部分数据库的职责，因此Seata的实现难度要比应用服务器的JTA大。
应用服务器进入微服务时代
那么应用服务器的分布式事务支持在微服务时代还有用吗？或者说我们应该怎样改进，才能让应用服务器进入微服务时代？
首先我们要看到JTA/XA的优势：支持数据的实时一致性，对业务开发更加友好。客户对原有的系统进行微服务改造时，如果把业务模型假定成数据最终一致性，客户就不得不做出很大的妥协和变更。特别是有些金融客户对一致性的要求会比较高。
我们可以学习Seata的架构，抛弃掉沉重的EJB/RMI-IIOP，让Spring Bean通过dubbo等RPC框架直接对外暴露服务，同时事务上下文可以在RPC调用时进行传递：
我们甚至可以将JTA独立出来，和Tomcat这样的Web容器整合，为微服务架构提供分布式事务支持。相信通过这样的改造，应用服务器的分布式事务能力在微服务时代又能焕发第二春。
