虽然微服务现在如火如荼，但对其实践其实仍处于初级阶段。即使互联网巨头的实践也大多是试验层面，鲜有核心业务系统微服务化的案例。GTS是目前业界第一款，也是唯一的一款通用的解决微服务分布式事务问题的中间件，而且可以保证数据的强一致性。本文将对GTS做出深入解读。

微服务倡导将复杂的单体应用拆分为若干个功能简单的、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。概念2012年提出迅速火遍全球，被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。根据Netflix云架构总监Adrian Cockcrof，Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58等很多互联网公司都进行了微服务化改造。当前微服务的开发框架也有几十种之多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。

1 分布式事务解决方案及其弊端

虽然微服务现在如火如荼，但对其实践其实仍处于初级阶段。即使互联网巨头的实践也大多是试验层面，鲜有核心业务系统微服务化的案例。而对于很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地更加困难。世界著名的软件架构大师Chris Richardson在《Introduction to Microservices》一文中也直接了当的指出了微服务当前存在的问题：

• 从单体应用拆分为分布式系统带来的复杂性。开发者需要选择或实现基于消息或者RPC模式的进程间通讯机制，另外开发者也要写额外的代码去处理对于目的服务请求可能存在的请求缓慢或者请求不可用导致的局部故障问题。
• 单体应用拆分所导致的数据库架构的拆分。应用更新多个业务记录非常常见，单体应用实现也比较简单。然而在微服务架构下，应用不得不调用多个微服务去更新多个数据库。一般很难使用分布式事务解决，不仅仅是因为CAP理论，还因为一些流行的NoSQL数据库和Message Queue系统压根也不支持（摊手）。最后还得绕回最终一致性方案，这个方案对开发者来讲也是非常有挑战性。
• 测试微服务架构的应用也是更加复杂的。因为服务之间可能有诸多调用，测试一个服务将不得不启动其他服务。
• 部署、运维一个微服务架构的应用变的更加困难。微服务一般由大量的服务组成，每个服务还有多个运行实例！将会有更多变化的部分需要去配置、部署、扩展、监控。此外还需要实现一个服务发现机制让其他服务找到它需要通信的服务的地址。

对于第一和第三个问题，笔者认为随着RPC框架的成熟，已经逐渐得到解决。例如dubbo可以支持rmi、hessian、http、webservice、thrift、redis等多种通讯协议，springcloud可以非常好的支持restful调用。spring体系下应用的测试也变的越来越简单。对于第四个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的部署与运维会变得越来越容易。

而对于Chris Richardson提到的第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 为此，本文将深入和大家探讨微服务架构下，分布式事务的各种解决方案，并重点为大家解读阿里巴巴提出的分布式事务解决方案----GTS。该方案中提到的GTS是目前业界第一款，也是唯一的一款通用的解决微服务分布式事务问题的中间件，而且可以保证数据的强一致性。

2 SOA分布式事务解决方案

在微服务之前，信息系统中的服务大多基于SOA的理念设计（SOA与微服务的区别），服务相对比较重。对于服务调用产生的分布式事务问题，在SOA时代，就有一些解决方案。比较著名的有基于XA协议的方案、TCC方案、消息最终一致性方案。

2.1基于XA协议的方案

该方案最早由oracle提出用于解决跨数据访问的事务问题，是一种强一致性的解决方案，由事务协调器和本地资源管理器共同完成。事务协调器和资源管理器间通过XA协议进行通信。XA协议实现的原理入下图所示，共分为两个阶段，也就是我们常说的两阶段协议。

两阶段方案在解决数据库分布式事务问题方面应用非常广泛，oracle、Mysql等主流关系数据库均支持XA协议，而且ocenbase、DCDB等著名的分布式数据库也都基于两阶段协议。在解决服务事务问题上，其实 XA协议不是只能作用于单个服务内部的多资源场景，跨服务的多资源场景也是可以的，只不过需要额外的事务传递机制。但其都有致命的缺点，性能不理想。由于需要等到各分支事务都就绪后全局事务才开始提交，所以每个事务锁定数据的时间较长，XA方案因此很难满足高并发场景。而且在解决微服务问题时XA方案的性能问题将会被放大。因为应用在访问服务的调用方式、网络环境等要比访问数据库复杂的多。例如，应用和其访问的数据库通常在一个局域网中，而其通过rpc调用的服务则可能属于另一个网络或者在公网上，其时延更长、出故障的概率更高。这将导致数据锁定时间和系统并发度进一步降低。所以XA方案基本不适合解决微服务的事务问题。

2.2TCC方案

TCC方案应用是目前呼声最高，也是落地最多的一个方案。当前也有一些开源的TCC框架实现，如TCC-Transaction、ByteTCC。TCC方案其实是两阶段方案的一种改进，其将本地资源管理器的功能融入到了业务实现中。其将整个业务逻辑显示的分成了Try、Confirm、Cancel三部分。try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理如下图所示。

事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，相当于XA的第一阶段。如果有任何一个服务的try接口调用失败会向事务协调器发送事务回滚请求，否则发送事务提交请求。事务协调器收到事务回滚请求后会依次调用事务的confirm接口，否则调用cancel接口回滚，这相当于XA的第二阶段。如果第二阶段接口调用失败，会进行重试。

TCC方案通过通过三个接口很好的规避了长时间数据加锁的问题，业务表在每个接口调用完毕即可释放，这很大程度上提高了业务的并发度，这也是TCC方案最大的优势。所以在SOA时期，TCC方案被很多金融、电商的业务系统大量使用。
当然TCC方案也有不足之处，集中表现在以下两个方面：

• 开发工作量大。它将部分资源管理器的功能融入到每个服务的开发中，导致服务的每个接口都需要实现try、confirm、cancle，还需要实现事务协调器，开发量不只翻了一倍。
• 实现难度大。系统需要记录每个应用的服务调用链路。我前面讲过rpc调用情况比较复杂，由于网络状况、系统故障等调用失败被视为常态，必须按照不同的失败原因实现不同策略的回滚。为了满足一致性的要求，二阶段不管调用confirm还是cancle都必须调用成功，如果一次调用不成功，事务协调器必须尝试重试。这就要求confirm和cancle接口必须实现幂等。

上述原因导致TCC方案大多是被研发实力较强、有迫切需求的大公司所采用。其将分布式事务变成一种所谓的“贵族技术”，中小型企业由于人员有限、技术实力薄弱，很难落地。而且笔者认为微服务倡导的是服务的轻量化、易部署，而TCC方案将很多事务的处理功能融入到业务中，对业务侵入性太高，导致服务逻辑复杂，比较适合比较重的服务。

2.3 消息事务一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。
以下单业务为例进行说明，下单基本流程是先存储订单信息，然后扣相应商品的库存，两个操作必须在一个事务中。如下图，业务应用首先调用订单服务，订单存储成功后，订单服务会通过消息处理服务投递订单消息到MQ。库存服务从MQ收到消息后进行扣库存操作，如果执行成功会向消息处理服务发送通知。消息处理服务会实时监测订单消息是否超时，如果超时会重新投递到MQ中，以驱动库存服务进行扣库存操作。如果扣库存操作执行失败后，库存服务后续还会从MQ接收到相同的订单消息，需要多次重复执行，直到成功或者进行人工干预。库存服务需要实现幂等。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。相对TCC方案来讲，消息方案技术难度相对低，落地较容易,如果对一致性不敏感的应用也是一个不错的选择。美国著名电商e-bay以及国内的蘑菇街都做过尝试。消息一致性方案的不足之处是其对应用侵入性较高，应用需要基于消息接口进行改造，而且需要建设专门的消息系统，成本较高。

3 GTS--微服务分布式事务解决方案

GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。GTS方案的基本思路是：将分布式事务与具体业务分离，在平台层面开发通用的事务中间件GTS，由事务中间件协调各服务的调用一致性，负责分布式事务的生命周期管理、服务调用失败的自动回滚。

GTS方案有三方面的优势，首先它将微服务从分布式事务中解放出来，微服务的实现不需要再考虑反向接口、幂等、回滚策略等复杂问题，只需要业务自己的接口即可，大大降低了微服务开发的难度与工作量。将分布式事务从所谓的“贵族技术”变为大家都能使用的“平民技术 ”，有利于微服务的落地与推广。 其次，GTS对业务代码几乎没有侵入，只需要通过注解@TxcTransaction界定事务边界即可，微服务接入GTS的成本非常低。第三，性能方面GTS也非常优秀，是传统XA方案的8～10倍。

3.1 基本原理

GTS中间件主要包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三部分。GTS Client主要完成事务的发起与结束。GTS RM完成分支事务的开启、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。

GTS和微服务集成后的结构图如上图所示。GTS Client需要和业务应用集成部署，RM与微服务集成部署。当业务应用发起服务调用时，首先会通过GTS Client向TC注册新的全局事务。之后GTS Server会给业务应用返回全局唯一的事务编号xid。业务应用调用服务时会将xid传播到服务端。微服务在执行数据库操作时会通过GTS RM向GTS Server注册分支事务，并完成分支事务的提交。如果A、B、C三个服务均调用成功，GTS Client会通知GTS Server结束事务。假设C调用失败，GTS Client会要求GTS Server发起全局回滚。然后由各自的RM完成回滚工作。

3.2 GTS的关键机制

• 可用性
  GTS服务也是由多个节点构成的高可用集群，可以弹性扩张，可以接收高并发的客户端请求。可以支持跨机房部署，支持同城容灾和两地三中心容灾。任何异常情况下的保证高可用。
• 自动回滚策略
  当有微服务调用失败时，GTS服务可以驱动各微服务的RM替微服务完成调用的回滚工作。举个转账的例子，转账应用通常调用存款服务和扣款服务完成转账功能。先调用扣款服务从A账户扣掉100元，然后调用存款服务向B账户中存款100元。如果转账应用在调用存款服务失败时，GTS Client会要求GTS Server发起回滚，然后通知扣款服务对应的RM，RM会直接在A账户增加100元。然后GTS Server通知转账应用回滚成功。从这个过程可以看到，在调用服务失败后，其实微服务不用做任何工作，而是由RM替微服务执行反向操作，也很自然的避免了幂等操作。TCC方案中，事务协调器需要显示调用微服务的反向向接口，如果反向接口调用失败还需要不断重试。
• 可扩展性
  有些情况下，应用需要调用第三方系统的接口或者不是基于GTS开发的微服，GTS无法接入到这些服务的实现中。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式。

MT模式预留了一阶段和二阶段的提交接口，允许应用介入GTS的两阶段提交。应用将提交及回滚接口注册后，GTS会自动完成调用。

• 隔离级别
  GTS目前支持读未提交和读已提交两种隔离级别。

3.3 GTS与其他方案的对比

1. 和XA方案对比

相比XA方案，GTS更加通用，可以对上层业务屏蔽底层实现细节，对业务几乎没有侵入。这一点在微服务时代特别有用，微服务面对的是大量的中小企业，甚至是个人开发者，业务诉求不尽相同，普适、标准的分布式事务产品是非常有必要的，可以让开发者从底层技术细节中脱离出来，更专注于业务逻辑的实现，从而获得更高效、快速的业务发展。两个方案都可以遵循ACID特性，都可以实现事务的强一致性。GTS性能要比XA方案高。

2. 和TCC方案对比

GTS方案和TCC方案最大的区别是实现分布式事务实现的层面不同。TCC方案选择从业务层面实现分布式事务功能，将事务的回滚、重试等功能在微服务中实现。而GTS选择从中间件层面解决分布式事务问题，对微服务几乎无侵入。两个方案都可以获得比较好的性能，都可以保证调用的一致性。TCC方案实现难度比较大，适合技术实力较强的团队。GTS方案可以实现事务的强一致性，另外采用GTS方案后微服务会更简单，耦合性也非常低。TCC主要提供开发框架，实现需要依赖业务方，而GTS是完整的分布式事务解决方案，所有分布式事务问题不需要业务方介入。

3. 和消息最终一致性对比

相比消息方案，GTS方案侵入性非常低，可以实现数据的强一致性。采用消息方案，上下游服务之间有很强的耦合性，测试、部署都不是很方便，需要单独建设消息系统。不过消息方案实现相对简单，如果对一致性要求不高，也是一个选择。

3.4 GTS的应用场景

GTS可应用在涉及服务调用的多个领域，包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等，详细介绍可以阅读 《GTS--阿里巴巴分布式事务全新解决方案》一文。

3.5 GTS的输出形式

GTS目前有三种输出形式：通过公有云平台输出、通过公网云服务输出、通过专有云平台输出。

• 1 通过公有云平台输出

这种输出形式主要面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以直接申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致行。这种使用场景下，业务系统和GTS间的网络环境比较理想，GTS能提供更低的响应时间。

公有云提供了比较丰富的与dubbo、SpringCloud等集成的样例，可以点击查看。

• 2 通过公网云服务输出

这种输出形式主要面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务。在网络抖动和闪断的情况下，GTS仍能保证服务调用的一致性。在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，业务可以轻松实现1000TPS以上分布式事务，可以满足绝大多数业务系统的需要。也可以用于本地的开发和测试 。

现在提供了sample-txc-simple和sample-txc-sample两个样例，sample-txc-simple是GTS的入门的基础样例，点击下载后，搭建好本地的数据库环境就可以直接运行样例。sample-txc-dubbo是GTS和dubbo框架集成的样例，也可以直接在本地机器运行。

• 3 通过专有云平台输出

这种形式主要面向于已建设了自己专有云平台的大用户，GTS可以直接部署到用户的专有云平台上，为专有云提供分布式事务服务。目前国家电网公司、中国邮政、浙江烟草等特大型企业的专有云都使用GTS，保证数据一致性。

3.6 GTS的使用方式

GTS对应用的侵入性非常低，使用也非常简单。下面以订单存储应用为例说明。订单业务应用通过调用订单服务和库存服务完成订单业务，服务开发框架为dubbo。

1 订单业务应用

在业务函数外围使用@TxcTransaction注解即可开启分布式事务。dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。

@TxcTransaction(timeout = 1000 * 10)
public void Bussiness(OrderServiceInterface os,StockServiceInterface ss)
{
//获取xid
String xid = TxcContext.getCurrentXid();
//1：调用订单服务，创建订单
//通过dubbo的隐形参数将txcid传到服务端
RpcContext.getContext().setAttachment("xid",xid);
int ret = os.setOrder(new Order(pid,num,new Date()));//调用订单服务
//2：调用库存服务，扣库存
RpcContext.getContext().setAttachment("xid",xid);
}复制代码

2 服务端使用方式

库存服务

public int setStock(Stock sk) {
//通过dubbo上下文获取xid
String xid = RpcContext.getContext().getAttachment("xid");
//将事务id绑定到服务端txc的上下文
TxcContext.bind(xid,null);
//执行扣库存操作
ret  = jdbcTemplate2.update("update stock set number = number -? where pid = ?",new Object[]{sk.getPnum(),sk.getPid()});
return ret;
}复制代码

3.7 GTS的应用情况

GTS在满足事务ACID的前提下，普通配置的单服务器可以达到15000 TPS以上的超强性能（两个小时完成1亿多笔业务）。目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。GTS在阿里云及专有云上输出后，有很多用户通过GTS解决SpringCloud、Dubbo、Edas等微服务的分布式事务问题，包括国家电网、中国邮政、中国烟草、特步、浙江公安、德邦快递、一步共享科技等，涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致认可。

上图是GTS与SpringCloud集成，应用于某共享出行系统。业务共享出行场景下，通过GTS支撑物联网系统、订单系统、支付系统、运维系统、分析系统等系各统应用事务一致性，保证海量订单和数千万流水的交易。

原文链接