分布式系统中的消息传递与 RPC（Openstack 与 K8s/Swarm）

Posted 2023-02-14

【中文标题】分布式系统中的消息传递与 RPC（Openstack 与 K8s/Swarm）

【英文标题】：Messaging vs RPC in a distributed system (Openstack vs K8s/Swarm)

【发布时间】：2018-05-16 02:20:45

【问题描述】：

OpenStack 使用消息传递（我认为默认情况下是 RabbitMQ？）在节点之间进行通信。另一方面，Kubernetes（谷歌内部 Borg 的血统）使用 RPC。 Docker 的 swarm 也使用 RPC。两者都是基于 gRPC/protofbuf 的，这似乎在 Google 内部也被大量使用。

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

OpenStack 在评估了消息传递与 RPC 的优缺点后是否选择了消息传递？有没有比较好的博客/系统评论比较使用消息传递与 RPC 的大型系统的成功？在可扩展的分布式系统中，消息传递是否比 RPC 更具优势？

【问题讨论】：

我会注意到有一点点错误的二分法。在 RPC 世界中，消息队列仍然有用，例如 gRPC 的 pubsub。但它们不是唯一的选择。

【参考方案1】：

在可扩展的分布式系统中，消息传递是否比 RPC 更具优势？

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

有没有优秀的人比较使用消息传递与 RPC 的大型系统的成功？

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

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

在可扩展的分布式系统中，消息传递是否比 RPC 更具优势？

即用型解决方案，只需使用客户端 坚持 准备使用服务发现 发布/订阅模式 容错

大部分点需要自己用gRPC实现。