基于 Seata Saga 设计更有弹性的金融应用

Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式，本文详解其中的 Saga 模式。

项目地址：https://github.com/seata/seata

本文作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。

金融分布式应用开发的痛点

分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。---《左耳听风-弹力设计之“补偿事务”》

而在金融领域微服务架构下的业务流程往往会更复杂，流程很长，比如一个互联网微贷业务流程调十几个服务很正常，再加上异常处理的流程那就更复杂了，做过金融业务开发的同学会很有体感。

所以在金融分布式应用开发过程中我们面临一些痛点：

• 业务一致性难以保障

 

我们接触到的大多数业务（比如在渠道层、产品层、集成层的系统），为了保障业务最终一致性，往往会采用“补偿”的方式来做，如果没有一个协调器来支持，开发难度是比较大的，每一步都要在 catch 里去处理前面所有的“回滚”操作，这将会形成“箭头形”的代码，可读性及维护性差。或者重试异常的操作，如果重试不成功可能要转异步重试，甚至最后转人工处理。这些都给开发人员带来极大的负担，开发效率低，且容易出错。

• 业务状态难以管理

 

业务实体很多、实体的状态也很多，往往做完一个业务活动后就将实体的状态更新到了数据库里，没有一个状态机来管理整个状态的变迁过程，不直观，容易出错，造成业务进入一个不正确的状态。

• 幂等性难以保障

 

服务的幂等性是分布式环境下的基本要求，为了保证服务的幂等性往往需要服务开发者逐个去设计，有用数据库唯一键实现的，有用分布式缓存实现的，没有一个统一的方案，开发人员负担大，也容易遗漏，从而造成资损。

• 业务监控运维难，缺乏统一的差错守护能力

 

业务的执行情况监控一般通过打印日志，再基于日志监控平台查看，大多数情况是没有问题的，但是如果业务出错，这些监控缺乏当时的业务上下文，对排查问题不友好，往往需要再去数据库里查。同时日志的打印也依赖于开发，容易遗漏。对于补偿事务往往需要有“差错守护触发补偿”、“工人触发补偿”操作，没有统一的差错守护和处理规范，这些都要开发者逐个开发，负担沉重。

理论基础

一些场景下，我们对数据有强一致性的需求时，会采用在业务层上需要使用“两阶段提交”这样的分布式事务方案。而在另外一些场景下，我们并不需要这么强的一致性，那就只需要保证最终一致性就可以了。

例如蚂蚁金服目前在金融核心系统使用的就是 TCC 模式，金融核心系统的特点是一致性要求高（业务上的隔离性）、短流程、并发高。

而在很多金融核心以上的业务（比如在渠道层、产品层、集成层的系统），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务（如金融网络）。这是如果每个服务都开发 Try、Confirm、Cancel 三个方法成本高。如果事务中有其它公司的服务，也无法要求其它公司的服务也遵循 TCC 这种开发模式。同时流程长，事务边界太长会影响性能。

对于事务我们都知道 ACID，也很熟悉 CAP 理论最多只能满足其中两个，所以，为了提高性能，出现了 ACID 的一个变种 BASE。ACID 强调的是一致性（CAP 中的 C），而 BASE 强调的是可用性（CAP 中的 A）。我们知道，在很多情况下，我们是无法做到强一致性的 ACID 的。特别是我们需要跨多个系统的时候，而且这些系统还不是由一个公司所提供的。BASE 的系统倾向于设计出更加有弹力的系统，在短时间内，就算是有数据不同步的风险，我们也应该允许新的交易可以发生，而后面我们在业务上将可能出现问题的事务通过补偿的方式处理掉，以保证最终的一致性。

所以我们在实际开发中会进行取舍，对于更多的金融核心以上的业务系统可以采用补偿事务，补偿事务处理方面在30年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较也公认 Saga 是作为长事务的解决方案。

https://github.com/aphyr/dist-sagas/blob/master/sagas.pdf