cls设计三大框架内容：五年磨一剑16项核心专利
cls设计三大框架内容：五年磨一剑16项核心专利GTS优势XA方案是在资源层面解决分布式事务的问题。补偿方案和消息方案是在应用层面解决事务问题。GTS既不在资源层面也不在应用层面，而是在中间件的层面解决事务问题。这是GTS和其他三个方案的本质不同点。在中间件层面解决有几个优势：第一，可以解决跨资源的事务问题，这个是XA方案很难做到的。如果业务系统需要访问多个资源，比如多个mysql数据库同时需要访问MYSQL以及HBASE，这个过程产生的事务问题，GTS可以解决。第二，可以解决服务化的事务问题，而且和应用是松耦合的，通过使用GTS微服务不需要嵌入解决事务的逻辑，微服务会更加简单、轻量化。第三，GTS对应用的侵入性非常低，便于应用的扩展和移植。在GTS出现之前，事务问题的解决方案主要有XA方案，补偿方案，消息方案等。·XA方案：优点为接口标准化。缺点是阻塞协议，影响系统吞吐和可伸缩性，性能不理想，很难满足互联网大并发需求，缺乏容错机制。·
在企业级互联网架构专场中，来自阿里巴巴的中间件技术专家厉启鹏（寈峰）为现场的听众带来了题为《GTS-分布式事务全新解决方案》的精彩分享。在本次分享中，他重点阐述了GTS如何帮助解决分布式事务问题，包括产品GTS的基本原理、核心优势、应用场景等；介绍了GTS的商业化情况，包括应用案例、商业化后给用户带来的价值提升等。
以下内容根据现场分享整理而成。
产品简介GTS是行业内的第一款也是唯一的一款，专注于解决分布式事务问题的中间件。GTS被定义为一站式的分布式事务解决方案，立足点是解决所有的事务问题。应用开发中遇到的事务问题大致分为四个方面：跨库事务、服务化事务、消息事务、混合事务。
GTS与其他解决方案对比
在GTS出现之前，事务问题的解决方案主要有XA方案，补偿方案，消息方案等。
·XA方案：优点为接口标准化。缺点是阻塞协议，影响系统吞吐和可伸缩性，性能不理想，很难满足互联网大并发需求，缺乏容错机制。
·补偿方案：优点为符合业务需求。缺点是实现复杂，各种异常情况难于处理，要求每个方法实现一个反向的回滚接口，运维成本高，扩现移植性不理想。
XA方案是在资源层面解决分布式事务的问题。补偿方案和消息方案是在应用层面解决事务问题。GTS既不在资源层面也不在应用层面，而是在中间件的层面解决事务问题。这是GTS和其他三个方案的本质不同点。在中间件层面解决有几个优势：第一，可以解决跨资源的事务问题，这个是XA方案很难做到的。如果业务系统需要访问多个资源，比如多个mysql数据库同时需要访问MYSQL以及HBASE，这个过程产生的事务问题，GTS可以解决。第二，可以解决服务化的事务问题，而且和应用是松耦合的，通过使用GTS微服务不需要嵌入解决事务的逻辑，微服务会更加简单、轻量化。第三，GTS对应用的侵入性非常低，便于应用的扩展和移植。
GTS优势
GTS的优势总结起来包括四个方面：
·完整解决方案。可以解决分布式数据库、跨数据库、服务化、消息系统场景下的分布式事务问题。
·侵入性极低。一行注解即可实现事务接入，也提供 API 接入模式使用门槛低，节省开发和运维成本。
·性能超强。高达传统分布式事务 10 倍性能，4c8g集群可达1.5万TPS。热点数据高效处理，无惧数据冲突。
·高可用。支持应用宕机、节点故障等各类异常情况下均可保持数据严格一致，支持同城主备及两地三中心部署。
产品历史
GTS于2014年正式立项，由阿里高级技术专家于皋牵头研发，所谓5年磨一剑。到2015年12月份在阿里内部各业务线大规模应用。2017年2月份在阿里云公测。目前GTS拥有16项核心专利，其中包括4项国际专利。阿里巴巴的用户现在主要有三类：专有云用户、公有云用户、阿里内部用户。
GTS于5月21日正式商用，首发1月内购买，低至七折。GTS 实例规格分为 5 TPS(免费版)、20 TPS、100 TPS、200 TPS、500 TPS、2000 TPS 和 5000 TPS。
功能架构总体架构
上图为总体架构图，左侧为GTS服务端，为三个节点的组成的集群；右侧为客户端。
GTS事务模型
GTS的全局事务是由若干个分支事务构成的。
GTS的客户端包含两部分：GTS Client和RM。在全局事务开始时，GTS Client会连接服务端，服务端会返回xid给Client；Client端将xid传输给涉及到全局事务的所有RM；之后，全局事务中的每一个RM需要开启一个分支事务，RM需要向服务端获取一个分支事务的ID号;之后，RM会汇报状态给服务端，服务端会知道每一个分支事务的执行情况，然后根据情况返回给Client端，以完成数据提交工作。
GTS与微服务集成架构
GTS与微服务框架集成的架构如上图所示。业务应用在调用微服务时首先会通过GTS Server发起一个全局事务，获取到全局事务ID后。业务应用进行服务调用，同时会将全局事务ID，也就是xid传输到每个服务端。业务应用在调用a、b之后如果调用微服务c的时候出现了异常，这个时候业务应用会通知服务端，由服务端驱动微服务的RM进行服务的回滚。这个回滚对服务是透明的。
容错机制
GTS允许服务端出现宕机情况，它可以保证这种情况下事务的一致性。如果应用是多机部署的，在应用节点宕机的情况下GTS仍然可以保证数据的一致性。
·服务节点宕机
如上图所示，在回滚的过程中，S3出现宕机情况之后，App1连接不上S3。此时，S1里面有S3的备用信息，那么App1会自动连接S1，由S1协助完成App1刚刚没有完成的回滚的工作。
·应用节点宕机
如上图所示，App2是客户端发起了回滚操作，如果回滚的过程中app1所在的节点宕机，这个时候，GTS服务端会驱动其他app1的RM完成回滚。
扩展机制
GTS支持横向扩展。由上图可以看出，一个逻辑组可以映射不同的物理组，而且不同的逻辑组可以映射到同一个物理组。
在应用节点非常多的情况下，可以通过不同的逻辑组去映射不同的物理结点，以达到横向扩展的效果。
AT&MT
GTS提供AT模式（自动模式）和MT（手动）两种模式。AT模式可以覆盖90%以上的场景，也是我们首先推荐使用的模式。可以自动回滚、对业务无侵入。MT模式是GTS对TCC的一种支持，主要适用于多个系统集成的场景。两种模式可以组合使用。
应用场景解决跨数据库的事务问题
数据库可以是同构数据库，异构数据库，关系数据库，非关系数据库等。GTS可以保证多种情况下的事务一致性。
解决微服务调用的事务问题
微服务经常会遇到各种事务问题，GTS非常适合解决这样的问题。比如应用嵌套调用微服务等，GTS都可以保证事务的一致性。
解决多系统集成的事务问题
上图为用户的案例。放款应用调用金融系统中的信用核心的服务去完成系统评估，调用风控中心服务为客户做风险评估，调用额度中心生成放款额度，最后调用银行的支用服务和合法校验服务，完成放款的操作。
解决混合事务问题
当应用调用多个服务时，GTS也可以解决这样的混合事务问题。
实践操作AT模式
上图所示例子为转账操作。
如上图所示，配置文件里需要加两个东西，第一个是GTS提供的一个数据源，第二个是需要加TxcTransactionScaner
MT模式
MT模式是调用第三方接口，或者是在不同系统集成的时候可能用到的一种模式。
在不同的阶段，GTS会调用不同的方法，当方法调用失败的时候GTS会有一定的策略去处理，保证方法的正确实行。
