码迷,mamicode.com
首页 > 其他好文 > 详细

阿里微服务架构下分布式事务解决方案-GTS

时间:2019-01-11 21:18:51      阅读:141      评论:0      收藏:0      [点我收藏+]

标签:aci   显示   []   细节   高可用集群   图片   1.4   timeout   微服务架构   

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段。即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例。GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性。本文将对GTS做出深入解读。

微服务倡导将复杂的单体应用拆分为若干个功能简单的、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。根据Netflix云架构总监Adrian Cockcrof,Hailo有160个不同服务构成,NetFlix有大约600个服务。国内方面,阿里巴巴、腾讯360、京东、58等很多互联网公司都进行了微服务化改造。当前微服务的开发框架也有几十种之多,比较著名的有DubboSpringCloudthrift 、grpc等。

GTS是一款分布式事务中间件,由阿里巴巴中间件部门研发,可以为微服务架构中的分布式事务提供一站式解决方案。GTS方案的基本思路是:将分布式事务与具体业务分离,在平台层面开发通用的事务中间件GTS,由事务中间件协调各服务的调用一致性,负责分布式事务的生命周期管理、服务调用失败的自动回滚。

GTS方案有三方面的优势,首先它将微服务从分布式事务中解放出来,微服务的实现不需要再考虑反向接口、幂等、回滚策略等复杂问题,只需要业务自己的接口即可,大大降低了微服务开发的难度与工作量。将分布式事务从所谓的“贵族技术”变为大家都能使用的“平民技术 ”,有利于微服务的落地与推广。 其次,GTS对业务代码几乎没有侵入,只需要通过注解@TxcTransaction界定事务边界即可,微服务接入GTS的成本非常低。第三,性能方面GTS也非常优秀,是传统XA方案的8~10倍。

1.1 基本原理

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完成回滚工作。

1.2 GTS的关键机制

  • 可用性 
    GTS服务也是由多个节点构成的高可用集群,可以弹性扩张,可以接收高并发的客户端请求。可以支持跨机房部署,支持同城容灾和两地三中心容灾。任何异常情况下的保证高可用。
  • 自动回滚策略 
    当有微服务调用失败时,GTS服务可以驱动各微服务的RM替微服务完成调用的回滚工作。举个转账的例子,转账应用通常调用存款服务和扣款服务完成转账功能。先调用扣款服务从A账户扣掉100元,然后调用存款服务向B账户中存款100元。如果转账应用在调用存款服务失败时,GTS Client会要求GTS Server发起回滚,然后通知扣款服务对应的RM,RM会直接在A账户增加100元。然后GTS Server通知转账应用回滚成功。从这个过程可以看到,在调用服务失败后,其实微服务不用做任何工作,而是由RM替微服务执行反向操作,也很自然的避免了幂等操作。TCC方案中,事务协调器需要显示调用微服务的反向向接口,如果反向接口调用失败还需要不断重试。
  • 可扩展性 
    有些情况下,应用需要调用第三方系统的接口或者不是基于GTS开发的微服,GTS无法接入到这些服务的实现中。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式。

MT模式预留了一阶段和二阶段的提交接口,允许应用介入GTS的两阶段提交。应用将提交及回滚接口注册后,GTS会自动完成调用。

  • 隔离级别 
    GTS目前支持读未提交和读已提交两种隔离级别。

1.3 GTS与其他方案的对比

1. 和XA方案对比

相比XA方案,GTS更加通用,可以对上层业务屏蔽底层实现细节,对业务几乎没有侵入。这一点在微服务时代特别有用,微服务面对的是大量的中小企业,甚至是个人开发者,业务诉求不尽相同,普适、标准的分布式事务产品是非常有必要的,可以让开发者从底层技术细节中脱离出来,更专注于业务逻辑的实现,从而获得更高效、快速的业务发展。两个方案都可以遵循ACID特性,都可以实现事务的强一致性。GTS性能要比XA方案高。

2. 和TCC方案对比

GTS方案和TCC方案最大的区别是实现分布式事务实现的层面不同。TCC方案选择从业务层面实现分布式事务功能,将事务的回滚、重试等功能在微服务中实现。而GTS选择从中间件层面解决分布式事务问题,对微服务几乎无侵入。两个方案都可以获得比较好的性能,都可以保证调用的一致性。TCC方案实现难度比较大,适合技术实力较强的团队。GTS方案可以实现事务的强一致性,另外采用GTS方案后微服务会更简单,耦合性也非常低。TCC主要提供开发框架,实现需要依赖业务方,而GTS是完整的分布式事务解决方案,所有分布式事务问题不需要业务方介入。

3. 和消息最终一致性对比

相比消息方案,GTS方案侵入性非常低,可以实现数据的强一致性。采用消息方案,上下游服务之间有很强的耦合性,测试、部署都不是很方便,需要单独建设消息系统。不过消息方案实现相对简单,如果对一致性要求不高,也是一个选择。

1.4 GTS的应用场景

GTS可应用在涉及服务调用的多个领域,包括但不限于金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等,详细介绍可以阅读 《GTS--阿里巴巴分布式事务全新解决方案》一文。

1.5 GTS的输出形式

GTS目前有三种输出形式:通过公有云平台输出、通过公网云服务输出、通过专有云平台输出。

  • 1 通过公有云平台输出

这种输出形式主要面向阿里云用户。如果用户的业务系统已经部署到阿里云上,可以直接申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致行。这种使用场景下,业务系统和GTS间的网络环境比较理想,GTS能提供更低的响应时间。
技术分享图片

公有云提供了比较丰富的与dubbo、SpringCloud等集成的样例,可以点击查看。

  • 2 通过公网云服务输出

这种输出形式主要面向于非阿里云的用户,使用更加方便、灵活,业务系统只要能连接互联网即可享受GTS提供的云服务。在网络抖动和闪断的情况下,GTS仍能保证服务调用的一致性。在正常网络环境下,以包含两个本地事务的全局事务为例,事务完成时间在20ms左右,业务可以轻松实现1000TPS以上分布式事务,可以满足绝大多数业务系统的需要。也可以用于本地的开发和测试 。
技术分享图片
现在提供了sample-txc-simple和sample-txc-sample两个样例,sample-txc-simple是GTS的入门的基础样例,点击下载后,搭建好本地的数据库环境就可以直接运行样例。sample-txc-dubbo是GTS和dubbo框架集成的样例,也可以直接在本地机器运行。

  • 3 通过专有云平台输出

这种形式主要面向于已建设了自己专有云平台的大用户,GTS可以直接部署到用户的专有云平台上,为专有云提供分布式事务服务。目前国家电网公司、中国邮政、浙江烟草等特大型企业的专有云都使用GTS,保证数据一致性。

1.6 GTS的使用方式

GTS对应用的侵入性非常低,使用也非常简单。下面以订单存储应用为例说明。订单业务应用通过调用订单服务和库存服务完成订单业务,服务开发框架为dubbo。

1 订单业务应用

在业务函数外围使用@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);
}

2 服务端使用方式

库存服务


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;
}

1.7 GTS的应用情况

GTS在满足事务ACID的前提下,普通配置的单服务器可以达到15000 TPS以上的超强性能(两个小时完成1亿多笔业务)。目前已经在淘宝、天猫、阿里影业、淘票票、阿里妈妈、1688等阿里各业务系统广泛使用,经受了16年和17年两年双十一海量请求的考验。某线上业务系统最高流量已达十万TPS(每秒钟10万笔事务)。GTS在阿里云及专有云上输出后,有很多用户通过GTS解决SpringCloud、Dubbo、Edas等微服务的分布式事务问题,包括国家电网、中国邮政、中国烟草、特步、浙江公安、德邦快递、一步共享科技等,涉及电力、物流、ETC、烟草、金融、零售、电商、共享出行等十几个行业,得到用户的一致认可
技术分享图片
上图是GTS与SpringCloud集成,应用于某共享出行系统。业务共享出行场景下,通过GTS支撑物联网系统、订单系统、支付系统、运维系统、分析系统等系各统应用事务一致性,保证海量订单和数千万流水的交易。

阿里微服务架构下分布式事务解决方案-GTS

标签:aci   显示   []   细节   高可用集群   图片   1.4   timeout   微服务架构   

原文地址:https://www.cnblogs.com/barrywxx/p/10257307.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!