微服务之间的异步请求完成后如何通知客户端？答案

【问题标题】：How can I notify the client when async requests between microservices are done?微服务之间的异步请求完成后如何通知客户端？
【发布时间】：2021-10-13 14:53:45
【问题描述】：

我们有一个微服务后端，根据客户端的请求，我们还需要调用另外两个微服务，就像附图中一样。现在我知道同步通信是一种反模式，但我不知道以下情况的最佳解决方案是什么：

客户端调用服务 A，在数据库中创建资产。
服务 A 必须调用服务 B，然后调用服务 C，这些服务将各自创建一个子元素，附加到服务 A 创建的资产。
问题是：服务B和服务C都创建了子元素需要通知客户端，还需要创建元素的详细信息

我的想法是使用事件在服务之间使用异步通信，如果子元素已创建，客户端将轮询 Servive B 和 Service C，但这提出了应该轮询多长时间的问题客户端如何知道创建是否失败并出现错误？

有没有更好的解决方案？

【问题讨论】：

标签： microservices

【解决方案1】：

我不会采用您建议的解决方案，因为客户端不应该真正了解下游组件中发生的事情/服务器生态系统中的内部实现细节。

你可以做一些事情，比如从服务 B 和 C 中触发一个事件，然后在 A 中监听这些事件。

从这一点开始，您可以使用轮询，但是您必须在 A 中保留（或缓存 - 分发）完整响应状态（您可能会拥有多个客户端轮询的 A 的单个实例），这可能如果它是 API 网关就可以，但您可能希望坚持使用 HTTP API 而不是轮询。

因此，如果 A 是面向客户端的服务，并且您想为下游后端使用基于消息的异步解决方案，则可以使用 RabbitMQ sendAndRecive (RPC) 之类的东西。您可以做的另一种选择是使用 Atmosphere 框架之类的东西来保存 HTTP 请求上下文，同时您转到远程 (B & C) 服务并返回到服务 A 的同一实例。

底线我会保留从您的客户端到服务 A 的请求和响应的 API 通信 - 将范围保持在一个地方，并且不会通过从客户端到 B 和 C 的通信来公开您的微服务实施细节。想一想将来您想要更新服务 D 时会发生什么 - 您不想更改可能不需要注意的客户端的行为。

【讨论】：