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

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

---

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

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

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

---

正因为如此，您需要像saga pattern这样的工具来实现补偿操作，以便在发生这种情况时恢复更改

saga或2PC解决了哪些问题，而不是提供高可用性。正如我前面所说，它们提供的数据一致性多于高可用性。他们确保所有的操作都进行了，或者没有任何操作。这与传统RDBMS中的事务相同，它们不提供高可用性，但在需要多次更改时提供数据一致性made@JAgrente我的意思是，我已经提到，我们可以有一个命名服务器，通过自动路由到可用实例来提供高可用性。因此，我们不能基于http响应回滚事务。例：如果微服务B出现故障，它将给a以500的响应状态。@JAgrenete我想根据你的建议，遵循这个传奇将使它变得更容易，而不是像我建议的那样遵循传统方法。我说的对吗？但是您不能回滚已经在服务a中提交的事务，因为服务B上有错误，要恢复服务a中的提交，唯一的方法是定义补偿操作或saga模式提供的其他机制