何时需要在微服务架构中使用回滚逻辑？答案

【问题标题】：When to need a roll-back logic in microservices architecture?何时需要在微服务架构中使用回滚逻辑？
【发布时间】：2023-09-02 18:30:01
【问题描述】：

根据chrisrichardson 所写的关于微服务中 sagas 中补偿事务的内容：

什么是补偿交易？

rejectOrder() 命令是补偿事务的一个示例。与 ACID 事务不同，sagas 不能自动撤消先前步骤所做的更改，因为这些更改已经提交。相反，您必须编写显式撤消这些更改的补偿事务。 saga 的每个步骤后面都有可能失败的步骤（出于业务原因）必须有相应的补偿事务。

在 Create Order Saga 中，createOrder() 具有 rejectOrder() 补偿事务，因为 reserveCredit() 步骤可能会失败。 reserveCredit() 步骤不需要补偿事务，因为approveOrder() 步骤不会失败。而且，approveOrder() 步骤不需要补偿事务，因为它是 saga 的最后一步。

这是否从字面上表示，只要后续步骤没有出于业务原因失败，该步骤就不需要补偿事务？如果以下步骤由于某些技术原因（例如一些错误或一些微服务间通信问题）而失败怎么办？

【问题讨论】：

如果您预计任何步骤会失败，您应该将其包装到事务中，这将在未来节省您的时间。不要看是因为业务逻辑还是技术问题
当有网络通信时，这不是一个选项，因为在失败的情况下服务不能回滚，因为它不会发生在数据库事务中，如果网络通信改变了状态其他微服务，然后，其他调用失败第一个无法回滚

标签： microservices distributed-transactions saga

【解决方案1】：

这是因为，如果不能出现业务错误，您可以重试通信或安排在技术问题解决时进行通信，当它发生时，状态将是正确的。

请记住，技术问题是暂时的，在微服务架构中，您必须处理最终的一致性

【讨论】：