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

Question

我有一个关于 Axon Saga 的问题。我有一个项目，其中有三个微服务，每个微服务都有自己的数据库，但是两个“从属”微服务必须将其数据共享给“主”微服务，为此我想使用 Axon Saga。我已经问过关于赔偿的问题，出了问题，我必须自己处理赔偿，还可以，但不太理想。目前我正在使用 DistributedCommandBus 在微服务之间进行通信，这有好处吗？我正在使用 Choreography Saga 模型，所以现在的样子是这样的：主站 -> 发送命令 -> 从站1 -> 处理事件Slave1 -> 发回命令 -> Master -> 处理事件Master -> 发送命令 -> Slave2 -> 处理事件Slave2 -> 发回命令 -> Master -> 处理事件如果出现问题，则会向后补偿命令/事件。我的问题是，是否有人对 Axon 做过类似的事情，并有补偿，最佳做法是什么？如何重试 Saga 进程？使用重试调度程序？如果可以的话添加一个 github 存储库。谢了哥们

Answer 1

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

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

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

1. 几个不同的聚合实例

2. 几种限界上下文

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

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

因此，如果您从“Master”向“Slave 1”发送命令，而后者操作失败，则该结果将返回到 Saga。因此，这为您提供了重试操作的第一个选项，我建议使用补偿操作来执行此操作。最后，通过补偿操作，我正在讨论发送命令来触发它。

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

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

通常，这DeadlineManager将是我首选的操作模式，除非您要求每个人都看到这种“重新安排操作”。

示例更新

下面是一些伪代码，可以让您了解 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(...));

                                     });

    }

}

Answer 2

我不知道您的确切用例，但从这个问题和您上一个问题中，我得到的印象是您想要回滚，或者在本例中撤消事件，如果事件处理程序之一无法处理该事件。

一般来说，您可以做一些事情。您可以查看首先应用该事件的聚合是否具有或可以具有信息来检查“从属”微服务是否应该能够在应用该事件之前处理该事件。如果这不切实际，从属微服务还可以直接在事件总线上应用“失败”事件，以通知系统的其余部分已发生需要处理的失败状态。