微服务下分布式事务解决方案

摘抄并学习

 

1. 微服务的发展

　　微服务倡导将复杂的单体应用拆分成若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性。便于敏捷开发。当前微服务的开发框架非常多，比较著名的有 Dubbo、SpringCloud、thrift、grpc 等。

 

2. 微服务落地存在的问题

　　虽然现在微服务如火如荼，但对其实践仍处于探索阶段。很多中小型互联网公司鉴于经验技术实力等问题，微服务落地比较困难。主要有以下几个方面：

　　1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变得更加复杂。

　　2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题非常突出。

　　3）微服务数量众多，其测试、部署、监控等都变得更加困难

 

　　随着 RPC（远程过程调用 Remote Procedure Call） 框架的成熟，第一个问题已经逐渐得到解决。例如 dubbo 可以支持多种通讯协议，springcloud 可以非常好的支持 restful 调用。对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。

　　以下介绍分布式事务的各种解决方案，重点解读阿里巴巴提出的分布式事务解决方案 —— GTS。

 

 

3. SOA分布式事务解决方案

 

3.1 基于 XA 协议的两阶段提交方案

　　交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务，XA 规范的基础是两阶段提交协议。

　　第一阶段是表决阶段，所有参与者都将本事务能否成功的信息返回给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提价或者回滚。

 

　　两阶段提交方案应用非常广泛，几乎所有商业 OLTP 数据库都支持 XA 协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

 

3.2 TCC 方案

　　TCC 方案在电商、金融领域落地较多，TCC 方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。Try 部分完成业务的准备工作，cinfirm 部分完成业务的提交，cancel 部分完成事务的回滚。基本原理如下

 

 　　事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的 Try 接口，完成一阶段准备，之后事务协调器会根据 Try 接口返回情况，决定调用 confirm 接口或者 cancel 接口。如果接口调用失败会进行重试。

　　TCC 方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量称为可能，当然 TCC 方案也有不足之处，集中表现在以下两个方面：

• 对应用的侵入性强。业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，应用侵入性较强，改造成本高。
• 实现难度大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm 和 cancel 接口必须实现幂等（针对一个操作，不管做多少次，产生效果或返回的结果都是一样的）。

　　上述原因导致 TCC 方案大多被研发实力较强，有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而 TCC 方案中很多事物的处理逻辑需要应用自己的编码实现，复杂且开发了大。

 

3.3 基于消息的最终一致性方案

 　　消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

　　消息方案从本质上是将分布式事务转换成两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。

 

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

4.1 GTS的核心优势

• 性能超强：GTS通过大量创新，解决了事务ACID 特性与高性能、高可用、低侵入 不可兼得的问题。单事务分支的平均响应时间在 2ms 左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。
• 应用侵入性低：GTS对业务低侵入，业务代码最少只需添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。
• 完整解决方案：GTS支持多种主流的服务框架，包括 EDAS、Dubbo、SpringCloud 等。有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入 GTS。此时需要用到 GTS 的 MT 模式。GTS 的 MT 模式可以等价于 TCC 模式，用户可以根据自身业务需求自定义每个事物阶段的具体行为。MT 模式提供了更多的灵活性、可能性，以达到特殊场景下的自定义优化及特殊功能的实现。
• 容错能力强：GTS 解决了 XA 事务协调器单点问题，实现真正的高可用，可用保证各种异常情况下的严格数据一致。

 

4.2 GTS 与微服务的集成

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

 

 

4.3 GTS的输出

　　GTS 目前有三种输出形式：公有云输出、公网输出、专有云输出

　　

4.3.1 公有云输出

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

 

4.3.2 公网输出

　　这种输出形式面向于非阿里云用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受 GTS 提供的云服务（与公有云输出的差别在于客户端部署在用户本地，而不在云上）

 

4.3.3 专有云输出

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

 

 

 

摘抄自：https://www.cnblogs.com/jiangyu666/p/8522547.html