OpenStack使用消息传递（默认情况下我认为是RabbitMQ？）用于节点之间的通信。另一方面，Kubernetes（谷歌内部Borg的血统）使用RPC。 Docker的swarm也使用RPC。两者都是基于gRPC / protofbuf的，似乎也在Google内部大量使用。
据我所知，像Kafka这样的消息传递平台广泛用于流数据和日志聚合。但是像OpenStack，Kubernetes，Docker Swarm等系统需要节点之间的特定交互，RPC似乎是一个自然选择，因为它允许为特定操作定义API。
OpenStack在评估了消息与RPC之间的优缺点后，是否选择了消息传递？是否有任何好的博客/系统评论比较使用消息传递与RPC的大规模系统的成功？在扩展的分布式系统中，消息传递是否比RPC具有任何优势？
答案 0 :(得分：4)
在扩展的分布式系统中，消息传递是否比RPC更具优势？
大多数持久性是邮件系统的一大优势。另一点是广播。您需要自己将其实现到gRPC中。服务发现和安全可能是另一个原因。在消息系统中，您只需要保持一个系统的高度安全性，而使用gRPC，您可能会有很多点可以让某人进入系统。消息队列系统通常已经实现了某种服务发现。使用gRPC，您必须至少使用另一个库。
对于使用消息传递与RPC的大规模系统的成功比较，是否有良好的文化？
它不是一个vs.有不同的用例。消息传递系统通常比RPC协议慢。不仅比gRPC慢。原因也很简单。您只需在两个或更多节点之间引入中间件。但它们提供持久性，广播，发布/订阅等等。
Openstack在评估了消息与RPC的优缺点后是否选择了消息？ 大概
在扩展的分布式系统中，消息传递是否比RPC具有任何优势？ 1.准备使用解决方案，只需使用客户端 2.坚持 3.准备使用服务发现 4.发布/子模式 5.容忍度
大多数要点都需要由gRPC自行实施。