api - 类似于 ACID 的微服务模式之间的通信

Question

过去几个月我一直在研究微服务架构应用程序，我仍在努力适应分布式特性。我多次注意到一种模式，但我不确定处理它的首选方式是什么。

假设我们有服务 A、服务 B 和服务 C。服务 A 公开了一个 API，其中一种方法依赖于调用 B 公开的 API 来创建资源 RB，还依赖于 C 公开的 API 来创建资源 RC。因此，在一个完美的世界中，A、B 和 C 都可以正常工作，但我多次注意到的用例是，在执行由 A 公开的 API 逻辑期间，B 或 C 可能会关闭。更重要的是它如何应该在创建 RB 时解决，C 已关闭，因此无法创建 RC，我们尝试通过在服务 B 上调用/delete/来回滚 RB 的创建，但在此期间 B 也已关闭。现在创建了 RB，但最终不应该创建，因为 RC 失败并且应该执行 A 的 API 逻辑。

相同的 A、B 和 C 可能是集群环境中的 3 个节点，当数据发布到其中一个节点时，试图在集群中传播数据。

抱歉，文字太长了，谢谢。

Answer 1

这个问题已有数十年历史，并且有许多不同的方法可以解决它。问题是实际实现您所描述的内容所需的分布式事务管理类型很难正确处理，并且往往会导致过于复杂的解决方案。这种复杂性确实是像 EJB 这样的东西已经过时的原因。

随着时间的推移，事情已经发展到在大多数情况下更容易让事情最终一致并将重试卸载到不同类型的消息队列等(如之前的海报所述)。当然，有些情况下你根本无法做到最终一致，但这种情况并不难识别，而且是少数。