池 GRPC ManagedChannels 和 BlockingStubs 还是一个共享？
Pool GRPC ManagedChannels and BlockingStubs or one shared?
这是我的场景：我维护一个主要充当 API 网关的服务。它接收一个 HTTP REST 请求，进行多个 GRPC 服务调用，然后将响应组合成一个上下文响应。
此服务是 运行 Jetty，当前配置了 250 个线程。
我调用了几种不同的后端 GRPC 服务，对于每项服务，我目前正在创建一个 ManagedChannel 和一个 BlockingStub，我将在所有工作线程中共享它们。
我知道这很好，因为 Channel 和 Stub 都是线程安全的，并且我的线程之间没有共享状态（我的所有请求都是幂等的）。
不过，我很好奇这是否是 "right" 做事的方式。我已经阅读了一些关于合并通道或拥有一个通道和多个存根的其他文章，但是如果我没有达到通道的 I/O 限制，我看不到好处（因为在引擎盖下，每个 ClientCall 都在调用线程中执行）。
是否有指向 Java GRPC 'best practice' 文档的特定指针可以帮助我解决这个问题？
听起来你做的还不错。分享 ManagedChannel 和 reasonable/possible 一样多是最重要的部分。是否共享存根或是否共享拦截器并不重要。有点不清楚您是否可以跨服务共享 ManagedChannels（如果任何频道指向同一目标）。
您说得对，某些用例可能需要 "pool" 通道来提高字节吞吐量，但这是少数情况。此外，即使在那种情况下，您也可以通过创建 Channel（或什至实现 ManagedChannel）来 "hide" 该逻辑，该逻辑在多个 ManagedChannel 之间进行循环，并共享该逻辑"one"频道越多越好。
这是我的场景：我维护一个主要充当 API 网关的服务。它接收一个 HTTP REST 请求，进行多个 GRPC 服务调用，然后将响应组合成一个上下文响应。
此服务是 运行 Jetty，当前配置了 250 个线程。
我调用了几种不同的后端 GRPC 服务，对于每项服务，我目前正在创建一个 ManagedChannel 和一个 BlockingStub，我将在所有工作线程中共享它们。
我知道这很好，因为 Channel 和 Stub 都是线程安全的，并且我的线程之间没有共享状态（我的所有请求都是幂等的）。
不过，我很好奇这是否是 "right" 做事的方式。我已经阅读了一些关于合并通道或拥有一个通道和多个存根的其他文章，但是如果我没有达到通道的 I/O 限制，我看不到好处（因为在引擎盖下，每个 ClientCall 都在调用线程中执行）。
是否有指向 Java GRPC 'best practice' 文档的特定指针可以帮助我解决这个问题？
听起来你做的还不错。分享 ManagedChannel 和 reasonable/possible 一样多是最重要的部分。是否共享存根或是否共享拦截器并不重要。有点不清楚您是否可以跨服务共享 ManagedChannels（如果任何频道指向同一目标）。
您说得对，某些用例可能需要 "pool" 通道来提高字节吞吐量，但这是少数情况。此外，即使在那种情况下，您也可以通过创建 Channel（或什至实现 ManagedChannel）来 "hide" 该逻辑，该逻辑在多个 ManagedChannel 之间进行循环，并共享该逻辑"one"频道越多越好。