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

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

开源地址:https://github.com/seata/seata

1 微服务的发展

微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务,这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇,很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成,NetFlix有大约600个服务。国内方面,阿里巴巴、腾讯、360、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多,比较著名的有Dubbo、SpringCloud、thrift 、grpc等。

2 微服务落地存在的问题

虽然微服务现在如火如荼,但对其实践其实仍处于探索阶段。很多中小型互联网公司,鉴于经验、技术实力等问题,微服务落地比较困难。如著名架构师Chris Richardson所言,目前存在的主要困难有如下几方面:

1)单体应用拆分为分布式系统后,进程间的通讯机制和故障处理措施变的更加复杂。

2)系统微服务化后,一个看似简单的功能,内部可能需要调用多个服务并操作多个数据库实现,服务调用的分布式事务问题变的非常突出。

3)微服务数量众多,其测试、部署、监控等都变的更加困难。

随着RPC框架的成熟,第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议,springcloud可以非常好的支持restful调用。对于第三个问题,随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出,微服务的测试、部署与运维会变得越来越容易。

而对于第二个问题,现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍,也是最具挑战性的一个技术难题。 为此,本文将深入和大家探讨微服务架构下,分布式事务的各种解决方案,并重点为大家解读阿里巴巴提出的分布式事务解决方案----GTS。该方案中提到的GTS是全新一代解决微服务问题的分布式事务互联网中间件。

3 SOA分布式事务解决方案

3.1 基于XA协议的两阶段提交方案

交易中间件与数据库通过 XA 接口规范,使用两阶段提交来完成一个全局事务, XA 规范的基础是两阶段提交协议。

第一阶段是表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;第二阶段是执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚。

微服务架构下分布式事务解决方案——阿里GTS_第1张图片

两阶段提交方案应用非常广泛,几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长,对性能影响很大,基本不适合解决微服务事务问题。

3.2 TCC方案

TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。基本原理如下图所示。

微服务架构下分布式事务解决方案——阿里GTS_第2张图片

事务开始时,业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口,完成一阶段准备。之后事务协调器会根据try接口返回情况,决定调用confirm接口或者cancel接口。如果接口调用失败,会进行重试。

TCC方案让应用自己定义数据库操作的粒度,使得降低锁冲突、提高吞吐量成为可能。 当然TCC方案也有不足之处,集中表现在以下两个方面:

  • 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作,应用侵入性较强,改造成本高。
  • 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求,confirm和cancel接口必须实现幂等。

上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署,而TCC方案中很多事务的处理逻辑需要应用自己编码实现,复杂且开发量大。

3.3 基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息,收到消息后执行相应操作。

微服务架构下分布式事务解决方案——阿里GTS_第3张图片

消息方案从本质上讲是将分布式事务转换为两个本地事务,然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高,应用需要进行大量业务改造,成本较高。

4 GTS–分布式事务解决方案

GTS是一款分布式事务中间件(https://www.aliyun.com/aliware/txc?spm=5176.8142029.388261.386.a72376f4lqvQxv),由阿里巴巴中间件部门研发,可以为微服务架构中的分布式事务提供一站式解决方案。

更多GTS资料请访问创始人微博(https://weibo.com/jiangyu666)。

4.1 GTS的核心优势

  • 性能超强

    GTS通过大量创新,解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右,3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。

  • 应用侵入性极低

    GTS对业务低侵入,业务代码最少只需要添加一行注解(@TxcTransaction)声明事务即可。业务与事务分离,将微服务从事务中解放出来,微服务关注于业务本身,不再需要考虑反向接口、幂等、回滚策略等复杂问题,极大降低了微服务开发的难度与工作量。

  • 完整解决方案

    GTS支持多种主流的服务框架,包括EDAS,Dubbo,Spring Cloud等。
    有些情况下,应用需要调用第三方系统的接口,而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式,用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性,可能性,以达到特殊场景下的自定义优化及特殊功能的实现。

  • 容错能力强

    GTS解决了XA事务协调器单点问题,实现真正的高可用,可以保证各种异常情况下的严格数据一致。

4.2 GTS的应用场景

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

4.3 GTS与微服务的集成

GTS包括客户端(GTS Client)、资源管理器(GTS RM)和事务协调器(GTS Server)三个部分。GTS Client主要用来界定事务边界,完成事务的发起与结束。GTS RM完成事务分支的创建、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进,事务生命周期的管理。GTS和微服务集成的结构图如下所示,GTS Client需要和业务应用集成部署,RM与微服务集成部署。

微服务架构下分布式事务解决方案——阿里GTS_第4张图片

4.4 GTS的输出形式

GTS目前有三种输出形式:公有云输出、公网输出、专有云输出。

4.4.1 公有云输出

这种输出形式面向阿里云用户。如果用户的业务系统已经部署到阿里云上,可以申请开通公有云GTS。开通后业务应用即可通过GTS保证服务调用的一致性。这种使用场景下,业务系统和GTS间的网络环境比较理想,达到很好性能。

微服务架构下分布式事务解决方案——阿里GTS_第5张图片

4.4.2 公网输出

这种输出形式面向于非阿里云的用户,使用更加方便、灵活,业务系统只要能连接互联网即可享受GTS提供的云服务(与公有云输出的差别在于客户端部署于用户本地,而不在云上)。

在正常网络环境下,以包含两个本地事务的全局事务为例,事务完成时间在20ms左右,50个并发就可以轻松实现1000TPS以上分布式事务,对绝大多数业务来说性能是足够的。在公网环境,网络闪断很难完全避免,这种情况下GTS仍能保证服务调用的数据一致性。

微服务架构下分布式事务解决方案——阿里GTS_第6张图片

4.5 GTS的使用方式

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

4.5.1 订单业务应用

在业务函数外围使用@TxcTransaction注解即可开启分布式事务。Dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。

@TxcTransaction(timeout = 1000 * 10)
public void Bussiness(OrderService orderService, StockService stockService, String userId) {
    //获取事务上下文
    String xid = TxcContext.getCurrentXid();
    //通过RpcContext将xid传到一个服务端
    RpcContext.getContext().setAttachment("xid", xid);
    
    //执行自己的业务逻辑
    int productId = new Random().nextInt(100);
    int productNum = new Random().nextInt(100);
    OrderDO orderDO = new OrderDO(userId, productId, productNum, new Timestamp(new Date().getTime()));
    orderService.createOrder(orderDO);
    
    //通过RpcContext将xid传到另一个服务端
    RpcContext.getContext().setAttachment("xid",xid);
    stockService.updateStock(orderDO);
}
4.5.2 服务提供者

更新库存方法

public int updateStock(OrderDO orderDO) {

	//获取全局事务ID,并绑定到上下文

	String xid = RpcContext.getContext().getAttachment("xid");

	TxcContext.bind(xid,null);

	//执行自己的业务逻辑

	int ret = jdbcTemplate.update("update stock set amount = amount - ? where product_id = ?",new Object[]{orderDO.getNumber(), orderDO.getProductId()});

	TxcContext.unbind();

	return ret;

}

4.6 GTS的应用情况

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

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

4.7 GTS的工程样例

GTS的公有云样例可参考阿里云网站。在公网环境下提供sample-txc-simple(http://txc-console.oss-cn-beijing.aliyuncs.com/sample/sample-txc-simple.zip)和sample-txc-dubbo(http://txc-console.oss-cn-beijing.aliyuncs.com/sample/sample-txc-dubbo.zip)两个样例工程。

你可能感兴趣的:(分布式事务,GTS)