microservices - 使客户端处理微服务最终一致性的最佳实践

Question

我一直在阅读一些关于最终一致性和编排微服务的文章和问题，但我还没有看到这个问题的明确答案。我会笼统地说。
简而言之 :如果客户端历史上对您的系统进行了后续同步 REST 调用，那么一旦对不同的微服务进行调用(由于最终一致性)，后续调用可能会返回意外结果，您会怎么做？
问题
假设您有一个提供 REST API 的单体应用程序。假设有两个模块 A 和 B 要转换为微服务。 B 维护的实体可以引用 A 维护的实体(例如 A 维护学生，B 维护类(class))。在单体的情况下，模块只是引用同一个数据库，但在微服务的情况下，它们每个都有自己的数据库并通过异步消息进行通信。所以他们的数据库最终是相互一致的。
我们 API 的一些现有第三方客户端应用程序习惯于首先(同步)调用属于模块 A 的端点，并且在第一次调用返回后，立即(即几毫秒后)调用模块 B 中的端点作为其一部分工作流程(例如，创建一个学生并将其放入类)。在新的情况下，这会导致一个问题:当第二次调用发生时，模块 B 可能还没有意识到模块 A 的变化。因此，客户端应用程序的现有工作流程可能会中断。 (例如，模块 B 可能会做出回应:您要安排的学生不存在，或者是在错误的年份。)
当调用由人类用户通过某个前端应用程序单独完成时，这不是一个大问题，因为模块通常在一秒钟后是一致的。当客户端应用程序(不受我们控制)只是调用 A 然后立即调用 B 作为自动化工作流程的一部分时，就会出现问题。在这种情况下，最终的一致性根本不够快。
A simple diagram that describes the situation
问题
是否有最佳实践或普遍同意的一组选项来缓解这个问题？ (我编造了学生/类(class)的例子，不要纠结于具体细节。:))
我们能想到的

简单地告诉这些客户端的开发者:从现在开始，你必须为你调用的每个端点实现一个重试机制。缺点似乎很明显。

实现 API gateway等到 B 准备好。缺点:有许多可以想象的工作流程(涉及更多的模块 A-Z)需要这个，所以网关可能会变得相当复杂。

以某种方式为客户端创建一个“ session ”，以跟踪它连续发出的请求。然后 B 可以判断它是否应该等待来自 A 的消息，或者它甚至可以通过查看客户端对 A 的精确请求来更新其状态。

有没有更好的方法？哪个最合适？
编辑:澄清问题主要涉及以自动化方式调用端点的第三方客户端的行为，这意味着即使是最终一致性的几毫秒“滞后”也可能是致命的。

Answer 1

Is there a best practice, or a generally agreed upon set of options, to mitigate this problem?

是的。您不能将每个方法分解为具有自己存储库的自己的微服务。
您可以确定微服务和存储库的范围，以适应强一致性的真正需求。如果您有一个用例，在调用服务端点 A 之后立即调用服务端点 B 需要查看第一次调用的结果，那么 A 和 B 应该是同一个微服务的一部分或共享同一个存储库。