问异步地服务基于REST的请求的常见实践是什么？

EN

将gRPC通信称为“反模式”是一件很难的事情。同步通信具有简单性的巨大优点，而异步通信则更灵活。你真的需要那种灵活性吗？

基于

事件的异步操作模型

异步通信意味着根据事件进行思考，而不是根据请求或通道进行思考。将请求响应通信模型转换为基于事件的模型如下所示：

• 进程A发布请求事件
• 进程B侦听请求事件，并最终发布响应事件。
• 进程A侦听响应事件。如果创建了匹配的响应事件，它最终将被创建原始请求事件的进程A接收。

不同的事件可以共享一个相关ID来表示它们之间的关联。

我是泛指请求和响应事件。在实践中，事件在软件域中应该有意义，例如ChatMessageSent、ChatMessageDelivered和ChatMessageRead事件。

用于异步操作的

如果您有一个HTTP/REST，它是异步微服务的网关，那么处理底层异步操作的方法是不同的。

• 服务器可以等待，希望在某个超时时间内收到响应事件。这可能是一个好主意，如果你非常肯定，最后期限将几乎总是满足。但是通常情况下，等待是有问题的:客户机只是看到延迟，并且不知道他们的HTTP请求是否被正确地接收了。
• 服务器可以立即响应指示收到了请求，但没有直接传递结果。结果可以稍后检索。具体来说，下面的HTTP状态代码可能是有用的：
  • 202接受专门用于异步操作。这意味着请求已经收到，但并不表示请求会成功。响应的主体可以通知客户如何监视状态。
  • 或者，响应可以使用303状态并重定向到表示操作的新创建的资源。如果可以直接创建这样的资源，这将是我首选的方法。

HTTP响应可以提供一种监视结果的方法。例如，它可以链接到表示操作状态的URL。HTTP服务器可以维护所有请求及其状态的数据库。当HTTP服务器在消息总线上观察到响应事件时，可以在数据库中更新状态。

在聊天应用程序中，HTTP通信可以如下所示：

1. 客户端发送一个新的聊天消息。服务器对表示消息> POST /messages >> {"body"："Lorem“的URL进行重定向响应。}}<303个参见其他< Location: /messages/ff591577-668c-4ffc-88d6-fe160068f93f。
2. 客户端请求消息状态。>获取/messages/ff591577-668c-4ffc-88d6-fe160068f93f < 200 OK << {"body"："Lorem“<，”发送“：1641405030 <，”接收“：空<，”读“：空}
3. 时间流逝。客户端再次请求消息状态。>获取/messages/ff591577-668c-4ffc-88d6-fe160068f93f < 200 OK << {"body"："Lorem“<，”发送“：1641405030 <，”接收“：1641405032 <，”读“：1641405079}

当然，对资源的状态进行客户端投票并不一定是一个好的设计。但是轮询是内置到HTTP的唯一方法(不，HTTP/2服务器推送不能解决这个问题)。如果想要实时更新，就必须有一些可以推送更新的通信渠道。在web上下文中，Websockets扮演此角色。服务器可以通过websockets发送通知，说明存在资源更新，以便客户端知道再次请求该资源。

同步通信可能足够好

这一切都很复杂。如果您没有处理固有的异步问题，那么坚持同步通信就会简单得多。在这种情况下，同步通信意味着每个请求都将在合理的超时内收到响应。如果您只与托管在同一个数据中心的内部服务交互，这可能是非常实用的。