分布式事务

一、微服务的发展
微服务倡导将复杂的单体应用拆分成若干个功能简单、松耦合的服务，这样可以降低开发难度、增强可扩展性，便于敏捷开发。也被越来越多的开发者所推崇，很多大型的互联网公司都开始进行微服务的实践。微服务框架有很多，比较著名的有dubbo、spring cloud等。

二、微服务落地存在的问题
虽然微服务通过将复杂的单体应用拆分成多个功能简单、松耦合的服务，从而降低开发难度、增强可扩展性等，但是也存如下问题：
1.单体应用拆分成分布式系统之后，各服务间的通信以及故障处理措施变的更加复杂。
2.系统微服务化后，一个看似简单的功能，内部可能需要调用多个微服务并操作多个数据库，所以服务调用的分布式事务问题变的非常棘手。
3.服务数量众多，部署、监控等操作变的更加复杂。

随着分布式框架的逐渐成熟，第一个问题已经逐渐解决。(服务间通信：dubbo可以支持多种通信协议，而spring cloud可以很好的支持restful调用，提供了ribbon负载均衡组件以及feign基于接口形式的服务调用。
故障处理：spring cloud提供spring cloud hystrix服务熔断、服务降级、依赖隔离、监控等多种服务容错机制。)对于第三个问题，随着docker、devops技术的发展以及自动化部署工具的成熟，微服务的测试、部署、运维正变的容易起来。但是对于第二个问题(分布式事务)，一直没有一个成熟的通用的解决方案。

三、分布式事务解决方案
1.基于XA协议的两阶段提交方案

如图所示，基于XA协议的两阶段提交方案是将事务划分成两个阶段提交，并添加了事务协调器从而保证多个数据源事务的ACID原则。
第一阶段是表决阶段。事务协调器通知所有参与该事务的资源管理器开始准备事务，资源管理器在接收到通知后开始准备阶段，写好事务日志并执行事务，并没有提交，然后将是否就绪的消息返回给事务协调器。
第二阶段是执行阶段。事务协调器根据资源管理器返回的消息进行分析，然后发出事务提交或者回滚的命令，资源管理器接收到命令后进行相应的操作并返回结果给事务协调器，事务协调器接受消息后，事务结束应用程序继续执行。

两阶段提交方案应用非常广泛，几乎所有的数据库都支持XA协议，但是这种方案对资源锁定的时间太长(因为事务协调器和资源管理器之间有好多通信)，对性能影响很大，所以几乎不适合解决分布式事务问题。

2.TCC方案

如图所示，TCC方案是对两阶段提交的一种改进。其将整个业务逻辑的每个分支(即调用的每个微服务)显示的分成try、confirm、cancel三个操作。try部分完成事务的准备工作，confirm部分完成事务的提交，cancel部分完成事务的回滚。事务开始的时候，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成第一阶段准备。之后事务协调器会根据try接口返回的情况决定调用confirm接口或cancel接口。如果接口调用失败会进行重试。

TCC方案让应用自己定义数据库操作的粒度,使得降低锁冲突，提高吞吐量成为可能。但是也有不足之处，主要体现在一下两方面：
1.对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本比较高。
2.实现难度大。需要根据网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足事务一致性的要求，confirm和cancel接口必须实现幂等。

3.基于消息的最终一致性方案
由于基于消息的最终一致性方案中考虑的问题比较多，实现起来比较复杂方案也很多，所以此处给出参考链接，等后续有时间了再补充上来。
基于消息的最终一致性方案参考链接
4.基于state的分布式事务解决方案
添加链接描述
5.GTS(Global Transaction Service)-阿里分布式事务解决方案
GTS是一款分布式事务中间件，由阿里中间件部门研发，可以为分布式架构中的分布式事务提供一站式解决方案。
(1)GTS的优势
性能超强
GTS通过大量创新，解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。

应用侵入性极低
GTS对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。

完整解决方案
GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。 有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。

容错能力强
GTS解决了XA事务协调器单点问题，实现真正的高可用，可以保证各种异常情况下的严格数据一致。

(2)GTS与微服务的集成

如图所示，GTS包括客户端(GTS Client)、资源管理器(GTS RM)、事务协调器(GTS Server)三部分。客户端和业务应用集成部署，主要用于界定事务的边界，完成事务的发起与结束。资源管理器和各个微服务集成部署，完成事务分支的创建、提交、回滚等操作。事务协调器主要负责分布式事务的整体推进，事务声明周期的管理。

(3)GTS的输出形式
公有云输出：这种输出形式面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致性。这种使用场景下，业务系统和GTS间的网络环境比较理想，达到很好性能。

公网输出：这种输出形式面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务（与公有云输出的差别在于客户端部署于用户本地，而不在云上）。在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，50个并发就可以轻松实现1000TPS以上分布式事务，对绝大多数业务来说性能是足够的。在公网环境，网络闪断很难完全避免，这种情况下GTS仍能保证服务调用的数据一致性。

专有云输出：这种形式主要面向于已建设了自己专有云平台的大用户，GTS可以直接部署到用户的专有云上，为专有云提供分布式事务服务。目前已经有10多个特大型企业的专有云使用GTS解决分布式事务难题，性能与稳定性经过了用户的严格检测。

(4)GTS的使用方式
以订单业务伪列。订单业务需要调用订单服务和库存服务完成下订单的业务操作。

订单业务应用：在订单业务方法的上面只需要添加@TxcTrancation注解即可开启分布式事务，然后在业务应用的方法中通过隐藏参数将GTS的事务xid传递到你要调用的微服务端

库存服务：获取业务应用传递过来的xid并绑定到上下文中，然后执行自己的业务逻辑，最后上下文再取消绑定xid

库存服务：和库存服务一样。