我们试图了解如何补偿“传奇补偿失败”。
我们有两个微服务和两个数据库，每个微服务一个。
用例：客户别名修改。
\"Customer microservice\"。
一个。 Customer 别名在客户表上被修改，但其状态为 pending。
湾。发送customer modified 事件。customer modified 事件由\"Constract microservice\" 接收。
一个。收到的Customer 会在所有合同上进行更新（我们使用的是 mongodb），因为每个合同中都嵌入了客户信息。
湾。发送contract updated 事件。contract updated 事件由 \"Customer microservice\" 接收。
一个。 Customer\ 的状态设置为 confirmed。
如果3.a 失败，则执行补偿操作，但如果失败了怎么办？
标签： microservices saga
这可以通过以下方法的组合来处理：
为补偿操作实现重试模式
异常处理 - 可以保存异常，并且可以通过以下方式解决 - 自动化过程，如通过单独的应用程序重试机制
这是方法#2 的扩展，如果自动化流程无法解决，则生成可以手动查看的异常报告，并可以根据问题采取措施。
【讨论】：
看起来您使用的是 saga 一词，但实际上您的意思是您想要一笔交易。如果您真的需要交易，请执行此操作（您可以查看 https://docs.temporal.io/ 之类的解决方案以提供该交易） [个人I think transactions between services are bad，如果我需要服务之间的交易，我会尝试重新考虑我的设计，但你的里程可能会有所不同]
您没有指定合同拒绝更改的原因 - 如果有业务规则是一回事，但如果这些是“技术原因”，如可用性等，那么要做的是确保事件是持久的并且是发送（例如发送端的发件箱模式）并让消费服务在可能的情况下处理它
如果涉及业务规则，那么这可能是一个不好的例子，但我希望一个人仍然可以更改他们的别名，而补偿将是保留一些与旧别名的合同或这些行很长的东西。
顺便说一句，您似乎有一个设计问题，导致您的服务之间不必要的时间耦合。
如果别名在合约中很重要但归客户服务所有，则存储在合约中的别名应视为已缓存。 在这种情况下，无论其他服务做什么，客户服务都可以关闭更新。它可以触发事件，并且您可以在合同服务上完成该过程。阅读合同时，您可以检查是否有更新版本的客户，如果有，请获取。您也可以（取决于业务需求。指定数据在上次更新时是正确的）
【讨论】：
隔离：由于本地事务在 Saga 运行时提交，它们的更改已经对其他并发事务可见，尽管 Saga 最终可能会失败，从而导致所有先前应用的事务得到补偿。即，从整个 Saga 的角度来看，隔离级别相当于“未提交的读取”。
最终其他服务会读取那些不一致的事件，他们也会根据这些做出错误的决定，他们会增加根本不应该发生的事件的数量。
最后会有大量的事件需要回滚（如果你的系统让用户做的事情超出了现实世界的允许范围，这怎么可能？你能从一个孩子那里拿回 5 分钟前卖掉的冰淇淋！）
【讨论】：