分布式系统中的消息传递与RPC（Openstack与K8S/Swarm）
OpenStack使用消息传递（我想默认情况下是RabbitMQ？）用于节点之间的通信。另一方面，Kubernetes（谷歌内部博格的血统）使用RPC。Docker的swarm也使用了RPC。两者都是基于grpc/protofbuf的，在Google内部似乎也大量使用。
共有1个答案
在可缩放的分布式系统中，消息传递比RPC有什么优势吗？
对于消息传递系统来说，持久化是一个很大的优势。另一点是广播。您需要自己将此实现到gRPC中。服务发现和安全性可能是另一个原因。在消息传递系统中，您只需要保持一个系统的高度安全，而在gRPC中，您可能会有很多地方有人可以侵入系统。消息队列系统通常已经实现了某种服务发现。对于gRPC，您必须至少使用另一个库进行此操作。
有没有比较大型系统使用消息传递和RPC的成功的好知识？
- 准备使用解决方案，只需使用客户端
- 持久性
- 已准备好使用服务发现
- 发布/子模式
- 故障容限
大部分的点需要自己用gRPC来实现。
-
问题内容： 对于这两个消息传递系统中的哪个是我，我将不胜感激。 更容易管理 需要了解和避免的陷阱或魔术少 具有较少的总体依赖 很简单。 问题答案： 更容易管理 hornetQ具有清晰的管理API，并且非常易于使用。 需要了解和避免的陷阱或魔术少 hornetQ专为嵌入式案例设计。将其集成到代码中非常非常容易。实际上，您可以用少于10行的代码来完成此操作。 具有较少的整体依赖性 HornetQ上的所
-
我正试图将FCM与SNS整合。我在这个答案中读到设置应该与GCM相同。我设法创建了一个FCM应用程序，可以向android设备发送消息。当应用程序在后台时，设备在托盘中接收通知，或当应用程序在前台时打印接收的消息。我正试图整合它现在到SNS，但我似乎不能使它工作，没有任何错误信息。
-
distributed RPC（分布式RPC） (DRPC) 的设计目的是充分利用Storm的计算能力实现高密度的并行实时计算。Storm topology（拓扑）接受若干个函数参数作为输入，然后输出这些函数调用的结果。 严格的来说，DRPC不能够算作Storm的一个特性，因为它是一种基于Storm 原语（Stream，Spout，Bolt，Topology）实现的设计模式。DRPC可以脱离Sto
-
本文向大家介绍Kafka 与传统消息系统之间有三个关键区别?相关面试题，主要包含被问及Kafka 与传统消息系统之间有三个关键区别?时的应答技巧和注意事项，需要的朋友参考一下 (1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留 (2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据 提升容错能力和高可用性 (3).Kafka 支持实时的流式处理
-
我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。 由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。 我们面临的最大问题是谁将负责微服务之间的事件共享。例如，
-
YodaOS 中通过 YodaOS Message 完成对系统中的某个模块的定制化，本章节即是列出 YodaOS 中标准的消息接口，方便有需要的开发者对模块进行定制。 YodaOS Message 使用 yodaos-project/flora 作为 IPC 方式，它支持的数据结构包括： int float long double string binary 本章节描述中出现的number格式为i