一元与流基准

时间:2017-12-25 18:15:23

标签: go microservices grpc

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

阅读GRPC文档后,我不清楚:

  

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

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

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

3 个答案:

答案 0 :(得分:0)

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

答案 1 :(得分:0)

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

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

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

使用流

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

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

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

使用流的一些缺点:

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

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

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

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

答案 2 :(得分:0)

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

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

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

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