一元与流基准

Question

我开始在Golang微服务应用程序中使用一些GRPC。

阅读GRPC文档后，我不清楚：

  

何时使用一元和何时使用流媒体？

我的意思是，作为示例，我正在构建一个微服务，它将解析XLS并将JSON返回到存根。我将使用thrid-party lib为我解析它。所以，我的工作是接收xls，调用lib并将其发送出去。很简单。

我能达到的最佳实践/表现是什么？使用流逐行发送（）或发送整个解析过的json一次？

Answer 1

发送一元几乎总是更快。 使用流媒体发送大文件。

Answer 2

这里的一些基准：https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a

除非您希望以异步方式（逐行）处理非常大的文件，否则一元必须是正确的选择。

有一些论点认为，流理论上应该具有更低的开销。但事实并非如此。 Streams 确保消息按照发送的顺序进行传递，这意味着如果存在并发消息，就会出现某种瓶颈。

使用流

• 否则您将需要投票通知，监听事件，发送数据，然后是增量

• 事务，即必须由单个服务器处理的大量串行调用

• 可以分解为多个较小请求的大型调用文件上传，文本到语音翻译

使用流的一些缺点：

• 难以负载平衡即。不会在新服务器上自动分配负载

• 更高的应用程序级别复杂性。将客户端消息与服务器响应映射必须由应用程序完成

• 间歇性网络故障。即使 TCP 连接中的小中断也会使连接失败。从间歇性网络故障中恢复的应用级复杂性。

• 维护消息顺序您不能写入多条消息，因此如果您在管道中有很多请求，则必须按顺序进行。

Answer 3

一元是请求/响应。客户端需要一个服务，它发送一个请求并接收一个响应。如果连接失败，客户端必须再次发送相同的请求。在客户端，Unary 快速且易于实施。

在流式传输中，一开始，客户端创建一个 RPC，发送多个请求，然后结束连接。典型的例子是，客户端向服务器发送一些通知（如周期性 gps 坐标或设备状态）。如果出现网络故障，重新连接后，可以从那个点开始，而不考虑之前的状态。你可以用多个 RPC 代替流（你基本上是定期轮询），它比一元慢，但多个一元 RPC 的应用复杂性和成本高于一个长时间运行的流。

如果文件比较大，放不下内存，可以使用流式传输。在 Unary 的情况下，断开连接将强制重新发送完整文件。但是由于应用程序开发人员确实可以检测到断开连接，因此您要么重新发送文件，要么确保每个流消息都包含足够的信息，以便可以将每个部分组合起来创建整体。

在您的情况下，json 的大 xls 文件适合客户端流式传输。