池 GRPC ManagedChannels 和 BlockingStubs 还是共享的？答案

【问题标题】：Pool GRPC ManagedChannels and BlockingStubs or one shared?池 GRPC ManagedChannels 和 BlockingStubs 还是共享的？
【发布时间】：2019-01-18 07:18:37
【问题描述】：

这是我的场景：我维护一个主要充当 API 网关的服务。它接收 HTTP REST 请求，进行多次 GRPC 服务调用，然后将响应组合成上下文响应。

此服务正在运行 Jetty，当前配置有 250 个线程。

我调用了几个不同的后端 GRPC 服务，我目前正在为每个服务创建一个 ManagedChannel 和一个 BlockingStub，我将在所有工作线程之间共享它们。

我知道这很好，因为 Channel 和 Stub 都是线程安全的，并且我的线程之间没有共享状态（我的所有请求都是幂等的）。

但是，我很好奇这是否是“正确”的做事方式。我已经阅读了一些关于池化通道或拥有一个通道和多个存根的其他项目，但是如果我没有达到通道的 I/O 限制，我看不到好处（因为在幕后，每个 ClientCall在调用线程中执行）。

是否有指向 Java GRPC“最佳实践”文档的特定指针可以帮助我解决这个问题？

【问题讨论】：

标签： java multithreading grpc

【解决方案1】：

听起来你正在做的事情很好。尽可能合理/可能地分享ManagedChannel 是最重要的部分。是否共享存根或是否共享拦截器并不重要。是否可以跨服务共享ManagedChannels 有点不清楚（如果任何渠道都指向同一个目标）。

您说得对，某些用例可能需要一个“通道池”来获得更高的字节吞吐量，但这是少数情况。此外，即使在这种情况下，您也可以通过创建一个Channel（甚至实现ManagedChannel）来“隐藏”该逻辑，该逻辑在多个ManagedChannels 之间进行循环，并尽可能多地共享该“一个”频道.

【讨论】：