分布式系统中的消息传递与RPC (Openstack与K8s/Swarm)
OpenStack使用消息传递(我想是默认的RabbitMQ ?)用于节点之间的通信。另一方面，Kubernetes (继承了Google内部的Borg)使用RPC。Docker的swarm也使用RPC。两者都是基于gRPC/protofbuf的，这似乎在Google内部也被大量使用。
我知道像Kafka这样的消息平台被广泛用于流数据和日志聚合。但是像OpenStack，Kubernetes，Docker Swarm等系统需要在节点之间进行特定的交互，而远程过程调用似乎是一个自然而然的选择，因为它允许为特定的操作定义API。
OpenStack是在评估消息传递与远程过程调用的优缺点后选择消息传递的吗？有没有好的博客/系统评论比较使用消息传递和RPC的大规模系统的成功？在可扩展的分布式系统中，消息传递是否提供了比RPC更好的优势？
回答 1
Stack Overflow用户
发布于 2017-12-06 20:47:11
在可伸缩的分布式系统中，消息传递是否提供了比
更好的优势？
大多数情况下，持久化是消息传递系统的一大优势。另一点是广播。您需要自己将其实现到gRPC中。服务发现和安全性可能是另一个原因。在消息传递系统中，你只需要保持一个系统的高度安全，而在gRPC中，你可能有很多人可以进入系统。消息队列系统通常已经实现了某种类型的服务发现。对于gRPC，您必须至少使用另一个库来完成此任务。
有没有比较使用消息传递和远程过程调用的大规模系统的成功的好知识？
它不是a，而是有不同的用例。消息传递系统通常比RPC协议慢。不仅比gRPC慢。原因也很简单。您只需在两个或多个节点之间引入一个中间件即可。但它们提供持久性、广播、发布/订阅等功能。
是在评估消息传递与远程过程调用的优缺点后选择消息传递的吗？很可能
在可扩展的分布式系统中，消息传递是否提供了比RPC更好的优势？
服务即用型解决方案，只需使用client
- Persistence
- Ready to use Discovery
- Pub/Sub Pattern
- Failure
即可
大多数要点都需要自己用gRPC实现。
https://stackoverflow.com/questions/47602517
复制相似问题