我对轴突佐贺有疑问。我有一个项目，其中有三个微服务，每个微服务都有自己的数据库，但是两个“从”微服务必须将其数据共享给“主”微服务，因此我想使用Axon Saga。我已经问过有关赔偿的问题，如果出现问题，我必须自己处理赔偿，这是可以的，但并不理想。目前，我正在使用DistributedCommandBus在微服务之间进行通信，这是否有益？我正在使用Choreography Saga模型，所以现在是这样：
主站->发送命令->从站1->处理事件
从站1->发送回命令->主站->处理事件
主站->发送命令->从站2->处理事件
从站2->发送命令->主站->处理事件
如果出现问题，则补偿命令/事件会向后退。
我的问题是，有人在薪酬方面对Axon做过这样的事情吗，最佳做法是什么？如何重试Saga流程？使用RetryScheduler？如果可以的话，添加一个github仓库。
谢了哥们
最佳答案
首先，让我回答您的主要问题：
我的问题是有人用Axon做过类似的事情吗？
很快，是的，因为这是Sagas的主要用例之一。
根据经验，我想说明Saga可用于协调以下之间的复杂业务交易：
几个不同的聚合实例
几个有限的上下文
从表面上看，您似乎已经进入了委派复杂业务交易的第二种选择。
重要的是要注意，在使用Sagas时，您应该非常有意识地处理任何异常和/或命令调度结果。
因此，如果您从“主站”向“从站1”发送命令，而后者却使操作失败，则该结果将返回到Saga。
因此，这为您提供了重试操作的第一种选择，我建议您执行补偿操作。
最后，通过补偿动作，我正在谈论调度命令来触发它。
如果您不能依靠调度命令的直接响应，那么在Saga中重试/重新调度消息将是第二种合理的选择。
为此，Axon具有EventScheduler和DeadlineManager。
请注意，两者中的前者会发布一个事件，以供所有人查看。
后者在单个Saga实例的上下文中调度DeadlineMessage，从而限制了可以看到重试的范围。
通常，DeadlineManager是我的首选操作方式，除非您要求每个人都可以看到此“重新安排动作”。
仅供参考，请在this页上查看EventScheduler信息，在this页上查看DeadlineManager信息。