【发布时间】：2017-10-10 12:45:52
【问题描述】：
因此，gRPC api 在我看来，就好像在一个应用程序中拥有多个服务的预期方式是在 io.grpc.Server 实例上构建并根据需要向其中添加尽可能多的服务。
是否有任何原因（就健壮性/性能/可用性/错误恢复能力而言...）为什么要使用多个 io.grpc.Server 实例来托管不同的服务？
我对基准特别感兴趣，但也感谢提供有关该主题的文档和/或讨论的链接。
【问题讨论】：
【发布时间】：2017-10-10 12:45:52
【问题描述】：
通常，所有服务都是单个 io.grpc.Server 的一部分。
多个 io.grpc.Servers 可能对根据访问/权限分离服务最有用。例如，如果您想要一个“特殊”的额外开放端口，例如允许管理员使用额外的防火墙规则访问或仅限本地主机。或者，如果您想要多个 Unix 域套接字，每个套接字都有自己的用户/组访问权限。
但如果您想听多次，也可以简单地使用它。例如，如果您想在普通 IP 端口上同时在 Unix 域套接字上侦听也很有用。
【讨论】：
从客户端的角度来看，连接多个服务器意味着创建多个通道，通道是昂贵的资源。如果相关服务可以全部在一台服务器上，那么客户端只需创建一个通道即可调用所有服务。
【讨论】：