gts
GTS 今年双 11 的成绩
今年 2684 亿的背后，有一个默默支撑，低调到几乎被遗忘的中间件云产品——GTS（全局事务服务，Global Transaction Service），稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。
2019 年 11 月 1 日至 12 日，GTS 日均处理分布式事务数量达 亿级 ，每天峰值 TPS 达 万级 。
这背后最重要意义在于：成绩是在给业务应用的设计和开发带来 0 负担 的前提下得到的。
GTS 带来的价值
随着企业的发展，企业业务架构面临数据、服务的分布化，几乎无可避免地要遇到分布式架构带来的数据一致性问题。
GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。
GTS 给业务应用带来的价值体现在以下几个方面：
架构复杂度降低：分布式事务这个 切面 的技术问题，全部 收敛 到 GTS 提供的服务来解决。
设计和开发成本减轻：业务逻辑的设计和开发，完全不需要针对是否涉及分布式事务而做任何额外的事情，对业务 0 侵入 。
项目交付、迭代速度加快：归因于上述两点，项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力，在这个商业机会瞬息万变的时代，显得尤为重要。
设想一个典型的云原生企业应用的成长路径：
1.0：单体应用，快速上线，这个时候完全不涉及分布式事务。
2.0：单个数据库无法支撑，数据分布到多个数据库，产生分布式事务问题。
3.0：微服务化，进一步产生跨服务的分布式事务。
4.0：跨应用的整合，成为 SaaS 或 FaaS 的平台，在更大的范围，产生分布式事务问题。
基于 GTS 提供的分布式事务服务，企业发展各阶段产生的不同场景下的数据一致性问题，可以得到一站式的解决。这使得业务可以平滑自然地，像搭积木一样成长起来。
从上面示例可以看到：GTS 实际上是把分布式事务（或者说分布式场景下的数据一致性）能力，作为一种 云原生 的服务，提供给生长在云上的应用，让分布式事务不再成为业务要面临的一个令人头疼的问题，而成为一种可以弹性伸缩，按需取用的服务能力。
GTS 的原理和创新
下面，从几个方面来大体介绍 GTS 的原理和创新。
首先，GTS 把分布式事务定义为由若干本地事务（分支）组成的全局事务。被全局事务管理的全部分支，将在协调器的协调下，保证一起成功或一起回滚。
其次，GTS 定义了一个事务模型，把整个全局事务过程模型化为 TM、RM、TC 三个组件之间协作的机制。
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
一个典型的分布式事务过程：
TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
XID 在微服务调用链路的上下文中传播。
RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
TM 向 TC 发起针对 XID 的全局提交或回滚决议。
TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
第三，GTS 创新地基于 SQL 解析实现对业务无侵入的自动补偿回滚机制。这种机制，GTS 将其命名为 Auto Transaction (AT) 模式。基本工作原理如下：
GTS 把全局事务分为两个阶段：执行阶段 和 完成阶段 。
执行阶段：
GTS 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。
这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。
基于这样的机制，分支的本地事务便可以在全局事务的 执行阶段 提交，马上释放本地事务锁定的资源。
完成阶段：
如果 TM 发出的决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），完成阶段 可以非常快速地完成。
如果 TM 发出的决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
最后，GTS 通过事务协调器集群以及对业务应用节点的容错，实现一个拒绝单点故障的高可用服务。
一方面，GTS 服务集群机制，保障任意服务节点宕机，可以其他节点无缝接管。
另一方面，应用任意节点的宕机，相应事务分支的请求也会路由到连接相同数据库的其他节点上，不影响全局事务的完整执行。
分布式事务模式融合及标准化（保护）
截止目前，还没有任何一种分布式事务的技术方案，可以满足所有场景的问题。GTS 的 AT 模式适用于绝大部分常见场景，但仍有一些场景更适合于使用业界其他的分布式事务解决方案。GTS 会把各类解决方案融合到 GTS 提供的云服务框架中，为云原生应用提供一站式的分布式事务服务。
这是 GTS 的抽象出的事务框架。通过这个抽象，分布式事务得以从整体架构中剥离出来，形成一个单独的技术切面，作为服务提供给应用。
简单来说，基于这个框架的应用，其分布式事务问题，就收敛到基于 RM 的分支事务机制和 TC 提供的稳定、可靠的服务中。分而治之，才能更有效地解决问题。
当前分布式应用层面，最具代表性的事务模式有 4 种，分别是 AT、TCC、Saga 和 XA，这些模式各有优缺点和适用的场景。
下面列出 4 种事务模式的优劣，以及在 GTS 的事务框架中的映射。
AT
优势： 业务无侵入；轻量，不依赖数据库的高级特性；回滚较少的场景性能高。
劣势： 隔离性不高，目前只能支持到接近 读已提交 的程度，更高的隔离级别，实现成本将非常高。
TCC
优势： 适用场景广泛；隔离性和性能都可以做极致优化。
劣势： 业务侵入性非常高。
Saga
优势： 长事务。
劣势： 有一定业务侵入性；隔离性差。
XA
优势： 业务无侵入；隔离性好。
劣势： 阻塞协议。
GTS 与开源
为了更好地构建一个云原生的分布式事务标准，2019 年初，GTS 选择了开源，发起了开源项目 SEATA（曾用名 FESCAR）。项目开源不到 1 年时间，收获 STAR 数已经突破 1.2 万，Contributor 超过 120 名，获得社区的广泛关注和认可。
分布式事务一直以来都可以称得上是世界性难题，希望可以通过 SEATA 这个开放的平台，聚集全世界的智慧来给这道难题交上一份让人满意的答卷。
进一步，GTS 将这份答卷转化为阿里云上高效、稳定、可靠的服务，赋能给广大云原生开发者。
总结
GTS 自从 2014 年诞生于阿里巴巴中间件的 5 年来，从支撑集团内第一个业务方开始，经历了从内部到云产品化，从封闭到开源，从单一模式到兼容并蓄和标准化，一直坚定地走在分布式事务领域的最前沿。
GTS 的目标是云原生时代，分布式事务的全面解决方案，任何分布式事务需求，在 GTS 上都能找到满意的答案
摘要： 本文将深入和大家探讨微服务架构下，分布式事务的各种解决方案，并重点为大家解读阿里巴巴提出的分布式事务解决方案—-GTS。该方案中提到的GTS是全新一代解决微服务问题的分布式事务互联网中间件。
原文地址:https://yq.aliyun.com/articles/542020
1 微服务的发展
微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。
2 微服务落地存在的问题
虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面：
1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。
2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
3）微服务数量众多，其测试、部署、监控等都变的更加困难。
随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用。对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。
而对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 为此，本文将深入和大家探讨微服务架构下，分布式事务的各种解决方案，并重点为大家解读阿里巴巴提出的分布式事务解决方案—-GTS。该方案中提到的GTS是全新一代解决微服务问题的分布式事务互联网中间件。
3 传统分布式事务解决方案
3.1 基于XA协议的两阶段提交方案
交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。 第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。
图片描述
两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
3.2 TCC方案
TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理如下图所示。
图片描述
事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。
TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 当然TCC方案也有不足之处，集中表现在以下两个方面：
对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。 上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。
3.3 基于消息的最终一致性方案
消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。
图片描述
消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。
4 GTS–分布式事务解决方案
GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。
更多GTS资料请访问研发团队微博。
4.1 GTS的核心优势
性能超强
GTS通过大量创新，解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。
应用侵入性极低
GTS对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。
完整解决方案
GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。 有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。
容错能力强
GTS解决了XA事务协调器单点问题，实现真正的高可用，可以保证各种异常情况下的严格数据一致。
4.2 GTS的应用场景
GTS可应用在涉及服务调用的多个领域，包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等，详细介绍可以阅读 《GTS–阿里巴巴分布式事务全新解决方案》一文。
4.3 GTS与微服务的集成
GTS包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。GTS Client主要用来界定事务边界，完成事务的发起与结束。GTS RM完成事务分支的创建、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。GTS和微服务集成的结构图如下所示，GTS Client需要和业务应用集成部署，RM与微服务集成部署。
图片描述
4.4 GTS的输出形式
GTS目前有三种输出形式：公有云输出、公网输出、专有云输出。
4.4.1 公有云输出
这种输出形式面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致性。这种使用场景下，业务系统和GTS间的网络环境比较理想，达到很好性能。
图片描述
4.4.2 公网输出
这种输出形式面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务（与公有云输出的差别在于客户端部署于用户本地，而不在云上）。
在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，50个并发就可以轻松实现1000TPS以上分布式事务，对绝大多数业务来说性能是足够的。在公网环境，网络闪断很难完全避免，这种情况下GTS仍能保证服务调用的数据一致性。
图片描述
具体使用样例使用参见4.7节GTS的工程样例。
4.4.3 专有云输出
这种形式主要面向于已建设了自己专有云平台的大用户，GTS可以直接部署到用户的专有云上，为专有云提供分布式事务服务。目前已经有10多个特大型企业的专有云使用GTS解决分布式事务难题，性能与稳定性经过了用户的严格检测。
4.5 GTS的使用方式
GTS对应用的侵入性非常低，使用也很简单。下面以订单存储应用为例说明。订单业务应用通过调用订单服务和库存服务完成订单业务，服务开发框架为Dubbo。
4.5.1 订单业务应用
在业务函数外围使用@TxcTransaction注解即可开启分布式事务。Dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。
@TxcTransaction(timeout = 1000 * 10)
public void Bussiness(OrderService orderService, StockService stockService, String userId) {
//获取事务上下文
String xid = TxcContext.getCurrentXid();
//通过RpcContext将xid传到一个服务端
RpcContext.getContext().setAttachment(“xid”, xid);
//执行自己的业务逻辑
int productId = new Random().nextInt(100);
int productNum = new Random().nextInt(100);
OrderDO orderDO = new OrderDO(userId, productId, productNum, new Timestamp(new Date().getTime()));
orderService.createOrder(orderDO);
//通过RpcContext将xid传到另一个服务端
RpcContext.getContext().setAttachment(“xid”,xid);
stockService.updateStock(orderDO);
}
4.5.2 服务提供者
更新库存方法
public int updateStock(OrderDO orderDO) {
//获取全局事务ID，并绑定到上下文
String xid = RpcContext.getContext().getAttachment(“xid”);
TxcContext.bind(xid,null);
//执行自己的业务逻辑
int ret = jdbcTemplate.update(“update stock set amount = amount - ? where product_id = ?”,new Object[]{orderDO.getNumber(), orderDO.getProductId()});
TxcContext.unbind();
return ret;
}
4.6 GTS的应用情况
GTS目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。
GTS在公有云和专有云输出后，已经有了100多个线上用户，很多用户通过GTS解决SpringCloud、Dubbo、Edas等服务框架的分布式事务问题。业务领域涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致认可。
上图是GTS与SpringCloud集成，应用于某共享出行系统。业务共享出行场景下，通过GTS支撑物联网系统、订单系统、支付系统、运维系统、分析系统等系各统应用的数据一致性，保证海量订单和数千万流水的交易。
4.7 GTS的工程样例
GTS的公有云样例可参考阿里云网站。在公网环境下提供sample-txc-simple和sample-txc-dubbo两个样例工程。
4.7.1 sample-txc-simple样例
4.7.1.1 样例业务逻辑 该样例是GTS的入门sample，案例的业务逻辑是从A账户转账给B账户，其中A和B分别位于两个MySQL数据库中，使用GTS事务保证A和B账户钱的总数始终不变。
4.7.1.2 样例搭建方法 1) 准备数据库环境
安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表（SQL脚本见4.7.3）。在db1库中创建user_money_a表，在db2库中创建user_money_b表。
2) 下载样例
将sample-txc-simple文件下载到本地，样例中已经包含了GTS的SDK。
3) 修改配置
打开sample-txc-simple/src/main/resources目录下的txc-client-context.xml，将数据源的url、username、password修改为实际值。
4) 运行样例
在sample-txc-simple目录下执行build.sh编译本工程。编译完成后执行run.sh。
4.7.2 sample-txc-dubbo 样例
4.7.2.1 样例业务逻辑 本案例模拟了用户下订单、减库存的业务逻辑。客户端（Client）通过调用订单服务（OrderService）创建订单，之后通过调用库存服务（StockService）扣库存。其中订单服务读写订单数据库，库存服务读写库存数据库。由 GTS 保证跨服务事务的一致性。
4.7.2.2 样例搭建方法
1) 准备数据库环境
安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表。在db1库中创建orders表，在db2库中创建stock表。
2) 下载样例
将样例文件sample-txc-dubbo下载到本地机器，样例中已经包含了GTS的SDK。
3) 修改配置
打开sample-txc-dubbo/src/main/resources目录，将dubbo-order-service.xml、dubbo-stock-service.xml两个文件中数据源的url、username、password修改为实际值。
4) 运行样例
编译程序 在工程根目录执行 build.sh 命令，编译工程。编译后会在 sample-txc-dubbo/client/bin 目录下生成 order_run.sh、stock_run.sh、client_run.sh 三个运行脚本对应订单服务、库存服务以及客户端。
运行程序
在根目录执行run.sh，该脚本会依次启动order_run.sh(订单服务)、stock_run.sh(库存服务)和client_run.sh(客户端程序)。
4.7.2.3 其他说明
样例使用Multicast注册中心的声明方式。如果本机使用无线网络，dubbo服务在绑定地址时有可能获取ipv6地址，可以通过jvm启动参数禁用。 方法是配置jvm启动参数 -Djava.net.preferIPv4Stack=true。
4.7.3 SQL
4.7.3.1 建表 txc_undo_log
CREATE TABLE txc_undo_log (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
gmt_create datetime NOT NULL COMMENT ‘创建时间’,
gmt_modified datetime NOT NULL COMMENT ‘修改时间’,
xid varchar(100) NOT NULL COMMENT ‘全局事务ID’,
branch_id bigint(20) NOT NULL COMMENT ‘分支事务ID’,
rollback_info longblob NOT NULL COMMENT ‘LOG’,
status int(11) NOT NULL COMMENT ‘状态’,
server varchar(32) NOT NULL COMMENT ‘分支所在DB IP’,
PRIMARY KEY (id),
KEY unionkey (xid,branch_id)
) ENGINE=InnoDB AUTO_INCREMENT=211225994 DEFAULT CHARSET=utf8 COMMENT=’事务日志表’;
4.7.3.2 建表 user_money_a
CREATE TABLE user_money_a (
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.3 建表 user_money_b
CREATE TABLE user_money_b (
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.4 建表 orders
CREATE TABLE orders (
id bigint(20) NOT NULL AUTO_INCREMENT,
user_id varchar(255) NOT NULL,
product_id int(11) NOT NULL,
number int(11) NOT NULL,
gmt_create timestamp NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM AUTO_INCREMENT=351 DEFAULT CHARSET=utf8
4.7.3.5 建表 stock
CREATE TABLE stock (
product_id int(11) NOT NULL,
price float NOT NULL,
amount int(11) NOT NULL,
PRIMARY KEY (product_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
5 总结
GTS已经在阿里内部广泛使用，经过了双十一流量高峰的考验。内部成熟后，在专有云和公有云服务了很多用户，很多用户一天事务量在千万/亿级别，解决了业务服务化改造后的分布式事务棘手技术难题。
在整个世界范围内，既满足事务ACID特性，又具备高性能、高可用、业务侵入性低的分布式事务中间件在GTS前是不存在的。让我们一起体验GTS带来的巨大变革吧！
