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

我有一个关于 Axon Saga 的问题。我有一个项目，其中有三个微服务，每个微服务都有自己的数据库，但是两个“从属”微服务必须将其数据共享给“主”微服务，为此我想使用 Axon Saga。我已经问过关于赔偿的问题，出了问题，我必须自己处理赔偿，还可以，但不太理想。目前我正在使用 DistributedCommandBus 在微服务之间进行通信，这有好处吗？我正在使用 Choreography Saga 模型，所以它现在的样子是这样的：

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

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

我的问题是，是否有人对 Axon 做过类似的事情，并有补偿，最佳做法是什么？我如何重试 Saga 进程？使用重试调度程序？如果可以的话添加一个 github 存储库。

谢了哥们

首先，让我回答你的主要问题：

我的问题是有人对 Axon 做过类似的事情吗？

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

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

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

需要注意的是，当你使用 Sagas 时，你应该非常有意识地处理any异常和/或命令调度结果。

因此，如果您从“Master”向“Slave 1”发送命令，而后者操作失败，则会出现以下结果将会回来进入佐贺。 因此，这为您提供了重试操作的第一个选项，我建议使用补偿动作。 最后，通过补偿操作，我正在讨论发送命令来触发它。

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

为此，Axon 拥有EventScheduler and DeadlineManager。 请注意，两者中的前者发布了一个事件给大家看。 后者安排了DeadlineMessage在单个 Saga 实例的上下文中，从而限制了谁可以看到正在发生重试的范围。

通常，DeadlineManager因此，这将是我的首选操作模式，除非您要求每个人都看到这种“重新安排行动”。 仅供参考，检查this https://docs.axoniq.io/reference-guide/implementing-domain-logic/complex-business-transactions/deadline-handling页面为EventScheduler信息与this https://docs.axoniq.io/reference-guide/configuring-infrastructure-components/deadlines页面为DeadlineManager info.

示例更新

下面是一些伪代码，可以让您了解 Saga 事件处理程序中的补偿操作是什么样子的：

class SomeSaga {

    private CommandGateway commandGateway;

    @SagaEventHandler(assocationValue = "some-key")
    public void on(SomeEvent event) {
        // perform some checks, validation and state setting, if necessary
        commandGateway.send(new MyActionCommand(...))
                      .exceptionally(throwable -> {
                                         commandGateway.send(new CompensatingAction(...));
                                     });
    }
}