Apache ServiceComb 的微服务数据最终一致性解决方案 Saga 演进

摘要: 微服务开源项目 Apache ServiceComb(incubating) 的微服务事务的数据一致性解决方案 Saga[4]（以下简称Saga）进行了演进。相对于上一版[2]，新演进的设计主要有以下优势：极大提升易用性。开发者只需使用2-3个注解（即启用事务服务：EnableOmega、全局事务标记：SagaStart和子事务标记：Compensable）。更方便扩展。对微服务框架的支持更友好。数据一致性与业务逻辑解耦。在演进后的设计中，通过服务侧omega的引入，saga协调器的职责更为单一（只需负责协调事务的完整性），与具体业务无关，因此，开发人员可以聚焦在具体业务的开发。

本文转自微服务开源项目 Apache ServiceComb 的官方博客：http://servicecomb.incubator.apache.org/cn/docs/saga_pack_design/

传统的单体应用的微服务化改造过程中大多会面临数据库拆分，故而原来由数据库保证的数据一致性也一定面临重新设计和实现，此时需要引入分布式数据一致性方案来解决。常见的解决方案主要有2PC，TCC，事件驱动等，而在微服务开源项目 ServiceComb中提出并实现了使用Saga[1]来解决微服务的数据一致性难题，不同方案的对比可参考《ServiceComb中的数据最终一致性方案》[2]一文。Saga是一个数据最终一致性的解决方案，它允许我们成功地执行所有事务，或在任何事务失败的情况下，补偿已成功的事务，并提供了ACID[3]中ACD的保证（由于事务是交错执行的，可能会看到其他事务的部分结果，因此不能满足隔离性要求）。因此，Saga适用于以下跨服务的事务场景：

嵌套调用。如网上购物时，会依次经过下单、支付服务和第三方支付这几个子事务，其中，下单依赖于支付服务的返回状态，而支付服务也包含了多种可选的支付方式，并依赖于具体支付方式返回的结果。通过Saga，可以清晰地看到一个完整事务中各个服务之间的关系，在异常时也能快速定位出现问题的子事务。
高并发。如秒杀场景下，在成功扣除库存和完成支付后方可认为秒杀成功，若成功扣除库存但支付失败则自动进行补偿（即恢复库存）。鉴于Saga只有提交和补偿两种状态，成功场景下只需对每个子事务进行一次调用即可，因此可以在高并发下保持高性能。
调用时间长。如线上购买电影票，选好座位后一般会有15分钟的支付时间。Saga仅在子事务的提交阶段对资源进行短暂的锁定，且通过超时机制确保事务超时后能自动补偿，即在规定时间内没有支付成功的话就自动释放锁定的座位，极大地简化了业务出现异常时的处理逻辑。

Saga新版本演进

新年新气象，Apache ServiceComb(incubating) Saga[4]（以下简称Saga）进行了演进。相对于上一版[2]，新演进的设计主要有以下优势：

极大提升易用性。开发者只需使用2-3个注解（即启用事务服务：EnableOmega、全局事务标记：SagaStart和子事务标记：Compensable）。
更方便扩展。对微服务框架的支持更友好。
数据一致性与业务逻辑解耦。在演进后的设计中，通过服务侧omega的引入，saga协调器的职责更为单一（只需负责协调事务的完整性），与具体业务无关，因此，开发人员可以聚焦在具体业务的开发。

Saga演进后的架构，如下图所示，主要包含两个组件，即alpha和omega，其中：

alpha充当协调者的角色，主要负责对事务的事件进行持久化存储以及协调子事务的状态，使其最终得以与全局事务的状态保持一致，即保证事务中的子事务要么全执行，要么全不执行。
omega是微服务中内嵌的一个agent，负责对网络请求进行拦截并向alpha上报事务事件，并在异常情况下根据alpha下发的指令执行相应的补偿或重试操作。