gRPC 双向流与背靠背 HTTP 调用

Question

我最近看到an article，我们使用双向流调用来交换业务数据，而不仅仅是上传/下载。

然后我想到了一个问题：这种模型是否可以替代 API 后端到后端 HTTP 调用？

例如，如果我们检查这个：

服务启动时，后端客户端可以与其他后端服务器打开 gRPC 流。然后当前台客户端调用此服务时：

1. 后端客户端向其他后端服务（带有ID）发送请求并等待
2. 另一个后端服务用响应（和相同的 ID）回调后端客户端
3. 一旦从后端客户端收到响应，它就会响应前端

   这种模式会比背靠背 HTTP 调用更快吗？还是这个想法完全愚蠢？ 有人已经试过了吗？

Answer 1

这种方法有其优点和缺点。

与一元调用相比，如果后端客户端遵循最佳实践并在调用之间重用 gRPC 通道，那么这应该不会更快。

不同之处在于，在一元调用中，header+data 帧将在请求时发送，headers+data+headers 帧在响应时发送，而在双向流中，请求-响应消息将只是数据帧。但是无论如何，标头帧通常与数据帧在同一个数据包中发送，并且标头解析不应该太消耗，所以我不希望我们可以在这里节省任何大量时间。

将所有一元调用转换为单个双向流的缺点是：

• 响应消息中没有错误代码，因此您必须在响应消息中设计错误模型并在服务器端和客户端进行处理。
• 将所有请求放在单个流上将不允许客户端对请求进行负载平衡。
• 在 http/2 流级别上有一个流控制机制。将所有请求放在单个流上会禁用它 - 一个大请求将阻止所有其他请求。

流式调用有许多有效的用例，例如，当我们需要订阅更新或在客户端和服务器之间流式传输数据时。对于这些用例，流式调用很棒，但如果一元调用适用于您的用例，将它们转换为流式调用不会带来显着的好处。