摘要：分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。对于服务调用产生的分布式事务问题，在时代，就有一些解决方案。而选择从中间件层面解决分布式事务问题，对微服务几乎无侵入。
摘要： 虽然微服务现在如火如荼，但对其实践其实仍处于初级阶段。即使互联网巨头的实践也大多是试验层面，鲜有核心业务系统微服务化的案例。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部分完成事务的回滚。基本原理如下图所示。
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与其他方案的对比
和XA方案对比
相比XA方案，GTS更加通用，可以对上层业务屏蔽底层实现细节，对业务几乎没有侵入。这一点在微服务时代特别有用，微服务面对的是大量的中小企业，甚至是个人开发者，业务诉求不尽相同，普适、标准的分布式事务产品是非常有必要的，可以让开发者从底层技术细节中脱离出来，更专注于业务逻辑的实现，从而获得更高效、快速的业务发展。两个方案都可以遵循ACID特性，都可以实现事务的强一致性。GTS性能要比XA方案高。
和TCC方案对比
GTS方案和TCC方案最大的区别是实现分布式事务实现的层面不同。TCC方案选择从业务层面实现分布式事务功能，将事务的回滚、重试等功能在微服务中实现。而GTS选择从中间件层面解决分布式事务问题，对微服务几乎无侵入。两个方案都可以获得比较好的性能，都可以保证调用的一致性。TCC方案实现难度比较大，适合技术实力较强的团队。GTS方案可以实现事务的强一致性，另外采用GTS方案后微服务会更简单，耦合性也非常低。TCC主要提供开发框架，实现需要依赖业务方，而GTS是完整的分布式事务解决方案，所有分布式事务问题不需要业务方介入。
和消息最终一致性对比
相比消息方案，GTS方案侵入性非常低，可以实现数据的强一致性。采用消息方案，上下游服务之间有很强的耦合性，测试、部署都不是很方便，需要多带带建设消息系统。不过消息方案实现相对简单，如果对一致性要求不高，也是一个选择。
3.4 GTS的应用场景
GTS可应用在涉及服务调用的多个领域，包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等，详细介绍可以阅读 《GTS--阿里巴巴分布式事务全新解决方案》一文。
3.5 GTS的输出形式
GTS目前有三种输出形式：通过公有云平台输出、通过公网云服务输出、通过专有云平台输出。
1 通过公有云平台输出
这种输出形式主要面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以直接申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致行。这种使用场景下，业务系统和GTS间的网络环境比较理想，GTS能提供更低的响应时间。
公有云提供了比较丰富的与dubbo、SpringCloud等集成的样例，可以点击查看。
2 通过公网云服务输出
这种输出形式主要面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务。在网络抖动和闪断的情况下，GTS仍能保证服务调用的一致性。在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，业务可以轻松实现1000TPS以上分布式事务，可以满足绝大多数业务系统的需要。也可以用于本地的开发和测试 。