因此gRPC api看起来好像在一个应用程序中拥有多个服务的预期方式是在io.grpc.Server实例上构建并根据需要添加尽可能多的服务。
是否有任何理由（在健壮性/性能/可用性/错误恢复能力......方面）知道为什么人们想要使用多个io.grpc.Server实例来托管不同的服务？
我特别感兴趣的是基准测试，但是对文档和/或关于该主题的讨论的链接也很感激。
答案 0 :(得分：1)
从客户的角度来看，连接到多个服务器意味着创建多个渠道，而渠道是昂贵的资源。如果相关服务可以在一个服务器中，那么客户端只需要创建一个通道来调用所有服务。
答案 1 :(得分：1)
通常，所有服务都是单个io.grpc.Server的一部分。
多个io.grpc.Servers可能对基于访问/权限的服务分离最有用。例如，如果您想要一个“特殊”的额外开放端口，例如允许使用额外防火墙规则的管理员访问权限或仅使用localhost。或者，如果您想要多个Unix域套接字，每个套接字都有自己的用户/组访问权限。
但如果你想多次听，也可以简单地使用它。例如，如果您想要在普通IP端口上侦听，也在Unix域套接字上也是有用的。