本文次要介绍分布式事务从外部到商业化和开源的演进历程，Seata 社区以后停顿和将来布局。
Seata 是一款开源的分布式事务解决方案，旨在为现代化微服务架构下的分布式事务提供解决方案。Seata 提供了残缺的分布式事务解决方案，包含 AT、TCC、Saga 和 XA 事务模式，可反对多种编程语言和数据存储计划。Seata 还提供了简便易用的 API，以及丰盛的文档和示例，不便企业在利用 Seata 时进行疾速开发和部署。
Seata 的劣势在于具备高可用性、高性能、高扩展性等特点，同时在进行横向扩大时也无需做额定的简单操作。目前 Seata 已在阿里云上几千家客户业务零碎中应用，其可靠性失去了业内各大厂商的认可和利用。
作为一个开源我的项目，Seata 的社区也在不断扩大，现已成为开发者交换、分享和学习的重要平台，也失去了越来越多企业的反对和关注。
明天我次要针对以下三个小议题对 Seata 进行分享：
- 从 TXC/GTS 到 Seata
- Seata 社区最新进展
- 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 计划。
- 研发效力 / 体验晋升测试的覆盖率，优先保证质量、兼容性和稳定性；重构官网文档构造，晋升文档搜寻的命中率；在体验上简化运维部署，实现一键装置和配置元数据简化；控制台反对事务管制和在线剖析能力。
作者：季敏（清铭）Seata 开源社区创始人，分布式事务团队负责人。
原文链接
本文为阿里云原创内容，未经容许不得转载。