概述
servicecomb-saga是一个微服务应用的数据最终一致性解决方案,是一种基于在2PC和TCC两者之间的框架,简单的说是依赖协调器的TCC方式。
特性
- 高可用。支持集群模式。
- 高可靠。所有的事务事件都持久存储在数据库中。
- 高性能。事务事件是通过gRPC来上报的,且事务的请求信息是通过Kyro进行序列化和反序列化的。
- 低侵入。仅需2-3个注解和编写对应的补偿方法即可进行分布式事务。
- 部署简单。可通过Docker快速部署。
- 支持前向恢复(重试)及后向恢复(补偿)。
saga架构图
- alpha充当协调者的角色,主要负责对事务的事件进行持久化存储以及协调子事务的状态,使其得以最终与全局事务的状态保持一致。
- omega是微服务中内嵌的一个agent,负责对网络请求进行拦截并向alpha上报事务事件,并在异常情况下根据alpha下发的指令执行相应的补偿操作。
Omega内部运行机制
omega是微服务中内嵌的一个agent。当服务收到请求时,omega会将其拦截并从中提取请求信息中的全局事务id作为其自身的全局事务id(即Saga事件id),并提取本地事务id作为其父事务id。在预处理阶段,alpha会记录事务开始的事件;在后处理阶段,alpha会记录事务结束的事件。因此,每个成功的子事务都有一一对应的开始及结束事件。
服务间通信流程
服务间通信的流程与Zipkin的类似。在服务生产方,omega会拦截请求中事务相关的id来提取事务的上下文。在服务消费方,omega会在请求中注入事务相关的id来传递事务的上下文。通过服务提供方和服务消费方的这种协作处理,子事务能连接起来形成一个完整的全局事务。
具体处理流程
成功场景
成功场景下,每个开始的事件都会有对应的结束事件。
异常场景
异常场景下,omega会向alpha上报中断事件,然后alpha会向该全局事务的其它已完成的子事务发送补偿指令,确保最终所有的子事务要么都成功,要么都回滚。
超时场景
超时场景下,已超时的事件会被alpha的定期扫描器检测出来,与此同时,该超时事务对应的全局事务也会被中断。
QuickStart
引入Saga的依赖
org.apache.servicecomb.saga
omega-spring-starter
${saga.version}
org.apache.servicecomb.saga
omega-transport-resttemplate
${saga.version}
注意: 请将${saga.version}更改为实际的版本号。
添加Saga的注解及相应的补偿方法
以一个转账应用为例:
- 在应用入口添加 @EnableOmega 的注解来初始化omega的配置并与alpha建立连接。
@SpringBootApplication
@EnableOmega
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
- 在全局事务的起点添加 @SagaStart 的注解。
@SagaStart(timeout=10)
public boolean transferMoney(String from, String to, int amount) {
transferOut(from, amount);
transferIn(to, amount);
}
注意: 默认情况下,超时设置需要显式声明才生效。
- 在子事务处添加 @Compensable 的注解并指明其对应的补偿方法。
@Compensable(timeout=5, compensationMethod="cancel")
public boolean transferOut(String from, int amount) {
repo.reduceBalanceByUsername(from, amount);
}
public boolean cancel(String from, int amount) {
repo.addBalanceByUsername(from, amount);
}
注意: 实现的服务和补偿必须满足幂等的条件。
注意: 默认情况下,超时设置需要显式声明才生效。
注意: 若全局事务起点与子事务起点重合,需同时声明 @SagaStart 和 @Compensable 的注解。
- 对转入服务重复第三步即可。
参考:https://github.com/apache/incubator-servicecomb-saga/