【转】微服务架构下的数据一致性保证（三）：补偿模式

在第一篇分享中介绍了微服务架构应满足数据最终一致性，并简要介绍了最终一致性的三种模式：可靠事件模式、补偿模式、TCC模式。

在第二篇分享中深入可靠事件模式，讲述了可靠事件投递和幂等性的实现方式和需要注意的问题。

在今天的第三篇分享中来谈谈补偿模式和TCC模式，主要从三个方面来谈。

•  实现补偿模式的关键在于业务流水的记录
• 通过重试保证补偿过程的完整，从而满足最终一致性
• TCC模式是优化的补偿模式

首先简单回顾一下补偿模式。

补偿模式使用一个额外的协调服务来协调各个需要保证一致性的微服务（我们称为工作服务），协调服务按顺序调用各个工作服务，如果某个工作服务调用失败就撤销之前所有已经完成的工作服务。要求需要保证一致性的工作服务提供补偿操作。

 

比如一家旅行公司通过协调3种工作服务为客户预订航班、预订酒店和预订火车。

当其中的预订火车失败时，就需要取消之前的航班和酒店的预订，这里面包含的三个工作服务都需要提供补偿操作。

为了降低开发的复杂性和提高效率，协调服务实现为一个通用的补偿框架。补偿框架提供服务编排和自动完成补偿的能力。

第一部分：实现补偿模式的关键在于业务流水的记录

要实现补偿过程，我们需要做到两点

1、首先要确定失败的步骤和状态，从而确定需要补偿的范围。

在上面的例子中我们不光要知道第3个步骤（预订火车）失败，还要知道失败的原因。如果是因为预订火车服务返回无票，那么补偿过程只需要取消前两个步骤就可以了；但是如果失败的原因是因为网络超时，那么补偿过程除前两个步骤之外还需要包括第3个步骤。

其次要能提供补偿操作使用到的业务数据。

比如一个支付微服务的补偿操作要求参数包括支付时的业务流水id、账号和金额。理论上说实际完成补偿操作可以根据唯一的业务流水id就可以，但是提供更多的要素有益于微服务的健壮性，微服务在收到补偿操作的时候可以做业务的检查，比如检查账户是否相等，金额是否一致等等。

做到上面两点的办法是记录完整的业务流水，可以通过业务流水的状态来确定需要补偿的步骤，同时业务流水为补偿操作提供需要的业务数据。

当客户的一个预订请求达到时，协调服务（补偿框架）为请求生成一个全局唯一的业务流水号。并在调用各个工作服务的同时记录完整的状态。

1.记录调用bookFlight的业务流水，调用bookFlight服务，更新业务流水状态

2.记录调用bookHotel的业务流水，调用bookHotel服务，更新业务流水状态

3.记录调用bookTrain的业务流水，调用bookTrain服务，更新业务流水状态

当调用某个服务出现异常时，比如第3步骤（预订火车）异常。

 

协调服务（补偿框架）同样会记录第3步的状态，同时会另外记录一条事件，说明业务出现了异常。然后就是执行补偿过程了，可以从业务流水的状态中知道补偿的范围，补偿过程中需要的业务数据从记录的业务流水中获取。

对于一个通用的补偿框架来说，预先知道微服务需要记录的业务要素是不可能的。那么就需要一种方法来保证业务流水的可扩展性，这里介绍两种方法：大表和关联表。

大表顾明思议就是设计时除必须的字段外，还需要预留大量的备用字段，框架可以提供辅助工具来帮助将业务数据映射到备用字段中。

关联表，分为框架表和业务表，技术表中保存为实现补偿操作所需要的技术数据，业务表保存业务数据，通过在技术表中增加业务表名和业务表主键来建立和业务数据的关联。

大表对于框架层实现起来简单，但是也有一些难点，比如预留多少字段合适，每个字段又需要预留多少长度。另外一个难点是如果向从数据层面来查询数据，很难看出备用字段的业务含义，维护过程不友好。

关联表在业务要素上更灵活，能支持不同的业务类型记录不同的业务要素；但是对于框架实现上难度更高，另外每次查询都需要复杂的关联动作，性能方面会受影响。

有了上面的完整的流水记录，协调服务就可以根据工作服务的状态在异常时完成补偿过程。

 

第二部分：通过重试来保证补偿过程的完整，从而满足最终一致性

补偿过程作为一个服务调用过程同样存在调用不成功的情况，这个时候需要通过重试的机制来保证补偿的成功率。当然这也就要求补偿操作本身具备幂等性。

如果只是一味的失败就立即重试会给工作服务造成不必要的压力，我们要根据服务执行失败的原因来选择不同的重试策略。

重试策略

 

1) 如果失败的原因不是暂时性的，由于业务因素导致（如业务要素检查失败）的业务错误，这类错误是不会重发就能自动恢复的，那么应该立即终止重试。

2) 如果错误的原因是一些罕见的异常，比如因为网络传输过程出现数据丢失或者错误，应该立即再次重试，因为类似的错误一般很少会再次发生。

3) 如果错误的原因是系统繁忙（比如http协议返回的500或者另外约定的返回码）或者超时，这个时候需要等待一些时间再重试。

 

重试操作一般会指定重试次数上线，如果重试次数达到了上限就不再进行重试了。这个时候应该通过一种手段通知相关人员进行处理。

对于等待重试的策略如果重试时仍然错误，可逐渐增加等待的时间，直到达到一个上限后，以上限作为等待时间。

如果某个时刻聚集了大量需要重试的操作，补偿框架需要控制请求的流量，以防止对工作服务造成过大的压力。

 

另外关于补偿模式还有几点补充说明

1.微服务实现补偿操作不是简单的回退到业务发生时的状态，因为可能还有其他的并发的请求同时更改了状态。一般都使用逆操作的方式完成补偿。

2.补偿过程不需要严格按照与业务发生的相反顺序执行，可以依据工作服务的重用程度优先执行，甚至是可以并发的执行。

3.有些服务的补偿过程是有依赖关系的，被依赖服务的补偿操作没有成功就要及时终止补偿过程。

4.如果在一个业务中包含的工作服务不是都提供了补偿操作，那我们编排服务时应该把提供补偿操作的服务放在前面，这样当后面的工作服务错误时还有机会补偿。

5.设计工作服务的补偿接口时应该以协调服务请求的业务要素作为条件，不要以工作服务的应答要素作为条件。因为还存在超时需要补偿的情况，这时补偿框架就没法提供补偿需要的业务要素。

 

第三部分：TCC模式是优化的补偿模式。

在补偿模式中一个比较明显的缺陷是，没有隔离性。从第一个工作服务步骤开始一直到所有工作服务完成（或者补偿过程完成），不一致是对其他服务可见的。另外最终一致性的保证还充分的依赖了协调服务的健壮性，如果协调服务异常，就没法达到一致性。

TCC模式在一定程度上弥补了上述的缺陷，在TCC模式中直到明确的confirm动作，所有的业务操作都是隔离的（由业务层面保证）。另外工作服务可以通过指定try操作的超时时间，主动的cancel预留的业务资源，从而实现自治的微服务。

TCC模式和补偿模式一样需要需要有协调服务和工作服务，协调服务也可以作为通用服务一般实现为框架。与补偿模式不同的是TCC服务框架不需要记录详细的业务流水，完成confirm和cancel操作的业务要素由业务服务提供。

TCC模式-confirm

 

在第4步确认预订之前，订单只是pending状态，只有等到明确的confirm之后订单才生效。

TCC模式-cancel

 

如果3个服务中某个服务try操作失败，那么可以向TCC服务框架提交cancel，或者什么也不做由工作服务自己超时处理。

TCC模式-heuristic exception

 

TCC模式也不能百分百保证一致性，如果业务服务向TCC服务框架提交confirm后，TCC服务框架向某个工作服务提交confirm失败（比如网络故障），那么就会出现不一致，一般称为heuristic exception。

需要说明的是为保证业务成功率，业务服务向TCC服务框架提交confirm以及TCC服务框架向工作服务提交confirm/cancel时都要支持重试，这也就要confirm/cancel的实现必须具有幂等性。如果业务服务向TCC服务框架提交confirm/cancel失败，不会导致不一致，因为服务最后都会超时而取消。

另外heuristic exception是不可杜绝的，但是可以通过设置合适的超时时间，以及重试频率和监控措施使得出现这个异常的可能性降低到很小。如果出现了heuristic exception是可以通过人工的手段补救的。

TCC的流程：

一个完整的 TCC 业务由一个主业务服务和若干个从业务服务组成，主业务服务发起并完成整个业务活动，TCC 模式要求从服务提供三个接口：Try、Confirm、Cancel。
1. Try
完成所有业务检查
预留必须业务资源
2. Confirm
真正执行业务
不作任何业务检查
只使用 Try 阶段预留的业务资源
Confirm 操作满足幂等性
3. Cancel：
释放 Try 阶段预留的业务资源
Cancel 操作满足幂等性
整个 TCC 业务分成两个阶段完成。
第一阶段：主业务服务分别调用所有从业务的 try 操作，并在活动管理器中登记所有从业务服务。当所有从业务服务的 try 操作都调用成功或者某个从业务服务的 try 操作失败，进入第二阶段。
第二阶段：活动管理器根据第一阶段的执行结果来执行 confirm 或 cancel 操作。
如果第一阶段所有 try 操作都成功，则活动管理器调用所有从业务活动的 confirm操作。否则调用所有从业务服务的 cancel 操作。
需要注意的是第二阶段 confirm 或 cancel 操作本身也是满足最终一致性的过程，在调用 confirm 或 cancel 的时候也可能因为某种原因（比如网络）导致调用失败，所以需要活动管理支持重试的能力，同时这也就要求 confirm 和 cancel 操作具有幂等性。
在补偿模式中一个比较明显的缺陷是，没有隔离性。从第一个工作服务步骤开始一直到所有工作服务完成（或者补偿过程完成），不一致是对其他服务可见的。另外最终一致性的保证还充分的依赖了协调服务的健壮性，如果协调服务异常，就没法达到一致性。
TCC模式在一定程度上弥补了上述的缺陷，在TCC模式中直到明确的confirm动作，所有的业务操作都是隔离的（由业务层面保证）。另外工作服务可以通过指定 try 操作的超时时间，主动的 cancel 预留的业务资源，从而实现自治的微服务。
TCC模式和补偿模式一样需要需要有协调服务和工作服务，协调服务也可以作为通用服务一般实现为框架。与补偿模式不同的是 TCC 服务框架不需要记录详细的业务流水，完成 confirm 和 cancel 操作的业务要素由业务服务提供。
在第4步确认预订之前，订单只是pending状态，只有等到明确的confirm之后订单才生效。
如果3个服务中某个服务try操作失败，那么可以向TCC服务框架提交cancel，或者什么也不做由工作服务自己超时处理。
TCC 模式也不能百分百保证一致性，如果业务服务向 TCC 服务框架提交 confirm后，TCC 服务框架向某个工作服务提交 confirm 失败（比如网络故障），那么就会出现不一致，一般称为 heuristic exception。
需要说明的是为保证业务成功率，业务服务向 TCC 服务框架提交 confirm 以及TCC 服务框架向工作服务提交 confirm/cancel 时都要支持重试，这也就要confirm/cancel 的实现必须具有幂等性。如果业务服务向 TCC 服务框架提交confirm/cancel 失败，不会导致不一致，因为服务最后都会超时而取消。
另外 heuristic exception 是不可杜绝的，但是可以通过设置合适的超时时间，以及重试频率和监控措施使得出现这个异常的可能性降低到很小。如果出现了heuristic exception 是可以通过人工的手段补救的。

转自：https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660392948&idx=1&sn=11602f1258af8bbf88322558aa8a2f21&scene=21#wechat_redirect