消息总线 vs. 服务总线 vs. 事件中心 vs. 事件网格

Posted 2023-03-10

【中文标题】消息总线 vs. 服务总线 vs. 事件中心 vs. 事件网格

【英文标题】：Message bus vs. Service bus vs. Event hub vs Event grid

【发布时间】：2020-01-04 12:53:16

【问题描述】：

我正在学习消息传递系统，但对这些术语感到困惑。

以下所有消息传递系统都在具有不同功能集的服务之间提供松散耦合。

queue - FIFO，拉机制，每个队列有 1 个消费者，但生产者数量不限？

message bus - 发布/订阅模型，任意数量的消费者和任意数量的生产者处理消息？ Azure Service Bus 是 message bus 的实现吗？

event bus - 发布/订阅模型，任意数量的消费者和任意数量的生产者处理事件？

就术语而言，人们是否可以互换使用message bus 和event bus？

事件和消息有什么区别？这些只是在这种情况下的同义词吗？

event hub - 发布/订阅模式、分区、重放，消费者可以将事件存储在外部存储中或接近实时的数据分析。究竟什么是事件中心？

event grid - 它可以用作事件中心的下游服务。 event hub 没有做什么？

有人可以提供一些历史背景，说明每种技术如何演变为另一种技术，每种技术都与一些实际用例相关联吗？

我发现message bus vs. message queue 很有帮助

【问题讨论】：

我建议阅读以下文档：azure.microsoft.com/en-us/blog/…docs.microsoft.com/en-us/azure/event-grid/…

不幸的是，该文档让一些人比刚开始时更加困惑 ;-) Esp。有GCP/AWS背景的，就清楚多了。不过，我确实喜欢 Ithar 下面的实用解释。

【参考方案1】：

即使您所有这些服务都处理从源到目标的数据传输，并且在它们的意图不同的伞式消息传递服务下可能看起来相似。

高层定义：

Azure 事件网格

- 事件驱动的发布-订阅模型（想想反应式编程）

Azure 事件中心

- 多源大数据流管道（想想遥测数据）

Azure 服务总线

- 传统的企业代理消息系统（取代 Azure 队列存储）

事件网格和事件中心

之间的区别

Event Grids不保证事件的顺序，但Event Hubs使用的分区是有序的，因此可以保持同一个分区中事件的顺序。 事件中心仅接受用于提取数据的端点，并且它们不提供将数据发送回发布者的机制。另一方面，事件网格发送 HTTP 请求以通知发布者中发生的事件。 事件网格 可以触发 Azure 函数。对于事件中心，Azure 函数需要拉取和处理事件。 事件网格是一种分配系统，而不是一种排队机制。如果一个事件被推入，它会立即被推出，如果它没有得到处理，它就会永远消失。除非我们将未传递的事件发送到存储帐户。此过程称为死信。 在事件中心中，数据最多可以保留 7 天，然后再进行回放。这使我们能够从某个时间点恢复或从较早的时间点重新开始，并在需要时重新处理事件。

事件中心和服务总线

之间的区别

对于外部发布者或接收者而言，Service Bus 和 Event Hubs 可能看起来非常相似，这就是难以理解两者之间的差异以及何时该理解的原因用什么。

Event Hubs 专注于事件流，其中 Service Bus 更像是一个传统的消息传递代理。 Service Bus 用作骨干，将云中运行的应用程序连接到其他应用程序或服务并在它们之间传输数据，而 Event Hubs 更关心接收海量数据具有高吞吐量和低延迟。 Event Hubs 将多个事件生产者与事件接收者分离，而 Service Bus 旨在分离应用程序。 服务总线消息支持消息属性“生存时间”，而事件中心的默认保留期为 7 天。 Service Bus 有消息会话的概念。它允许基于会话 ID 属性关联消息，而事件中心则不允许。 服务总线消息被接收者拉出并且无法再次处理，而事件中心消息可以被多个接收者摄取。 Service Bus 使用队列和主题的术语，而 Event Hubs 使用分区术语。

使用这个松散的一般经验法则。

发生了一些事情 - 偶数集线器

做点什么或给我点什么——服务总线

正如@Louie Almeda 所说，您可能会发现此link 对 Azure 官方文档很有用。

【讨论】：

您写了“事件网格可以触发 Azure 函数。在事件中心的情况下，Azure 函数需要拉和处理事件。”但我的印象是两者都使用了推送-机制（而服务总线使用轮询）。见Event Hubs Features - Read events。还是我误解了文档？

这是对 EH 和 SB 之间差异的第一个解释，它实际上使我清楚地了解了 usage 的区别，而不仅仅是列出功能差异。谢谢。

Azure Functions 现在似乎支持事件中心作为触发器：docs.microsoft.com/en-us/azure/azure-functions/…

你的一般规则评论应该在微软每一页的最顶部，它是对每个问题的快速回答:)

@OmarMuscatello 订阅主题类似于接收发送到主题的消息副本的虚拟队列。如果您希望将每条消息传递到多个目标组件，请使用主题；但是一旦从队列中拉出消息，就无法再次摄取。

【参考方案2】：

我发现this comparison from Azure docs 非常有帮助。这是事件和消息之间的主要区别。

事件与消息服务

有一个重要的区别需要注意 在传递事件的服务和传递事件的服务之间 消息。

事件

事件是条件或状态的轻量级通知 改变。该活动的发布者对如何 事件被处理。事件的消费者决定如何处理 通知。事件可以是离散单元或系列的一部分。

离散事件报告状态变化并且是可操作的。采取 下一步，消费者只需要知道发生了什么事。 事件数据包含有关发生的事情的信息，但没有 触发事件的数据。例如，一个事件通知 消费者知道文件已创建。它可能有一般信息 关于文件，但它没有文件本身。离散事件 非常适合需要扩展的无服务器解决方案。

系列活动 报告一个条件并且是可分析的。事件是按时间顺序排列的 相关。消费者需要有序的一系列事件来 分析发生了什么。

留言

消息是服务产生的原始数据，用于消费或存储 别处。消息包含触发消息的数据 管道。消息的发布者期望如何 消费者处理消息。两者之间存在合同 双方。例如，发布者发送带有原始数据的消息， 并期望消费者从该数据创建一个文件并发送一个 工作完成后的响应。

还讨论了这些不同服务的比较，因此请务必查看。

【参考方案3】：

我同意你关于超载条款的评论，尤其是云服务营销术语......

从历史上看，我的事件和消息具有更不同的含义 - event 用于指代同一进程内的通信，而 - 消息指跨不同进程的通信。

【参考方案4】：

关于“公共汽车”，我可以给你一些“历史”信息，因为我学会了成为一名音响工程师。在音乐混音器中，您还有用于混合信号的“总线”和“路由”。对于混音器，我们谈论的是电信号，无论是否在混音中！

关于消息系统，将“bus”、“hub”和“grid”视为同义词！对于同一件事，它们都是花哨的词。他们试图表达某种运输系统，包括某种路线，因为你总是有生产者和消费者——这可能是 N:M 关系。取决于用例。

队列通常有点不同，但其效果可能相同。队列意味着东西在排队的地方，比如排队买东西的人！ （剧院门票....）

如今，一切都是数字化的，这在本质上意味着它可以是可数的。这就是“消息”的存在方式！音乐混音器传统上会混合模拟信号，这些信号不可数但连续，因此信息将是 f.ex。说话的声音或任何类型的声音。今天，“消息”意味着某种信息包，它是唯一的和可数的。因此，它是一种“事物”，您可以在队列中添加和删除，或者将其发送到中心供消费者使用。

别担心，你会习惯这些条款的！我希望我能给你一个想法。