2. Fescar 的发展历程

阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。

2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。

2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service） 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。

2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。

TXC/GTS/Fescar 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。

2.1 设计初衷

高速增长的互联网时代，快速试错 的能力对业务来说是至关重要的：

一方面，不应该因为技术架构上的微服务化和分布式事务支持的引入，给业务层面带来额外的研发负担。
另一方面，引入分布式事务支持的业务应该基本保持在同一量级上的性能表现，不能因为事务机制显著拖慢业务。
基于这两点，我们设计之初的最重要的考量就在于：
对业务无侵入： 这里的侵入是指，因为分布式事务这个技术问题的制约，要求应用在业务层面进行设计和改造。这种设计和改造往往会给应用带来很高的研发和维护成本。我们希望把分布式事务问题在 中间件 这个层次解决掉，不要求应用在业务层面做额外的工作。
高性能： 引入分布式事务的保障，必然会有额外的开销，引起性能的下降。我们希望把分布式事务引入的性能损耗降到非常低的水平，让应用不因为分布式事务的引入导致业务的可用性受影响。

既有的分布式事务解决方案按照对业务侵入性分为两类，即：对业务无侵入的和对业务有侵入的。

既有的主流分布式事务解决方案中，对业务无侵入的只有基于 XA 的方案，但应用 XA 方案存在 3 个方面的问题：

要求数据库提供对 XA 的支持。如果遇到不支持 XA（或支持得不好，比如 MySQL 5.7 以前的版本）的数据库，则不能使用。
受协议本身的约束，事务资源（数据记录、数据库连接）的锁定周期长。长周期的资源锁定从业务层面来看，往往是不必要的，而因为事务资源的管理器是数据库本身，应用层无法插手。这样形成的局面就是，基于 XA 的应用往往性能会比较差，而且很难优化。
已经落地的基于 XA 的分布式解决方案，都依托于重量级的应用服务器（Tuxedo/WebLogic/WebSphere 等)，这是不适用于微服务架构的。

实际上，最初分布式事务只有 XA 这个唯一方案。XA 是完备的，但在实践过程中，由于种种原因（包含但不限于上面提到的 3 点）往往不得不放弃，转而从业务层面着手来解决分布式事务问题。比如：

基于可靠消息的最终一致性方案
TCC
Saga
都属于这一类。这些方案的具体机制在这里不做展开，网上这方面的论述文章非常多。总之，这些方案都要求在应用的业务层面把分布式事务技术约束考虑到设计中，通常每一个服务都需要设计实现正向和反向的幂等接口。这样的设计约束，往往会导致很高的研发和维护成本。

不可否认，侵入业务的分布式事务方案都经过大量实践验证，能有效解决问题，在各行各业的业务应用系统中起着重要作用。但回到原点来思考，这些方案的采用实际上都是 迫于无奈。设想，如果基于 XA 的方案能够不那么重，并且能保证业务的性能需求，相信不会有人愿意把分布式事务问题拿到业务层面来解决。

一个理想的分布式事务解决方案应该：像使用 本地事务 一样简单，业务逻辑只关注业务层面的需求，不需要考虑事务机制上的约束。