蚂蚁集团境外站点 Seata 实践与探索

PART. 1

背景

蚂蚁国际境外银行业务正在部分迁移至阿里云，原内部使用的 SOFA 技术栈无法在阿里云上得到支持。为了满足银行业务快速发展、简化银行系统技术栈的目标，我们采用了 Spring+Dubbo 等一套开源的技术方案重新构建起了新的技术栈。蚂蚁集团作为金融机构，内部应用采用了微服务架构，数据间的一致性极其重要，但蚂蚁内部原有的分布式事务框架，在阿里云上也无法提供技术支持。

Seata 是分布式事务解决方案，囊括了阿里集团的 TXC（阿里云版本称为 GTS）和蚂蚁集团的 TCC/SAGA 等多种模式，是一款经过多年双十一大规模流量验证的金融级分布式事务框架。因此在综合比较各个现有的分布式事务框架之后，我们选择了 Seata。

本文介绍了蚂蚁集团境外银行技术部在国际站点建设过程中，使用开源的 Seata 1.4.2 版本进行分布式事务管理的详细方案。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情形的处理方法。

PART. 2

调研

Seata 经过四年建设后，已经形成了一个非常庞大的技术体系。但不管其如何演进，Seata 整体保持了架构的稳定性与使用接口的向后兼容性。

Seata 官网给出了其如下架构图：

总体由如下角色构成：

●TC: Transaction Coordinator

事务协调器：维护全局事务和分支事务的状态，驱动全局事务提交或者回滚。

●TM: Transaction Manager

事务管理器：定义全局事务的范围，提交或者回滚全局事务。

●RM：Resource Manager

资源管理器：和分支事务在同一个应用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。

TC 与 TM 以及各个 RM 之间使用 netty 框架进行长链接通信，通信协议是在四层 TCP 协议之上自定义的一套二进制双向通信协议，所以 Seata 总体的通信效率非常高。

Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：

参与者需要实现 Try/Confirm/Cancel 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑完成两阶段的提交。优点是通过业务逻辑实现数据可见性和隔离性，快速释放本地事务，提高对同一个资源的并发度，缺点是引入了中间数据的预处理过程，增加了业务复杂度。因此 TCC 模式具有很好的性能与隔离性，尤其适合在银行金融场景下同一个账户的并发交易处理。

在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来恢复记录到一阶段之前的状态。类似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架自动生成，自动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因此对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发使用同一个资源的场景，则 AT 模式可以很好的兼顾性能和隔离性，以及更好的开发效率。

是一种长事务解决方案，其一阶段正向服务和二阶段补偿服务都由业务开发实现，它在微服�