作者：季敏（清铭）Seata 开源社区创始人，分布式事务团队卖力人。
本文紧张先容分布式事务从内部到商业化和开源的演进进程，Seata 社区当提高展和未来方案。
Seata 是一款开源的分布式事务办理方案，旨在为当代化微做事架构下的分布式事务供应办理方案。Seata 供应了完全的分布式事务办理方案，包括 AT、TCC、Saga 和 XA 事务模式，可支持多种编程措辞和数据存储方案。Seata 还供应了简便易用的 API，以及丰富的文档和示例，方便企业在运用 Seata 时进行快速开拓和支配。
Seata 的上风在于具有高可用性、高性能、高扩展性等特点，同时在进行横向扩展时也无需做额外的繁芜操作。目前 Seata 已在阿里云上几千家客户业务系统中利用，其可靠性得到了业内各大厂商的认可和运用。
作为一个开源项目，Seata 的社区也在不断扩大，现已成为开拓者互换、分享和学习的主要平台，也得到了越来越多企业的支持和关注。
本日我紧张针对以下三个小议题对 Seata 进行分享：
从 TXC/GTS 到 SeataSeata 社区最新进展Seata 社区未来方案从 TXC/GTS 到 Seata分布式事务的缘起Seata 在阿里内部的产品代号叫 TXC（taobao transaction constructor），这个名字有非常浓厚的组织架构色彩。TXC 起源于阿里五彩石项目，五彩石是上古神话中女娲补天所用的石子，项目名喻意为冲破关键技能壁垒，象征着阿里在从单体架构向分布式架构的演进过程中的主要里程碑。在这个项目的过程中演进出一批划时期的互联网中间件，包括我们常说的三大件：
HSF 做事调用框架，办理单体运用到做事化后的做事通信调用问题。TDDL 分库分表框架，办理规模化后单库存储容量和连接数问题。MetaQ 框架，办理异步调用问题。三大件的出身知足了微做事化业务开拓的基本需求，但是微做事化后的数据同等性问题并未得到妥善办理，短缺统一的办理方案。运用微做事化后涌现数据同等性问题概率远大于单体运用，从进程内调用到网络调用这种繁芜的环境加剧了非常场景的产生，做事跳数的增多使得在涌现业务处理非常时无法协同高下游做事同时进行数据回滚。TXC 的出身正是为理解决运用架构层数据同等性的痛点问题，TXC 核心要办理的数据同等性场景包括：
跨做事的同等性。应对系统非常如调用超时和业务非常时折衷高下游做事节点回滚。分库分表的数据同等性。应对业务层逻辑 SQL 操作的数据在不同数据分片上，担保其分库分表操作的内部事务。发送的数据同等性。应对数据操作和发送成功的不一致性问题。为了战胜以上通用场景碰着的问题，TXC 与三大件做了无缝集成。业务利用三大件开拓时，完备感知不到背后 TXC 的存在，业务不须要考虑数据同等性的设计问题，数据同等性担保交给了框架托管，业务更加聚焦于业务本身的开拓，极大的提升了开拓的效率。
TXC 已在阿里集团内部广泛运用多年，经由双 11 等大型活动的洪荒流量洗礼，TXC 极大提高了业务的开拓效率，担保了数据的精确性，肃清了数据不一致导致的资损和商誉问题。随着架构的不断演进，标准的三节点集群已可以承载靠近 10W TPS 的峰值和毫秒级事务处理。在可用性和性能方面都达到了 4 个 9 的 SLA 担保，纵然在无值守状态下也能担保整年无端障。
分布式事务的演进
新事物的出身总是会伴随着质疑的声音。中间件层来担保数据同等性到底可靠吗？TXC 最初的出身只是一种模糊的理论，缺少理论模型和工程实践。在我们进行 MVP（最小可行产品）模型测试并推广业务上线后，常常涌现故障，常常须要在深夜起床处理问题，睡觉时要佩戴手环来应对紧急相应，这也是我接管这个团队在技能上过的最痛楚的几年。
随后，我们进行了广泛的谈论和系统梳理。我们首先须要定义同等性问题，我们是要像 RAFT 一样实现多数共识同等性，还是要像 Google Spanner 一样办理数据库同等性问题，还是其他办法？从运用节点自上而下的分层构造来看，紧张包括开拓框架、做事调用框架、数据中间件、数据库 Driver 和数据库。我们须要决定在哪一层办理数据同等性问题。我们比较理解决不同层次数据同等性问题所面临的同等性哀求、通用性、实现繁芜度和业务接入本钱。末了，我们权衡利弊，把实现繁芜度留给我们，作为一个同等性组件，我们须要确保较高的同等性，但又不能锁定到详细数据库的实现上，确保场景的通用性和业务接入本钱足够低以便更随意马虎实现业务，这也是 TXC 最初采取 AT 模式的缘故原由。
分布式事务它不仅仅是一个框架，它是一个体系。我们在理论上定义了同等性问题，观点上抽象出了模式、角色、动作和隔离性等。从工程实践的角度，我们定义了编程模型，包括低侵入的表明、大略的方法模板和灵巧的 API，定义了事务的根本能力和增强能力（例如如何以低本钱支持大量活动），以及运维、安全、性能、可不雅观测性和高可用等方面的能力。
分布式事务办理了哪些问题呢？一个经典且具有体感的例子便是转账场景。转账过程包括减去余额和增加余额两个步骤，我们如何担保操作的原子性？在没有任何干预的情形下，这两个步骤可能会碰着各种问题，例如 B 账户已销户或涌现做事调用超时等情形。
超时问题一贯是分布式运用中比较难办理的问题，我们无法准确知晓 B 做事是否实行以及其实行顺序。从数据的角度来看，这意味着 B 账户的钱未必会被成功加起来。在做事化改造之后，每个节点仅获知部分信息，而事务本身须要全局折衷所有节点，因此须要一个拥有上帝视角、能够获取全部信息的中央化角色，这个角色便是 TC（transaction coordinator），它用于全局折衷事务的状态。TM（Transaction Manager）则是驱动事务天生发起的角色。
但是，纵然上帝也有打瞌睡儿的时候，他的判断也并不总是精确的，因此须要一个 RM（resource manager）角色作为灵魂的代表来验证事务的真实性。这便是 TXC 最基本的哲学模型。我们从方法论上验证了它的数据同等性是非常完备的，当然，我们的认知是有边界的。大概未来会证明我们是火鸡工程师，但在当前情形下，它的模型已经足以办理大部分现有问题。
经由多年的架构演进，从事务的单链路耗时角度来看，TXC 在事务开始时的处理均匀韶光约为 0.2 毫秒，分支注册的均匀韶光约为 0.4 毫秒，全体事务额外的耗时在毫秒级别之内。这也是我们推算出的极限理论值。在吞吐量方面，单节点的 TPS 达到 3 万次/秒，标准集群的 TPS 靠近 10 万次/秒。
Seata 开源
为什么要做开源？这是很多人问过我的问题。2017 年我们做了商业化的 GTS（Global Transaction Service）产品产品在阿里云上售卖，有公有云和专有云两种形态。此时集团内发展的顺利，但是在我们商业化的过程中并不顺利，我们碰着了各种各样的问题，问题总结起来紧张包括两类：一是开拓者对付分布式事务的理论相称匮乏，大多数人连本地事务都没搞明白是怎么回事更何况是分布式事务。二是产品成熟度上存在问题，常常碰着稀奇古怪的场景问题，导致了支持交付本钱的急剧上升，研发变成了售后客服。
我们反思为什么碰着如此多的问题，这里紧张的问题是在阿里集团内部是统一措辞栈和统一技能栈的，我们对特定场景的打磨是非常成熟的，做事阿里一家公司和做事云上成千上万家企业有实质的差异，这也启迪我们产品的场景生态做的不足好。在 GitHub 80% 以上的开源软件是根本软件，根本软件紧张办理的是场景通用性问题，因此它不能被有一家企业 Lock In，比如像 Linux，它有非常多的社区分发版本。因此，为了让我们的产品变得更好，我们选择了开源，与开拓者们共建、遍及更多的企业用户。
阿里的开源经历了三个紧张阶段。第一个阶段是 Dubbo 所处的阶段，开拓者用爱发电，Dubbo 开源了有十几年的韶光，韶光充分证明了 Dubbo 是非常精良的开源软件，它的微内核插件化的扩展性设计也是我最初开源 Seata 的主要参考。做软件设计的时候我们要思考扩展性和性能权衡起来哪个会更主要一些，我们到底是要做一个三年的设计，五年的设计亦或是知足业务发展的十年设计。我们在做 0-1 做事调用问题的办理方案的同时，能否预测到 1-100 规模化后的管理问题。
第二个阶段是开源和商业化的闭环，商业化反哺于开源社区，促进了开源社区的发展。我认为云厂商更随意马虎做好开源的缘故原由如下：
首先，云是一个规模化的经济，一定要建立在稳定成熟的内核根本上，在上面去包装其产品化能力包括高可用、免运维和弹性能力。不稳定的内核一定导致过高的交付支持本钱，研发团队的支持答疑穿透过高，过高的交付本钱无法实现大规模的复制，穿透率过高无法使产品快速的演进迭代。
其次，商业产品是更懂业务需求的。我们内部团队做技能的常常是站在研发的视角 YY 需求，做出来的东西没有人利用，也就不会形成代价的转换。商业化网络到的都是真实的业务需求，因此，它的开源内核也必须会朝着这个方向演进。如果不朝着这个方向去演进一定导致两边架构上的分裂，增加团队的掩护本钱。
末了，开源和商业化闭环，能促进双方更好的发展。如果开源内核常常涌现各种问题，你是否乐意相信的它的商业化产品是足够精良的。
第三个阶段是体系化和标准化。首先，体系化是开源办理方案的根本。阿里的开源项目大多是基于内部电阛阓景的实践而出身的。例如 Higress，它用于打通蚂蚁集团的网关；Nacos 承载着做事的百万实例和千万连接；Sentinel 供应大匆匆时的降级和限流等高可用性能力；而 Seata 卖力保障交易数据的同等性。这套体系化的开源办理方案是基于阿里电商生态的最佳实践而设计的。其次，标准化是另一个主要的特点。以 OpenSergo 为例，它既是一个标准，又是一个实现。在过去几年里，海内开源项目数量呈爆发式增长。然而，各个开源产品的能力差异很大，彼此集成时会碰着许多兼容性问题。因此，像 OpenSergo 这样的开源项目能够定义一些标准化的能力和接口，并供应一些实现，这将为全体开源生态系统的发展供应极大的帮助。
Seata 社区最新进展Seata 社区简介
目前，Seata 已经开源了 4 种事务模式，包括 AT、TCC、Saga 和 XA，并在积极探索其他可行的事务办理方案。Seata 已经与 10 多个主流的 RPC 框架和关系数据库进行了集成，同时与 20 多个社区存在集成和被集成的关系。此外，我们还在多措辞体系上探索除 Java 之外的措辞，如 Golang、PHP、Python 和 JS。Seata 已经被几千家客户运用到业务系统中。
Seata 的运用已经变得越来越成熟，在金融业务场景中信银行和光大银行与社区做了很好的互助，并成功将其纳入到核心账务系统中。在金融场景对微做事体系的落地是非常严苛的，这也标志着 Seata 的内核成熟度迈上了一个新台阶。
Seata 扩展生态
Seata 采取了微内核和插件化的设计，它在 API、注册配置中央、存储模式、锁掌握、SQL 解析器、负载均衡、传输、协议编解码、可不雅观察性等方面暴露了丰富的扩展点。这使得业务可以方便地进行灵巧的扩展和技能组件的选择。
Seata 运用案例
案例1：中航信航旅纵横项目中航信航旅纵横项目在 Seata 0.2 版本中引入 Seata 办理机票和优惠券业务的数据同等性问题，大大提高了开拓效率、减少了数据不一致造成的资损并提升了用户交互体验。
案例2：滴滴出行二轮车奇迹部滴滴出行二轮车奇迹部在 Seata 0.6.1 版本中引入 Seata，办理了小蓝单车、电动车、资产等业务流程的数据同等性问题，优化了用户利用体验并减少了资产的丢失。案例3：美团根本架构美团根本架构团队基于开源的 Seata 项目开拓了内部分布式事务办理方案 Swan，被用于办理美团内部各业务的分布式事务问题。
案例4：盒马小镇盒马小镇在游戏互动中利用 Seata 掌握偷花的流程，开拓周期大大缩短，从 20 天缩短到了 5 天，有效降落了开拓本钱。
Seata 事务模式的演进
Seata 当提高展支持 Oracle和 Postgresql 多主键。支持 Dubbo3支持 Spring Boot3支持 JDK 17支持 ARM64 镜像支持多注册模型扩展了多种 SQL 语法支持 GraalVM Native Image支持 Redis lua 存储模式
Seata 2.x 发展方案紧张包括下面几个方面：
存储/协议/特性存储模式上探索存算不分离的 Raft 集群模式；更好的体验，统一当前 4 种事务模式的 API；兼容 GTS 协议；支持 Saga 表明；支持分布式锁的掌握；支持以数据视角的洞察和管理。生态领悟支持更多的数据库，更多的做事框架，同时探索国产化信创生态的支持；支持 MQ 生态；进一步完善 APM 的支持。办理方案办理方案上除了支持微做事生态探索多云方案；更贴近云原生的办理方案；增加安全和流量防护能力；实现架构上核心组件的自闭环收敛。多措辞生态多措辞生态中 Java 最成熟，其他已支持的编程措辞连续完善，同时探索与措辞无关的 Transaction Mesh 方案。研发效能/体验提升测试的覆盖率，优先担保质量、兼容性和稳定性；重构官网文档构造，提升文档搜索的命中率；在体验上简化运维支配，实现一键安装和配置元数据简化；掌握台支持事务掌握和在线剖析能力。一句话总结 2.x 的方案：更大的场景，更大的生态，从可用到好用。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开拓者社区不拥有其著作权，亦不承担相应法律任务。详细规则请查看《阿里云开拓者社区用户做事协议》和《阿里云开拓者社区知识产权保护指引》。如果您创造本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将急速删除涉嫌侵权内容。
