GTS属于分布式事务中间件，是阿里的研发出来的，在微服务架构中分布式事务提供一站式解决方案GTS优势
性能强
GTS解决事务ACID特性与高性能、高可用、低侵略的问题。单事务分支平均响应在2ms，一般3个服务器组成集群
足够支撑3w个TPS以上的分布式事务请求
侵入性低
GTS对业务侵入低，业务代码最少的情况下只需要添加注解一个 @TxcTransaction 声明事务就得了
事务与业务分离，将微服务从事务中解放，微服务关注点在业务 无需考虑反向接口，幂等、回滚策略等复杂问题
有效降低微服务开发难度和繁杂的工作量
完整解决方案
GTS支持多种主流服务框架 其中DUBBO SpringClod应用
GTS的MT模式下等价于TCC模式，用户可以根据业务需求自定义每个事务阶段具体行为。MT模式提供很多灵活的自定义优化与特殊功能满足特殊的应用场景
容错率高
GTS解决XA事务协调器单点问题。可以做到高可用保证各种异常能严格保持一致
GTS应用场景
涉及服务调用多个领域，泛指金融支付，电信，电子商务，快递物流，广告营销，即时社交通信，手游，
物流网等应用业务
GTS与微服务集成
GTS客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。
Client用来界定事务边界，完成发起和结束提交。RM负责完成事务分支行为包括创建提交回滚等操作。
Server负责分布式事务的整体推进，事务生命周期管理。

GTS输出形式
公有云输出、
这种输出形式面向阿里云用户。阿里云处理用户业务系统的事务。统一治理保持服务调用一致性达到最佳的性能
公网输出、
这种输出面向非阿里用户，在正常网络环境下，连接互联网即可享受GTS云服务。事务完成时间短并发强
专有云输出。
这种面向自己专用云平台的大用户。GTS部署到专用云上面提供分布式事务服务。性能与稳定需要经过用户自身严格检测。
GTS使用方式
使用简单，例如订单功能应用，通过调用订单服务与库存服务完成订单。服务开发框架使用DUbbo

GTS的应用情况

GTS目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。

GTS在公有云和专有云输出后，已经有了100多个线上用户，很多用户通过GTS解决SpringCloud、Dubbo、Edas等服务框架的分布式事务问题。业务领域涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致认可。

准备数据库环境
安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表（SQL脚本见4.7.3）。在db1库中创建user_money_a表，在db2库中创建user_money_b表。
下载样例
将sample-txc-simple文件下载到本地，样例中已经包含了GTS的SDK。
修改配置
打开sample-txc-simple/src/main/resources目录下的txc-client-context.xml，将数据源的url、username、password修改为实际值。
运行样例
在sample-txc-simple目录下执行build.sh编译本工程。编译完成后执行run.sh。

样例搭建方法

1) 准备数据库环境

安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表。在db1库中创建orders表，在db2库中创建stock表。

2) 下载样例

将样例文件sample-txc-dubbo下载到本地机器，样例中已经包含了GTS的SDK。

3) 修改配置

打开sample-txc-dubbo/src/main/resources目录，将dubbo-order-service.xml、dubbo-stock-service.xml两个文件中数据源的url、username、password修改为实际值。

4) 运行样例

• 编译程序在工程根目录执行 build.sh 命令，编译工程。编译后会在 sample-txc-dubbo/client/bin 目录下生成 order_run.sh、stock_run.sh、client_run.sh 三个运行脚本对应订单服务、库存服务以及客户端。
• 运行程序
  

在根目录执行run.sh，该脚本会依次启动order_run.sh(订单服务)、stock_run.sh(库存服务)和client_run.sh(客户端程序)。

总结

GTS已经在阿里内部广泛使用，经过了双十一流量高峰的考验。内部成熟后，在专有云和公有云服务了很多用户，很多用户一天事务量在千万/亿级别，解决了业务服务化改造后的分布式事务棘手技术难题。

GTS属于分布式事务中间件，是阿里的研发出来的，在微服务架构中分布式事务提供一站式解决方案GTS优势
性能强
GTS解决事务ACID特性与高性能、高可用、低侵略的问题。单事务分支平均响应在2ms，一般3个服务器组成集群
足够支撑3w个TPS以上的分布式事务请求
侵入性低
GTS对业务侵入低，业务代码最少的情况下只需要添加注解一个 @TxcTransaction 声明事务就得了
事务与业务分离，将微服务从事务中解放，微服务关注点在业务 无需考虑反向接口，幂等、回滚策略等复杂问题
有效降低微服务开发难度和繁杂的工作量
完整解决方案
GTS支持多种主流服务框架 其中DUBBO SpringClod应用
GTS的MT模式下等价于TCC模式，用户可以根据业务需求自定义每个事务阶段具体行为。MT模式提供很多灵活的自定义优化与特殊功能满足特殊的应用场景
容错率高
GTS解决XA事务协调器单点问题。可以做到高可用保证各种异常能严格保持一致
GTS应用场景
涉及服务调用多个领域，泛指金融支付，电信，电子商务，快递物流，广告营销，即时社交通信，手游，
物流网等应用业务
GTS与微服务集成
GTS客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。
Client用来界定事务边界，完成发起和结束提交。RM负责完成事务分支行为包括创建提交回滚等操作。
Server负责分布式事务的整体推进，事务生命周期管理。

GTS输出形式
公有云输出、
这种输出形式面向阿里云用户。阿里云处理用户业务系统的事务。统一治理保持服务调用一致性达到最佳的性能
公网输出、
这种输出面向非阿里用户，在正常网络环境下，连接互联网即可享受GTS云服务。事务完成时间短并发强
专有云输出。
这种面向自己专用云平台的大用户。GTS部署到专用云上面提供分布式事务服务。性能与稳定需要经过用户自身严格检测。
GTS使用方式
使用简单，例如订单功能应用，通过调用订单服务与库存服务完成订单。服务开发框架使用DUbbo

GTS的应用情况

GTS目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。

GTS在公有云和专有云输出后，已经有了100多个线上用户，很多用户通过GTS解决SpringCloud、Dubbo、Edas等服务框架的分布式事务问题。业务领域涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致认可。

准备数据库环境
安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表（SQL脚本见4.7.3）。在db1库中创建user_money_a表，在db2库中创建user_money_b表。
下载样例
将sample-txc-simple文件下载到本地，样例中已经包含了GTS的SDK。
修改配置
打开sample-txc-simple/src/main/resources目录下的txc-client-context.xml，将数据源的url、username、password修改为实际值。
运行样例
在sample-txc-simple目录下执行build.sh编译本工程。编译完成后执行run.sh。

样例搭建方法

1) 准备数据库环境

安装MySQL，创建两个数据库db1和db2。在db1和db2中分别创建txc_undo_log表。在db1库中创建orders表，在db2库中创建stock表。

2) 下载样例

将样例文件sample-txc-dubbo下载到本地机器，样例中已经包含了GTS的SDK。

3) 修改配置

打开sample-txc-dubbo/src/main/resources目录，将dubbo-order-service.xml、dubbo-stock-service.xml两个文件中数据源的url、username、password修改为实际值。

4) 运行样例

• 编译程序在工程根目录执行 build.sh 命令，编译工程。编译后会在 sample-txc-dubbo/client/bin 目录下生成 order_run.sh、stock_run.sh、client_run.sh 三个运行脚本对应订单服务、库存服务以及客户端。
• 运行程序
  

在根目录执行run.sh，该脚本会依次启动order_run.sh(订单服务)、stock_run.sh(库存服务)和client_run.sh(客户端程序)。

总结

GTS已经在阿里内部广泛使用，经过了双十一流量高峰的考验。内部成熟后，在专有云和公有云服务了很多用户，很多用户一天事务量在千万/亿级别，解决了业务服务化改造后的分布式事务棘手技术难题。