来自微服务中API网关的异步响应

Question

在微服务架构中，建议：

1. 客户端应用程序到API网关的通信应同步（例如 通过http REST。）

2. 微服务通信的API网关也应该是 同步

3. 但是服务之间的通信应该是异步的。

  

您应尽量遵循的另一条规则是使用   内部服务之间只有异步消息传递，并使用   同步通信（例如HTTP）仅从客户端应用   前端服务（API网关加上第一级   微服务）。

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication

现在，如果我理解正确，当用户请求API网关并依次调用第一项服务时，它将返回一个确认（带有一些GUID），该确认将传递给客户端应用程序。但是服务将继续执行请求。 现在弹出问题，当请求完全处理后，它们将如何通知客户端应用程序。一种方法是客户端可以使用传递给它的GUID检查状态。

但是可以通过一些推送通知来完成吗？我们如何集成服务器到服务器的推送通知？

Answer 1

  

现在，如果我理解正确，当用户请求API网关并依次调用第一项服务时，它将返回一个确认（带有一些GUID），该确认将传递给客户端应用程序。但是服务将继续执行请求。

否，微服务不应继续执行该请求，因为该请求已经完成。当需要时，它们将在所需的远程数据（执行请求的微服务中的数据）发生更改时，更新其内部缓存（更精确的本地表示）。进行更新的最佳方法是使用集成事件（即，当微服务执行使数据发生突变的请求时，它将向订阅的微服务发布事件）。

为了满足网关或客户端的请求，微服务甚至不应异步通信。他们应该使用后台任务在请求到来之前提前准备数据。

Answer 2

对此我有一点不同的理解，因为它说服务之间的通信应该是异步的，而到API网关的通信和到服务的API网关的通信应该是其余的API。 因此我们无需执行任何操作，因为这些都是简单的API调用，并且管道将处理请求-响应跟踪，而服务之间的异步调用将提高服务的吞吐量。

Answer 3

您正在描述一个场景，其中系统与外部参与者（对用户而言很粗鲁）之间的整个交互遵循异步模型。这是完全合理的，但是就在您真的需要时也是如此。实际上，如果您选择让“外部”通过REST API与系统交互，那么也许根本就不需要它。

如果系统通过同步应用程序端点（例如REST端点）接收到请求，则它必须在发送响应之前完成请求，否则将毫无意义。考虑像这样的API

POST用户/：用户名/通知

通知本质上是同步的，但是请求仅声明“应将新通知附加到用户的通知集合中”。 API响应201，这意味着“确定，该通知已经与用户相关联，最终它将被推送到某个频道上”。这是描述异步交互的“事务”方式

当用户想要订阅通知频道时，出现另一种情况。我希望可以使用双向异步pubsub通信协议（例如websockets）来实现。

但是，在两种情况下，微服务之间如何通信都无关紧要，如果请求是同步的，则“链”的第一个服务应等待，直到准备好响应为止。这是因为API网关在http中转发请求的原因。

另一方面，异步通信可用于强制服务之间的一致性，而不是进行实际的通信。假设订单服务将数据发送到经纪人。每次对orders [orderId]的某些属性进行更改时，它都会在/ orders /：orderId主题中发布更改。同时，公开一个内部http点。每个服务都会从依赖的服务中缓存数据。用户服务执行GET / orders /：orderId，同时向请求者发送响应，将数据放入本地缓存中，并订阅orders /：orderId主题。每次在此主题上发送“变异”时，用户服务都会捕获到该变异并将变异应用于相应的缓存对象。通信是同步的，保持同步，并且管理相对简单；同时您的系统可以保存复制的数据，并且仍然（最终）保持一致