一尘不染

Axon Framework:具有两个或三个微服务之间的补偿事件的Saga项目

spring-boot

我对轴突佐贺有疑问。我有一个项目,其中有三个微服务,每个微服务都有自己的数据库,但是两个“从”微服务必须将其数据共享给“主”微服务,因此我想使用Axon
Saga。我已经问过有关补偿的问题,当出现问题时,我必须自己处理补偿,这是可以的,但并不理想。目前,我正在使用DistributedCommandBus在微服务之间进行通信,这是否有益?我正在使用Choreography
Saga模型,所以现在是这样:

  1. 主站->发送命令->从站1->处理事件
  2. 从站1->发送回命令->主站->处理事件
  3. 主站->发送命令->从站2->处理事件
  4. 从站2->发送命令->主站->处理事件

如果出现问题,则补偿命令/事件会向后退。

我的问题是,有人在薪酬方面对Axon做过这样的事情吗,最佳做法是什么?如何重试Saga流程?使用RetryScheduler?如果可以的话,添加一个github仓库。

谢了哥们


阅读 741

收藏
2020-05-30

共1个答案

一尘不染

首先,让我回答您的主要问题:

我的问题是有人用Axon做过类似的事情吗?

很快,是的,因为这是Sagas的主要用例之一。根据经验,我想说明Saga可用于 协调以下 之间 的复杂业务交易

  1. 几个不同的聚合实例
  2. 几个有限的上下文

从表面上看,您似乎已经进入了委派复杂业务交易的第二种选择。

重要的是要注意,在使用Sagas时,您应该 非常有意识地 处理 任何 异常和/或命令调度结果。

因此,如果您从“主站”向“从站1”发送命令,而后者却使操作失败,则该结果 将返回 到Saga。因此,这为您提供了重试操作的第一种选择,我建议您使用
补偿操作 。最后,通过补偿动作,我正在谈论调度命令来触发它。

如果您不能依靠调度命令的直接响应,那么在Saga中重试/重新调度消息将是第二种合理的选择。

为此,Axon具有EventSchedulerDeadlineManager。请注意,两者中的前者会发布一个事件 ,以供所有人查看
。后者DeadlineMessage在单个Saga实例的上下文中调度a ,从而限制了可以看到重试的范围。

通常,这DeadlineManager将是我的首选操作方式,除非您要求每个人都可以看到此“重新安排动作”。仅供参考,请在页面上获取EventScheduler信息,并在页面上获取DeadlineManager信息。

2020-05-30