这是我的场景:我维护一个主要充当 API 网关的服务。它接收 HTTP REST 请求，进行多个 GRPC 服务调用，然后将响应组合成上下文响应。
此服务正在运行 Jetty，当前配置有 250 个线程。
我调用了几种不同的后端 GRPC 服务，对于每一种服务，我当前正在创建一个 ManagedChannel 和一个 BlockingStub，我在所有工作线程之间共享它们。
我知道这很好，因为 Channel 和 Stub 都是线程安全的，并且我的线程之间没有共享状态(我的所有请求都是幂等的)。
但是，我很好奇这是否是“正确”的做事方式。我读过一些有关池化 channel 或拥有一个 channel 和多个 stub 的其他文章，但如果我没有达到 channel 的 I/O 限制，我看不到好处(因为在幕后，每个 ClientCall在调用线程中执行)。
是否有指向 Java GRPC“最佳实践”文档的具体指针可以帮助我解决此问题？
最佳答案
听起来你正在做的事情很好。分享ManagedChannel尽可能合理/可能是最重要的部分。是否共享 stub 、是否共享拦截器并不重要。有点不清楚是否可以分享ManagedChannel跨服务(如果任何 channel 针对同一目标)。
你是对的，某些用例可能需要一个 channel “池”来获得更高的字节吞吐量，但这是少数情况。此外，即使在这种情况下，您也可以通过创建 Channel 来“隐藏”该逻辑。 (甚至实现 ManagedChannel )在多个 ManagedChannel 之间进行循环s，并尽可能多地共享该“一个” channel 。
关于java - 池 GRPC ManagedChannels 和 BlockingStubs 还是共享之一？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51790492/