分布式事务解决方案--GTS（一）

1. 杂谈

由于目前公司项目是单体架构，服务之间耦合严重，发布个活动都需要发布主应用，对线上服务的稳定性造成了一定影响，最近公司就开始做微服务化的拆分，而且又不能停止现有功能的迭代开发，所以就一边开发新功能，一边拆分服务。

2. 问题

小公司果然在实现微服务的道路上步步维艰，虽然微服务现在如火如荼，但行业上对其实践其实仍处于探索阶段，基础设施不够完善。

主要问题包括：

• 单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂（dubbo，spirng cloud能框架基本已经解决）。
• 系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
• 微服务数量众多，其测试、部署、监控等都变的更加困难（docker，devops基本已经解决）。

3. 传统方案

目前解决分布式事务比较常见的方案是XA，TCC和消息。但它们都各有缺点。

• XA：两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
• TCC:业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。
• 消息：消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高（但相对XA和TCC改动最小）。

就传统的分布式事务解决方案来分析，消息的方案应该是最适合微服务的，锁定时间最小，最终一致性的实现对于互联网应用来说一般都是能接受的。但有没有更优雅的方案呢，如果你的服务刚好是部署在阿里云上的，那么恭喜你了，可以在改动最小的情况下，接入GTS，那么GTS是什么呢？

4. GTS--分布式事务解决方案

GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。相对于传统分布式事务解决方案，GTS有如下优势（微服务架构下分布式事务解决方案 —— 阿里GTS）（这些特性其实是每个设计中间件的开发人员都需要考虑和兼顾的方面）：

• 性能超强

GTS解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。

• 应用侵入性极低

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

• 完整解决方案

GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。

有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。

• 容错能力强

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

对于GTS的介绍就到这里，下一篇将讲GTS的使用方式。