试试SAGA

项目中遇到多个微服务调用需要考虑和处理某个环节失败时的处理。虽然这里不需要很强的事务概念，但是需要对失败的动作进行重试等操作。这里的重试本质上就是rollback的另一种形式，在saga里算是“forward recovery”。

借机又翻看了一下相关的文章，贴到了文末。

Saga vs TCC

1) Saga相比TCC的缺点是缺少预留动作，所以某些情况补偿的实现比较麻烦甚至无法撤销只能补救。不过没有预留动作也意味着不必担心资源释放的问题。 2) TCC最少通信次数为2n，Saga为n（n=sub-transaction的数量）。 3) 第三方服务没需要提供有Try接口。 总体感觉下来SAGA更适合微服务的多数场景。

试用 Saga 思想

解决这类问题当然可以直接引入一些已存在的saga框架，不过这里存在学习、部署等成本。如果只是小范围的解决问题，或许可以使用下面的形式。

上面示意图针对的场景是：服务的执行都需要较长时间、并且是异步调用。

如果各个服务执行时间都不长，一个调用链下来小于几百毫秒，那么直接使用reactive style的编码也应该可以。

因为各服务执行时间较长，所以不能使用同步调用。这里耗时指的是对于有UI的程序至少影响到到UI前的用户，如果是后台应用那么至少阻塞的时长影响到系统的资源可用性。

即使服务执行时间短，同步调用也会使调用链的availability降低，所以微服务的场景下使用异步调用有天然的好处。

从这个示意图其实可以看作是Chris演讲中提到的最最原始的模式。 可以把callback看作是saga事务参与方发送消息到"message broker"。而调用链的第一个节点就充当了saga的协调者。 各个微服务的updateStatus端点就是message的listner，只不过这里直接通过callback实现而没有利用消息队列。 最开始的endpoint负责生成一个transactionId并依次传递给每个下游服务，每个下游服务通过callback把自己的状态更新给上游。

关于服务上的endpoints:

1) getStatus() 端点提供给UI获取当前状态.

2) transCheckAndAmend(trans_n) 每个服务暴露的业务方法都需要提供一个补偿方法。

1. 服务的入口方法其实充当了协调者, 更像orchestration的，而不是choreography的。
2. Timer 是个后台定时器不停的检查服务状态，如果状态不成功就调用compensating endpoint.

Reference: [1]: Saga的经典论文 https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf [2]: 《Microservice Pattern》”Chapter4, Managing transactions with sagas” [3]: Chris Richardson 在2017年的演讲：https://www.youtube.com/watch?v=YPbGW3Fnmbc

一些网文： [3] 分布式事务：Saga模式 https://www.jianshu.com/p/e4b662407c66 [4] 七种分布式事务的解决方案 https://cloud.tencent.com/developer/article/1806989 [5] 分布式事务六种解决方案 https://zhuanlan.zhihu.com/p/183753774