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

Question

OpenStack使用消息传递(默认情况下我认为是RabbitMQ？)来进行节点之间的通信.另一方面,Kubernetes(谷歌内部Borg的血统)使用RPC.Docker的swarm也使用RPC.两者都是gRPC/protofbuf,似乎也在谷歌内部大量使用.

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

OpenStack在评估了消息与RPC之间的优缺点后是否选择了消息？是否有任何好的博客/系统评论比较使用消息传递与RPC的大规模系统的成功？在扩展的分布式系统中,消息传递是否比RPC具有任何优势？

Answer 1

在可扩展的分布式系统中，消息传递相对于RPC是否具有任何优势？

持久性通常是消息传递系统的一大优势。另一点是广播。您需要自己将其实现到gRPC中。服务发现和安全性可能是另一个原因。在Messaging System中，您只需要保持一个系统的高度安全，而使用gRPC时，您可能会有很多地方可能有人闯入系统。消息队列系统通常已经实现了某种服务发现。使用gRPC，您必须为此至少使用另一个库。

比较使用消息传递和RPC的大规模系统的成功率，是否有很好的素养？

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

Openstack在评估了消息传递与RPC的优缺点之后是否选择了消息传递？大概

在可扩展的分布式系统中，消息传递相对于RPC是否具有任何优势？1.准备使用解决方案，只使用客户端2.持久性3.准备使用服务发现4.发布/订阅模式5.容错

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