Seata（Simple Extensible Autonomous Transaction Architecture）是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。在 GitHub 上拥有超过 1.4 万 Star，毫无疑问是开源社区分布式事务领域最火爆的项目。

GTS（Global Transaction Service 全局事务服务）是阿里云上的分布事务中间件产品，用于实现分布式环境下特别是微服务架构下的高性能事务一致性。

• 2014 年，阿里巴巴中间件团队发布分布式事务中间件产品 TXC（Taobao Transaction Constructor），为集团内部应用提供服务。
• 2016 年，TXC 经过产品化改造，以 GTS 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。
• 2019 年，阿里巴巴中间件团队基于 TXC 和 GTS 的技术积累，发起了开源项目 Seata（曾用名 Fescar），和社区一起建设这个分布式事务解决方案。开源项目 Seata 的基础是基于 GTS 架构定义的分布式事务框架以及 GTS 独创的的 AT（Automatic Transaction）模式。
• Seata 项目经过近一年的发展，收获包括蚂蚁金服分布式事务领域核心技术合作，以及开源社区的大力投入，加入 TCC 和 Saga 模式支持，于 2019 年底发布 GA 版本。
• 2020 年 2 月，基于 Seata 项目 GA 后的版本，GTS 实现与 Seata 的协议兼容，支持使用 Seata 的应用无缝迁移到云上基于 GTS 提供的服务来高效运行。

简单来讲，Seata 项目 2019 年之初的创建是 GTS 的开源版本，经过一年的演进，GTS 商业版本开始全面提供对 Seata 的支持。

GTS 如何实现对 Seata 的支持

接下来，我们全面解读 GTS 是如何实现对 Seata 的支持的。

Seata 定义的分布式事务框架

首先，看一下 Seata 定义的分布式事务框架。

核心组件定义

Seata 明确定义分布式事务的 3 个核心组件：

• Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
• Transaction Manager (TM)：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
• Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

一个典型的事务过程：

1. TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
2. XID 在微服务调用链路的上下文中传播。
3. RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
4. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
5. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

事务框架和事务模式

基于架构上定义的 3 个角色，Seata 把分布式事务抽象成这样一个 事务框架。

TM 定义全局事务的边界。

RM 负责定义分支事务的边界和行为。

TC 跟 TM 和 RM 交互（开启、提交、回滚全局事务；分支注册、状态上报和分支的提交、回滚），做全局的协调。

所谓 Seata 的 事务模式，是这个框架下，RM 驱动的 分支事务的不同行为模式，应该是 事务（分支）模式。

Seata 定义的事务模式

AT 模式

AT 模式 RM 驱动分支事务的行为：

• 执行阶段：

  • 代理 JDBC 数据源，解析业务 SQL，生成更新前后的镜像数据，形成 UNDO LOG。
  • 向 TC 注册分支。
  • 分支注册成功后，把业务数据的更新和 UNDO LOG 放在同一个本地事务中提交。

• 完成阶段：

  • 全局提交，收到 TC 的分支提交请求，异步删除相应分支的 UNDO LOG。
  • 全局回滚，收到 TC 的分支回滚请求，查询分支对应的 UNDO LOG 记录，生成补偿回滚的 SQL 语句，执行分支回滚并返回结果给 TC。

TCC 模式

TCC 模式 RM 驱动分支事务的行为：

• 执行阶段：

  • 向 TC 注册分支。
  • 执行业务定义的 Try 方法。
  • 向 TC 上报 Try 方法执行情况：成功或失败。

• 完成阶段：

  • 全局提交，收到 TC 的分支提交请求，执行业务定义的 Confirm 方法。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的 Cancel 方法。

Saga 模式

Saga 模式 RM 驱动分支事务的行为：

• 执行阶段：

  • 向 TC 注册分支。
  • 执行业务方法。
  • 向 TC 上报业务方法执行情况：成功或失败。

• 完成阶段：

  • 全局提交，RM 不需要做事情。
  • 全局回滚，收到 TC 的分支回滚请求，执行业务定义的补偿回滚方法。

XA 模式

XA 模式 RM 驱动分支事务的行为：

• 执行阶段：

  • 向 TC 注册分支。
  • XA start，执行业务 SQL，XA end。
  • XA prepare，并向 TC 上报 XA 分支的执行情况：成功或失败。

• 完成阶段：

  • 收到 TC 的分支提交请求，XA commit。
  • 收到 TC 的分支回滚请求，XA rollback。

TC 在 Seata 架构中的重要作用

Seata 架构中的 TM 和 RM 和应用部署在一起，应用根据业务需求，选择合适的分布式事务模式来解决数据一致性问题。

从上述 4 类已经或即将被 Seata 框架支持的分布式事务模式的工作机制可以看到：

无论使用哪处模式，都离不开一个稳定高效的 TC 提供服务。这些服务包括（但不限于）：

• 记录全局事务状态
• 记录事务分支的注册
• 驱动事务分支进行最终的提交或回滚
• 事务链路监控
• 异常事务的恢复
• 全局事务超时检测
• 全局事务间隔离机制

分布式事务的协调机制被 Seata 框架定义为一项标准化的服务。这项服务可以像 ZooKeeper 独立部署运维，给应用的分布式系统提供事务服务。

GTS 带给 Seata 用户的价值

GTS 的架构

Seata 定义的事务协议，如下图所示：

Seata 的分布式事务框架源自 GTS，二者的底层架构和事务协议是完全一致的。

• GTS 把 TM 和 RM 的实现统一打包到 GTS SDK 中。
• GTS 的服务端就是 TC 的一个高可用实现。

GTS 的事务协议，如下图所示：

依托于阿里云的基础设施，GTS Server 以多副本、高可用集群形态部署，提供高质量的事务协调服务。

GTS 作为 Seata 的 TC

架构和协议层面的一致，使得 GTS 可以很自然地提供对 Seata 应用的事务协调支持。

只要实现具体网络通信机制上的兼容适配，就可以完整支撑 Seata 应用运行在 GTS 服务之上。

Seata 应用迁移到云上使用 GTS 服务不需要做任何编程改造，仅仅是把自运维的 Seata 的 TC Server 替换为 GTS 提供的高性能、高可靠、高可用的云服务。

GTS 的价值

GTS 作为云原生分布式事务服务的价值

随着企业的发展，企业业务架构面临数据、服务的分布化，几乎无可避免地要遇到分布式架构带来的数据一致性问题。

GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。

GTS 给业务应用带来的价值体现在以下几个方面：

• 架构复杂度降低：分布式事务这个 切面 的技术问题，全部 收敛 到 GTS 提供的服务来解决。
• 设计和开发成本减轻：业务逻辑的设计和开发，完全不需要针对是否涉及分布式事务而做任何额外的事情，对业务 0 侵入 。
• 项目交付、迭代速度加快：归因于上述两点，项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力，在这个商业机会瞬息万变的时代，显得尤为重要。

设想一个典型的云原生企业应用的成长路径：

• 1.0：单体应用，快速上线，这个时候完全不涉及分布式事务。
• 2.0：单个数据库无法支撑，数据分布到多个数据库，产生分布式事务问题。
• 3.0：微服务化，进一步产生跨服务的分布式事务。
• 4.0：跨应用的整合，成为 SaaS 或 FaaS 的平台，在更大的范围，产生分布式事务问题。

基于 GTS 提供的分布式事务服务，企业发展各阶段产生的不同场景下的数据一致性问题，可以得到一站式的解决。这使得业务可以平滑自然地，像搭积木一样成长起来。

从上面示例可以看到：GTS 实际上是把分布式事务（或者说分布式场景下的数据一致性）能力，作为一种 云原生 的服务，提供给生长在云上的应用，让分布式事务不再成为业务要面临的一个令人头疼的问题，而成为一种可以弹性伸缩，按需取用的服务能力。

GTS 支持 Seata 带来的价值

GTS 提供对开源解决方案 Seata 的兼容支持后，给 GTS 商业用户和 Seata 开源用户之间建立了一座桥梁，给两类用户创造更多价值。

对于既有的和潜在的 GTS 用户：

• 不必担心厂商的 Lock-in，核心技术完全符合开源的开放标准。
• 基于开源的解决方案可以在社区得到更多技术支持。
• 更容易基于开源项目进行 POC 验证，构建开发、测试环境。

对于既有的和潜在的 Seata 用户：

• 基于 Seata 构建的业务系统，可以灵活进行云上或云下部署，代码 0 修改。

• 迁移上云，基于 GTS 提供的服务，可以完全省去运维 Seata TC Server 的成本：

  • 部署 Seata TC Server 所需的机器、网络、数据库等资源成本
  • 运维 Seata TC Server 的人力资源成本
  • 跟进 Seata 版本，升级 Seata TC Server 的研发、测试成本

• 另外，GTS 给 Seata 应用提供更多增值服务能力：

  • 按量付费：不使用不产生任何费用
  • 自动扩容缩容：服务能力的扩容和缩容透明化
  • 监控分析：控制台提供事务数据的统计、监视、异常事务控制、链路分析等企业级功能特性

发展路线图

开源项目 Seata 和商业产品 GTS 正在并行向前演进：

• Seata 正在打造新的分布式事务模式：XA 模式，将在不久的 1.x 版本发布（预计 1.2 或 1.3）。
• GTS 基于开源的 Seata 内核，融合既有的和新的商业特性，打造全新的 3.0 版本。3.0 版本发布后，将支持 Seata 全部事务模式：AT、TCC、Saga 和 XA，实现开源版本和商业版本的融合。
• 版本融合后，GTS 每个版本都的发布都将实现对最新稳定开源版本的兼容支持。

实践

GTS 的 SDK 2.9.0 版本支持基于 Seata 的应用使用 AT 模式，运行在 GTS 服务上。参考样例，点击这里。

另外，基于 GTS 构建微服务分布式事务解决方案的更多实践，请参考阿里云最佳实践的推荐，以及官网。

作者信息：煊檍，GitHub ID：sharajava，阿里巴巴中件间 GTS 研发团队负责人，SEATA 开源项目发起人，曾在 Oracle 北京研发中心多年，从事 WebLogic 核心研发工作。长期专注于中间件，尤其是分布式事务领域的技术实践。