如何回滚微服务

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

Now

Step-1:M1调用M2更新MySQL中的一些用户数据，并且更新成功，最后得到M2的成功响应

Step-2:M1 调用 M3 更新 Cassandra 中的一些数据，更新成功，最后收到 M3 的成功响应

Step-3:M1 调用 M4 来更新 MongoDB 中的一些数据，但由于某些数据库服务器问题或任何其他问题而失败。

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

为了实现这种回滚场景，我们需要做什么呢？

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

传奇模式

微服务架构中分布式事务场景的常用解决方案是佐贺图案 https://microservices.io/patterns/data/saga.html。 分布式传奇是一种用于管理您所描述的场景中的故障的模式。

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

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

Example

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

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

使用事件：

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

使用命令：

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

你可以看一下this https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b示例如何实现 Saga 模式。