问题描述
我遇到的问题是为什么我们甚至需要像 SAGA（异步）或 2PC（同步）这样的模式来执行微服务之间的事务性服务间通信？ .因为我们可以通过命名服务器来实现。我的意思是让我们考虑一下，如果微服务在事务调用过程中出现故障，那么命名服务器不能将该请求路由到所需的微服务的不同实例吗？这样微服务之间就不会出现不可用的情况。
Ex: A 和 B 是微服务，所有这些微服务都注册在像 Eureka 这样的命名服务器中，A 需要 B 通过执行服务间通信来完成事务。但出乎意料的是，B 宕机了。所以命名服务器可以将 A 的请求路由到 B 的另一个实例，没有。那么不可用的地方在哪里。那么现在为什么我们需要这些模式？
解决方法
这不是高可用性问题而是数据一致性问题，这与我们在关系数据库中需要事务的原因相同。之所以需要它们，不仅是因为数据库连接可能在事务期间失败，还因为我们希望整个操作要么成功要么失败。 这可能包括在插入或更新期间未满足约束等问题。
这个问题也可以应用于分布式事务。您可能希望不同微服务中的两个操作成功或失败。如果其中一个操作失败，因为该微服务的实例已关闭，而且因为数据库中的插入/更新由于任何其他原因失败，即使另一个调用成功并且更改，您也希望恢复整个操作已提交。
正因为如此，您需要像 saga 模式这样的工具来实现补偿操作，以便在发生此类事情时恢复更改