gRPC双向流与背对背HTTP调用

Question

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

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

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

​

​

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

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

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

Answer 1

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

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

区别在于，在一元调用中，header+data帧将在请求时发送，而headers+data+headers帧将在响应时发送，而在bidi流请求响应消息中，响应消息将仅仅是数据帧。但是，报头帧通常都是在同一个数据包中发送的，而且数据帧的解析也不应该太费时，所以我不希望在这里节省任何重要的时间。

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

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

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