技术界喜讯频传，继 GitHub 开放无限免费私有仓库后，阿里巴巴于近期正式开源了其核心的分布式事务解决方案 —— Fescar（后更名为
Seata），并发布了首个开源版本 v0.1.0。这为长期受困于微服务数据一致性难题的开发者们提供了一个强有力的新选项。

项目地址：

https://github.com/alibaba/fescar (注：现已迁移至 Seata)

Fescar / Seata 是什么？
Fescar（Fast & EaSy Commit And Rollback，后更名为 Seata - Simple Extensible Autonomous Transaction
Architecture）是一款面向微服务架构的高性能、易用型分布式事务解决方案。其设计目标是在分布式环境下，像使用本地事务一样简单高效地实现全局事务的提交与回滚。

微服务下的分布式事务挑战：
在传统的单体应用中，所有模块共享一个数据库，利用数据库的本地事务即可轻松保证数据一致性。

然而，在微服务架构下，业务被拆分为多个独立服务，每个服务拥有独立的数据库。此时，虽然每个服务内部可以通过本地事务保证自身数据一致，但如何确保跨越多个服务、多个数据库的整个业务逻辑的数据一致性，成为一个经典难题。

Fescar / Seata 的核心解决机制
Fescar 通过“两阶段提交”的改进模型——“AT模式”（Automatic Transaction）来解决上述问题。其核心思想是：将一个分布式事务拆分为一个全局事务（Global
Transaction）和若干个分支事务（Branch Transaction），分支事务即各个微服务的本地事务。

如下图所示，全局事务管理者负责协调所有分支事务的最终提交或回滚。

三大核心角色
Transaction Coordinator (TC - 事务协调器)：
维护全局事务和分支事务的状态，驱动全局提交或回滚。它是独立部署的服务器组件。

Transaction Manager (TM - 事务管理器)：
定义全局事务的边界，负责开启、提交或回滚全局事务。它嵌入在应用程序中。

Resource Manager (RM - 资源管理器)：
管理分支事务相关的资源（如数据库连接），负责向TC注册分支事务、报告状态，并驱动分支事务的提交或回滚。它作为一个中间件层拦截并处理数据库操作。

分布式事务的典型生命周期
事务发起：TM 向 TC 申请发起一个全局事务，TC 生成一个全局唯一的 XID（事务ID）。

ID传播：XID 随着微服务调用链在上下文中传播。

分支注册：RM 在处理业务时，将本地事务作为该 XID 的一个分支事务注册到 TC。

全局决议：业务执行完毕，TM 根据结果向 TC 发起全局提交或回滚请求。

驱动完成：TC 根据决议，驱动所有相关的 RM 完成分支事务的最终提交或回滚。

项目的演进历程
TXC (2014)：项目起源，名为“淘宝事务构造器”，用于解决阿里内部微服务化初期的分布式事务问题。

GTS (2016)：TXC 产品化，更名为“全局事务服务”(Global Transaction Service)，成为阿里云中间件的商业产品。

Fescar / Seata (2019)：基于 TXC/GTS 的深厚积累，阿里巴巴决定将其核心代码开源，普惠整个开发者社区，后正式定名为 Seata。

阿里将如此核心的商业级解决方案开源，无疑是 2019 年对技术社区的一份厚礼，也预示着云原生与微服务生态将迎来更成熟的基础设施。

参考链接：

github.com/alibaba/fescar (Seata 前身)

seata.io (当前官方网站)