标签：aci 显示 [] 细节 高可用集群 图片 1.4 timeout 微服务架构
虽然微服务现在如火如荼，但对其实践其实仍处于初级阶段。即使互联网巨头的实践也大多是试验层面，鲜有核心业务系统微服务化的案例。GTS是目前业界第一款，也是唯一的一款通用的解决微服务分布式事务问题的中间件，而且可以保证数据的强一致性。本文将对GTS做出深入解读。
微服务倡导将复杂的单体应用拆分为若干个功能简单的、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。概念2012年提出迅速火遍全球，被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。根据Netflix云架构总监Adrian Cockcrof，Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58等很多互联网公司都进行了微服务化改造。当前微服务的开发框架也有几十种之多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。
GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。GTS方案的基本思路是：将分布式事务与具体业务分离，在平台层面开发通用的事务中间件GTS，由事务中间件协调各服务的调用一致性，负责分布式事务的生命周期管理、服务调用失败的自动回滚。
GTS方案有三方面的优势，首先它将微服务从分布式事务中解放出来，微服务的实现不需要再考虑反向接口、幂等、回滚策略等复杂问题，只需要业务自己的接口即可，大大降低了微服务开发的难度与工作量。将分布式事务从所谓的“贵族技术”变为大家都能使用的“平民技术 ”，有利于微服务的落地与推广。 其次，GTS对业务代码几乎没有侵入，只需要通过注解@TxcTransaction界定事务边界即可，微服务接入GTS的成本非常低。第三，性能方面GTS也非常优秀，是传统XA方案的8～10倍。
GTS中间件主要包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三部分。GTS Client主要完成事务的发起与结束。GTS RM完成分支事务的开启、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。 
GTS和微服务集成后的结构图如上图所示。GTS Client需要和业务应用集成部署，RM与微服务集成部署。当业务应用发起服务调用时，首先会通过GTS Client向TC注册新的全局事务。之后GTS Server会给业务应用返回全局唯一的事务编号xid。业务应用调用服务时会将xid传播到服务端。微服务在执行数据库操作时会通过GTS RM向GTS Server注册分支事务，并完成分支事务的提交。如果A、B、C三个服务均调用成功，GTS Client会通知GTS Server结束事务。假设C调用失败，GTS Client会要求GTS Server发起全局回滚。然后由各自的RM完成回滚工作。
MT模式预留了一阶段和二阶段的提交接口，允许应用介入GTS的两阶段提交。应用将提交及回滚接口注册后，GTS会自动完成调用。
相比XA方案，GTS更加通用，可以对上层业务屏蔽底层实现细节，对业务几乎没有侵入。这一点在微服务时代特别有用，微服务面对的是大量的中小企业，甚至是个人开发者，业务诉求不尽相同，普适、标准的分布式事务产品是非常有必要的，可以让开发者从底层技术细节中脱离出来，更专注于业务逻辑的实现，从而获得更高效、快速的业务发展。两个方案都可以遵循ACID特性，都可以实现事务的强一致性。GTS性能要比XA方案高。
GTS方案和TCC方案最大的区别是实现分布式事务实现的层面不同。TCC方案选择从业务层面实现分布式事务功能，将事务的回滚、重试等功能在微服务中实现。而GTS选择从中间件层面解决分布式事务问题，对微服务几乎无侵入。两个方案都可以获得比较好的性能，都可以保证调用的一致性。TCC方案实现难度比较大，适合技术实力较强的团队。GTS方案可以实现事务的强一致性，另外采用GTS方案后微服务会更简单，耦合性也非常低。TCC主要提供开发框架，实现需要依赖业务方，而GTS是完整的分布式事务解决方案，所有分布式事务问题不需要业务方介入。
相比消息方案，GTS方案侵入性非常低，可以实现数据的强一致性。采用消息方案，上下游服务之间有很强的耦合性，测试、部署都不是很方便，需要单独建设消息系统。不过消息方案实现相对简单，如果对一致性要求不高，也是一个选择。
GTS可应用在涉及服务调用的多个领域，包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等，详细介绍可以阅读 《GTS--阿里巴巴分布式事务全新解决方案》一文。
GTS目前有三种输出形式：通过公有云平台输出、通过公网云服务输出、通过专有云平台输出。
这种输出形式主要面向阿里云用户。如果用户的业务系统已经部署到阿里云上，可以直接申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致行。这种使用场景下，业务系统和GTS间的网络环境比较理想，GTS能提供更低的响应时间。
公有云提供了比较丰富的与dubbo、SpringCloud等集成的样例，可以点击查看。
这种输出形式主要面向于非阿里云的用户，使用更加方便、灵活，业务系统只要能连接互联网即可享受GTS提供的云服务。在网络抖动和闪断的情况下，GTS仍能保证服务调用的一致性。在正常网络环境下，以包含两个本地事务的全局事务为例，事务完成时间在20ms左右，业务可以轻松实现1000TPS以上分布式事务，可以满足绝大多数业务系统的需要。也可以用于本地的开发和测试 。
现在提供了sample-txc-simple和sample-txc-sample两个样例，sample-txc-simple是GTS的入门的基础样例，点击下载后，搭建好本地的数据库环境就可以直接运行样例。sample-txc-dubbo是GTS和dubbo框架集成的样例，也可以直接在本地机器运行。
这种形式主要面向于已建设了自己专有云平台的大用户，GTS可以直接部署到用户的专有云平台上，为专有云提供分布式事务服务。目前国家电网公司、中国邮政、浙江烟草等特大型企业的专有云都使用GTS，保证数据一致性。
GTS对应用的侵入性非常低，使用也非常简单。下面以订单存储应用为例说明。订单业务应用通过调用订单服务和库存服务完成订单业务，服务开发框架为dubbo。
在业务函数外围使用@TxcTransaction注解即可开启分布式事务。dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。
@TxcTransaction(timeout = 1000 * 10)
public void Bussiness(OrderServiceInterface os,StockServiceInterface ss)
{
//获取xid
String xid = TxcContext.getCurrentXid();
//1：调用订单服务，创建订单
//通过dubbo的隐形参数将txcid传到服务端
RpcContext.getContext().setAttachment("xid",xid);
int ret = os.setOrder(new Order(pid,num,new Date()));//调用订单服务
//2：调用库存服务，扣库存
RpcContext.getContext().setAttachment("xid",xid);
}库存服务
public int setStock(Stock sk) {
//通过dubbo上下文获取xid
String xid = RpcContext.getContext().getAttachment("xid");
//将事务id绑定到服务端txc的上下文
TxcContext.bind(xid,null);
//执行扣库存操作
ret = jdbcTemplate2.update("update stock set number = number -? where pid = ?",new Object[]{sk.getPnum(),sk.getPid()});
return ret;
}GTS在满足事务ACID的前提下，普通配置的单服务器可以达到15000 TPS以上的超强性能（两个小时完成1亿多笔业务）。目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用，经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS（每秒钟10万笔事务）。GTS在阿里云及专有云上输出后，有很多用户通过GTS解决SpringCloud、Dubbo、Edas等微服务的分布式事务问题，包括国家电网、中国邮政、中国烟草、特步、浙江公安、德邦快递、一步共享科技等，涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业，得到用户的一致认可。
上图是GTS与SpringCloud集成，应用于某共享出行系统。业务共享出行场景下，通过GTS支撑物联网系统、订单系统、支付系统、运维系统、分析系统等系各统应用事务一致性，保证海量订单和数千万流水的交易。
标签：aci 显示 [] 细节 高可用集群 图片 1.4 timeout 微服务架构
原文地址：https://www.cnblogs.com/barrywxx/p/10257307.html
