为什么我们需要像 2PC 或 SAGA 这样的模式来执行微服务之间的顺序事务？

Question

我遇到的问题是为什么我们甚至需要像 SAGA（异步）或 2PC（同步）这样的模式来执行微服务之间的事务性服务间通信？ .因为我们可以通过命名服务器来实现。我的意思是让我们考虑一下，如果一个微服务在事务调用过程中出现故障，那么命名服务器不能将该请求路由到所需的不同微服务实例吗？那么微服务之间就不会有任何不可用的情况了。

例如：A 和 B 是微服务，所有这些微服务都注册在像 Eureka 这样的命名服务器中，A 需要 B 通过执行服务间通信来完成事务。但出乎意料的是，B 宕机了。因此，命名服务器可以将 A 的请求路由到 B 的另一个实例 no 。那么，不可用在哪里。那么现在为什么我们需要这些模式呢？

Answer 1

这不是高可用性的问题，而是数据一致性的问题，这与我们在关系数据库中需要事务的原因相同。之所以需要它们，不仅是因为在事务期间数据库连接可能会失败，还因为我们希望整个操作要么成功要么失败。 这可能包括插入或更新期间未满足的约束等问题。

这个问题也可以应用于分布式事务。您可能希望不同微服务中的两个操作成功或失败。如果其中一个操作失败，因为该微服务的实例已关闭，还因为数据库中的插入/更新由于任何其他原因而失败，您希望恢复整个操作，即使另一个调用已成功并且更改已提交。

因此，您需要像 saga 模式这样的工具来实现补偿操作，以便在发生此类事情时恢复更改