作者：季敏（清铭）Seata 开源社区创始人，分布式业务团队负责人。
本文首要介绍分布式业务从内部到商业化和开源的演进历程，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 存储形式
Seata2.x 开展规划
首要包含下面几个方面：
-
存储/协议/特性 ****存储形式上探究存算不分离的 Raft 集群形式；更好的体会，一致当时 4 种业务形式的 API；兼容 GTS 协议；支撑 Saga 注解；支撑分布式锁的操控；支撑以数据视角的洞悉和治理。
-
生态 ****融合支撑更多的数据库，更多的服务结构，一起探究国产化信创生态的支撑；支撑 MQ 生态；进一步完善 APM 的支撑。
-
处理计划 ****处理计划上除了支撑微服务生态探究多云计划；更靠近云原生的处理计划；添加安全和流量防护才能；完成架构上中心组件的自闭环收敛。
-
多语言生态 ****多语言生态中 Java 最老练，其他已支撑的编程语言继续完善，一起探究与语言无关的 Transaction Mesh 计划。
-
研制效能/体会 ****提高测验的覆盖率，优先确保质量、兼容性和安稳性；重构官网文档结构，提高文档查找的命中率；在体会上简化运维布置，完成一键装置和装备元数据简化；操控台支撑业务操控和在线分析才能。
一句话总结 2.x 的规划：更大的场景，更大的生态，从可用到好用。
