首页 > 解决方案 > 池 GRPC ManagedChannels 和 BlockingStubs 还是共享的?

问题描述

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

该服务正在运行 Jetty,目前配置了 250 个线程。

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

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

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

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

标签: javamultithreadinggrpc

解决方案


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

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


推荐阅读