我有一个用例，其中许多客户端需要不断向服务器发送大量指标（几乎是永久的）。服务器需要存储这些事件，并在以后处理它们。我不希望服务器对这些事件做出任何响应。
我正在考虑为此使用grpc。最初，我认为客户端流式传输可以做到（like how envoy does），但问题是客户端流式传输无法确保应用程序级别的可靠传递（即，如果流在两者之间关闭，则发送的消息数量实际上是由服务器），我买不起。
我的想法是，我应该使用双向流，在服务器流中使用 acks，或者使用多个一元 rpc 调用（可能在重复字段中对事件进行一些批处理以提高性能）。
哪个会更好？
【问题讨论】：
流确保消息按照发送的顺序传递，这意味着如果有并发消息，就会出现某种瓶颈。
Google 的 gRPC 团队建议不要使用流而不是一元来提高性能，但是，有人认为理论上流应该具有更低的开销。但这似乎不是真的。
对于较少数量的并发请求，两者似乎具有相当的延迟。 但是，对于更高的负载，一元调用的性能要好得多。
没有明显的理由我们应该更喜欢流而不是一元，因为使用流会带来额外的问题，例如
这里有一些基准测试：https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a
【讨论】：
问题是客户端流无法确保应用程序级别的可靠传输（即，如果流在两者之间关闭，发送的消息有多少是由服务器实际处理的），我负担不起
这意味着您需要回应。即使响应只是一个确认，从 gRPC 的角度来看，它仍然是一个响应。
一般方法应该是“使用一元”，除非可以通过流解决足够大的问题以克服其复杂性成本。我讨论了这个at 2018 CloudNativeCon NA（视频有幻灯片和 YouTube 的链接）。
例如，如果您有多个后端，那么每个一元 RPC 可能会被发送到不同的后端。这可能会导致各种后端同步自身的高开销。流式 RPC 在开始时选择一个后端并继续使用相同的后端。因此流式传输可能会降低后端同步的频率，并在服务实现中实现更高的性能。但是当错误发生时，流式传输会增加复杂性，在这种情况下，它会导致 RPC 变得长寿，这使得负载平衡更加复杂。因此，您需要权衡流式传输/长寿命 RPC 所增加的复杂性是否为您的应用程序提供了足够大的好处。
我们通常不建议使用流式 RPC 来获得更高的 gRPC 性能。确实，在流上发送消息比新的一元 RPC 更快，但改进是固定的并且具有更高的复杂性。相反，我们建议使用流式 RPC，因为它可以提供更高的应用程序（您的代码）性能或更低的应用程序复杂性。
【讨论】：