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

摘抄并学习

 

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