1. 微服务的发展，以及微服务落地所存在的问题
微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有 Dubbo、SpringCloud、thrift 、grpc等。
虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面：
1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。
2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
3）微服务数量众多，其测试、部署、监控等都变的更加困难。
随着 RPC 框架的成熟，第一个问题已经逐渐得到解决。例如 Dubbo 可以支持多种通讯协议，Spring Cloud可以非常好的支持 RESTful 调用。对于第三个问题，随着 Docker、DevOps 技术的发展以及各公有云 PaaS 平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。
而对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 为此，本文将深入和大家探讨微服务架构下，分布式事务的各种解决方案，并重点为大家解读阿里巴巴提出的分布式事务解决方案----全局事务服务（GTS），即全新一代解决微服务问题的分布式事务互联网中间件。
2. 传统分布式事务解决方案及其弊端
2.1 基于XA协议的两阶段提交方案
交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。 第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。
两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
2.2 TCC方案
TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理如下图所示。
事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。
TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
当然TCC方案也有不足之处，集中表现在以下两个方面：
1. 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
2. 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm 和 cancel 接口必须实现幂等。
上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。
2.3 基于消息的最终一致性方案
消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。
消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。
3 GTS：全新一代分布式事务解决方案
GTS 是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。
3.1 GTS的核心优势
性能超强
GTS 通过大量创新，解决了事务 ACID 特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在 2ms 左右，3 台服务器组成的集群可以支撑 3万 TPS 以上的分布式事务请求。
应用侵入性极低
GTS 对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。
完整解决方案
GTS支持多种主流的服务框架，包括 EDAS，Dubbo，Spring Cloud等。
有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。
容错能力强
GTS解决了XA事务协调器单点问题，典型配置是三台服务器组成的事务协调器集群，实现服务高可用，可以保证异常情况（比如网络断开、服务器宕机、硬盘损坏不可恢复等）下的数据严格一致。
在要求更高可用性的场景，比如电商业务双11大促，常用配置是六台服务器组成的主、备集群（各三台）。当主集群有服务器不可用，自动切换到备集群提供服务。
3.2 GTS的应用场景
GTS可应用在涉及服务调用的多个领域，包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等。
对于GTS已经支持的数据源（MySQL，DRDS，RDS，PetaData，Oracle，Oceanbase等）可以采用AT模式（自动模式，加个注解界定事务范围即可），对于目前不支持的数据源（HBase，Redis，DB2等）可以采用MT模式（手动模式，等价于TCC，需要手工实现接口）。
3.3 GTS与微服务的集成
GTS包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。GTS Client主要用来界定事务边界，完成事务的发起与结束。GTS RM完成事务分支的创建、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。GTS和微服务集成的结构图如下所示，GTS Client需要和业务应用集成部署，RM与微服务集成部署。
3.4 GTS的输出形式
GTS目前有三种输出形式：公有云输出、公网输出、专有云输出。
公有云输出
这种输出形式面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致性。这种使用场景下，业务系统和GTS间的网络环境比较理想，达到很好性能。
公网输出
这种输出形式面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务（与公有云输出的差别在于客户端部署于用户本地，而不在云上）。 在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，50个并发就可以轻松实现1000TPS以上分布式事务，对绝大多数业务来说性能是足够的。在公网环境，网络闪断很难完全避免，这种情况下GTS仍能保证服务调用的数据一致性。
专有云输出
这种形式主要面向于已建设了自己专有云平台的大用户，GTS可以直接部署到用户的专有云上，为专有云提供分布式事务服务。目前已经有10多个特大型企业的专有云使用GTS解决分布式事务难题，性能与稳定性经过了用户的严格检测。
3.5 GTS的应用情况
GTS目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。
GTS在公有云和专有云输出后，已经有了100多个线上用户，很多用户通过GTS解决SpringCloud、Dubbo、Edas等服务框架的分布式事务问题。业务领域涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致好评。
上图是 GTS 与 Spring Cloud 集成，应用于某共享出行系统。业务共享出行场景下，通过 GTS 支撑物联网系统、订单系统、支付系统、运维系统、分析系统等系各统应用的数据一致性，保证海量订单和数千万流水的交易。
3.6 GTS 的使用方式
GTS对应用的侵入性非常低，使用也很简单。下面以订单存储应用为例说明。订单业务应用通过调用订单服务和库存服务完成订单业务，服务开发框架为Dubbo。
1 订单业务应用
在业务函数外围使用@TxcTransaction注解即可开启分布式事务。Dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。
2 库存服务
更新库存
3.7 GTS的工程样例
1 sample-txc-simple样例
sample-txc-simple是GTS的入门样例，现在可以在阿里云环境或者公网环境运行此样例。点击查看搭建步骤
2 sample-txc-dubbo样例
sample-txc-dubbo是GTS和Dubbo框架集成的样例工程。本样例模拟了用户下订单、减库存的业务逻辑。客户端（Client）通过调用订单服务（OrderService）创建订单，之后通过调用库存服务（StockService）扣库存。其中订单服务读写订单数据库，库存服务读写库存数据库。由 GTS 保证跨服务事务的一致性。现在可以在阿里云环境或者公网环境运行此样例。点击查看搭建步骤
3 sample-txc-springcloud样例
sample-txc-springcloud是GTS和Spring Cloud集成的样例工程。样例模拟转账业务，从 A 账户扣款给 B 账户打款。应用程序通过调用扣款微服务和存款微服务完成转账业务。现在可以在阿里云环境运行此样例。点击查看搭建步骤点击下载样例工程
如您还有其他疑问，可以钉钉扫码加入如下 GTS 交流群，GTS 的一线技术专家将为您答疑解惑。
更多精彩分享
- 游戏论坛项目感言 2023-04-08 10:31:50.253
- 游戏论坛模拟 2023-04-08 10:45:38.443
- 云笔记 2022-07-13 15:06:14.387
- Shopify Experts 2022-02-21 23:44:46.197
- Google Ads Specialist 2022-01-04 20:00:59.0
- Buy here pay here PA 2021-08-31 19:11:51.327
- 萨达萨达所大所大所多 2019-04-04 12:34:03.7
- 5G时代，会是国产操作系统突破的契机吗？ 2018-12-26 23:31:29.32
- 8年时间，什么叫从0到1？雷军的小米已注定成传奇！ 2018-12-26 23:10:40.077
- Top Mobile Development Company in India 2018-08-16 21:18:29.953
游戏论坛模拟