gRPC 双向流与背对背 HTTP 调用

Question

我最近看到一篇文章，其中我们使用双向流调用来交换业务数据，而不仅仅是上传/下载。

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

例如，如果我们检查一下：

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

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

这种模式是否比连续 HTTP 调用更快？或者这个想法完全是愚蠢的？有人已经尝试过这个了吗？

Answer 1

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

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

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

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

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

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