如何回滚微服务

Question

我对微服务有疑问。假设有5个微服务，例如M1，M2，M3，M3，M4和M5。有4个数据库，由4个微服务连接/访问。例如，M2连接到MySql，M3连接到Cassandra，M4连接到MangoDb，M5连接到Oracle。

现在

步骤1：M1调用M2以更新mySql中的某些用户数据，并成功更新，最后得到M2的成功响应

步骤2：M1呼叫M3以更新Cassandra中的某些数据，并成功更新，最后得到M3的成功响应

步骤3：M1调用M4以更新MangoDb中的某些数据，但由于某些数据库服务器问题或任何其他问题而失败。

在这里，我的要求是，我想回滚以前的微服务（M2和M3）所发生的数据库更改

为了实现这种回滚方案，我们需要做什么？

Answer 1

这是分布式事务的典型案例。无论您对数据库使用单独的技术还是在不同的服务器上使用相同的技术，您都执行事务性操作。为了处理这种类型的事务的回滚，您不能依靠用于事务和回滚的数据库技术机制。你必须自己做。

传奇模式

微服务架构中分布式事务场景的常见解决方案是Saga 模式。分布式传奇是一种管理场景中的故障的模式，正如您所描述的那样。

Saga 是基于业务流程创建的，例如“在网上商店购买产品”。此过程可能涉及对多个微服务的多个操作。Saga 将控制和管理此流程执行，如果其中一个步骤失败，它将触发操作以恢复在失败操作之前完成的操作。

有多种方法可以实现传奇。这取决于您的架构以及您的微服务相互通信的方式。你使用命令和/或事件吗？

例子

“在网上商店购买产品”业务流程。假设这个业务流程有 3 个简单的步骤，由 3 个不同的微服务完成：

• 行动 1 - 在产品-库存-微服务中储备产品
• 操作 2 - 在支付微服务中验证支付
• 行动 3 - 在订单微服务中订购产品

使用事件：

您可以发布事件以执行某些操作（或多个操作），如果其中一个操作失败，您可以发布该事件的还原（或删除）事件。对于上述业务流程，可以说 1. 操作成功和 2. 操作失败。在这种情况下，为了回滚 1. 操作，您将发布一个类似“RemoveReservationFromProduct”的事件，以便删除保留并将状态恢复到该业务流程的事务开始之前的状态。此事件将由事件处理程序拾取，该事件处理程序将在您的数据库中恢复该状态。由于它是一个事件，您可以为失败实现重试机制，或者如果代码中存在一些错误，则稍后重新应用它。

使用命令：

如果您使用某种 rest api 作为命令直接调用微服务，您可以运行一些删除或更新端点来恢复您所做的更改。对于上述业务流程，可以说 1. 操作成功和 2. 操作失败。在这种情况下，为了回滚 1. 操作，您将调用 delete api 删除特定产品的预订，以便删除预订并将状态恢复到该业务流程的事务开始之前的状态.

你可以看看这个例子如何实现 Saga 模式。

Answer 2

据我了解，Saga就是您正在寻找的。这个想法是为每个状态改变操作提供一个撤消操作，如果下游出现问题则必须调用该操作。