分布式系统中的消息传递与RPC(Openstack vs K8s / Swarm)

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (1)
  • 关注 (0)
  • 查看 (136)

OpenStack使用消息传递(默认情况下我认为是RabbitMQ?)用于节点之间的通信。除了Kubernetes(谷歌内部Borg的血统)使用RPC。Docker的swarm也使用RPC。两者都是基于gRPC / protofbuf的,似乎也在谷歌内部大量使用。

我知道像Kafka这样的消息传递平台被广泛用于流数据和日志聚合。但是像OpenStack,Kubernetes,Docker Swarm等系统需要节点之间的特定交互,RPC似乎是一个自然的选择,因为它允许为特定的操作定义API。

OpenStack在评估了消息与RPC之间的利弊之后是否选择了消息传递?是否有任何良好的文化比较使用消息传递与RPC的大规模系统的成功?在扩展的分布式系统中,消息传递是否比RPC具有任何优势?

提问于
用户回答回答于

在扩展的分布式系统中,消息传递是否比RPC具有任何优势?

持久性主要是消息系统的一大优势。另一点是广播。您需要自己将其实现到gRPC中。服务发现和安全可能是另一个原因。在Messaging System中,您只需要保持一个系统的高度安全性,而在gRPC中有许多点可以进入系统。与消息传递系统相比,找到闯入服务的方法可能更简单。Kafka等提供服务发现的解决方案,而你必须自己弄清楚如何解决这个问题。

是否有任何良好的文化比较使用消息传递与RPC的大规模系统的成功?

这不是一个对比有不同的用例。消息传递系统通常比RPC协议慢。不仅比gRPC慢。原因很简单。您只需在两个或更多节点之间引入中间件。但它们提供持久性,广播,发布/订阅等。

Openstack在评估了消息与RPC的优缺点后是否选择了消息?我认同。 在扩展的分布式系统中,消息传递是否比RPC具有任何优势?1.准备使用解决方案,只需实现客户端2.持久性3.准备使用服务发现4.发布/子模式5.容错

大多数要点都需要自己用gRPC来实现。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励