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

时间:2019-08-31 18:44:26

标签: message-queue azureservicebus azure-eventhub servicebus azure-eventgrid

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

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

queue-先进先出(FIFO),拉动机制,每个队列1个使用者,但生产者数目不限?

message bus-发布/订阅模型,任何数量的消费者,任何数量的生产者都在处理消息? Azure Service Busmessage bus的实现吗?

event bus-发布/订阅模型,具有多少生产者处理事件的任何数量的消费者?

就术语而言,人们是否会交替使用message busevent bus

事件和消息之间有什么区别?在这种情况下,这些仅仅是同义词吗?

event hub-发布/订阅模型,分区,重播,使用者可以将事件存储在外部存储中或接近实时数据分析。事件中心到底是什么?

event grid-可用作事件中心的下游服务。 event hub不做到底是什么?

有人能提供一些历史背景吗,因为每种技术如何与某些实际用例结合在一起?

我发现message bus vs. message queue有用

4 个答案:

答案 0 :(得分:6)

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

事件与消息服务

有一个重要的区别要注意 提供事件的服务与提供事件的服务之间 消息。

事件

事件是状态或状态的轻量级通知 更改。活动的发布者对如何 事件已处理。事件的使用者决定如何处理 通知。事件可以是离散的单元,也可以是系列的一部分。

离散事件报告状态更改并且可以执行。采取 下一步,消费者只需要知道发生了什么事即可。 事件数据具有发生了什么但没有发生的信息 触发事件的数据。例如,一个事件通知 使用者已创建文件。它可能有一般信息 关于文件,但它本身没有文件。离散事件 非常适合需要扩展的无服务器解决方案。

系列赛事 报告情况并且可以分析。这些事件是按时间排序的, 相关。消费者需要按顺序排列的一系列事件来 分析发生了什么。

消息

消息是服务产生的要消费或存储的原始数据 别处。该消息包含触发该消息的数据 管道。消息的发布者对如何 消费者处理该消息。两者之间存在合同 双方。例如,发布者发送包含原始数据的消息, 并希望使用者根据该数据创建文件并发送 工作完成后做出回应。

还讨论了这些不同服务的比较,因此请务必检查一下。

答案 1 :(得分:2)

关于“公共汽车”,我可以为您提供一些“历史”信息,因为我学会了成为一名音响工程师。在音乐混音器中,您还具有用于混合信号的“总线”和“路由”。对于调音台,我们正在谈论的是电信号,无论是混音还是不混音!

关于消息传递系统,请将“总线”,“集线器”和“网格”视为同义词!他们都是同一件事的幻想词。他们试图表达一种包含某种路线的运输系统,因为您总是有生产者和消费者-这可能是N:M关系。视使用情况而定。

队列通常有所不同,但是其效果可以相同。排队意味着排队的东西,例如排队买东西的人! (剧院门票...。)

如今,所有事物都是数字化的,从本质上讲,这意味着它可以计数。这就是“消息”出现的方式!传统上,音乐混音器将混合不可计数但连续的类似信号,因此信息将为f.ex。语音或任何声音。今天,“消息”是指某种信息包,它是唯一且可计数的。因此,这是您可以添加到队列中或从队列中删除的“事物”,或将其发送到供消费者使用的集线器。

别担心,您会习惯那些条款!希望我能给你个主意。

答案 2 :(得分:1)

我同意您关于重载条款的评论,尤其是对于云服务营销术语。...

从历史上看,我的事件和消息具有更明显的含义 -事件是指同一过程中的交流,而 -消息是指不同过程之间的通信。

答案 3 :(得分:0)

即使所有这些服务都处理从源到目标的数据传输,并且看起来好像属于消息传递服务,但它们的意图确实有所不同。

高级定义:

  • Azure事件网格 –事件驱动的发布-订阅模型(认为是反应式编程)
  • Azure事件中心 –多源大数据流传输管道(认为遥测数据)
  • Azure服务总线-传统的企业代理消息传递系统(代替Azure队列存储)

事件网格事件中心

之间的区别
  1. 事件网格不保证事件的顺序,但是事件中心使用按顺序排列的分区,因此可以在事件列表中维护事件的顺序。相同的分区。
  2. 事件中心仅接受用于数据提取的端点,并且不提供将数据发送回发布者的机制。另一方面,事件网格发送HTTP请求以通知发布者中发生的事件。
  3. 事件网格可以触发Azure功能。对于事件中心,Azure功能需要拉出并处理事件。
  4. 事件网格是一个分发系统,而不是排队机制。如果事件被推送,事件将立即被推送,如果事件未被处理,事件将永远消失。除非我们将未交付的事件发送到存储帐户。此过程称为死信。
  5. 事件中心中,数据最多可以保存7天,然后重播。这使我们能够从某个点恢复或从较旧的时间点重新开始,并在需要时重新处理事件。

事件中心服务总线

之间的区别

对于外部发布者或接收者,服务总线事件中心可能看起来非常相似,这使得很难理解两者之间的区别以及何时需要用什么。

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

使用这种宽松的一般经验法则。

已发生某些事情– 甚至是集线器

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

如@Louie Almeda所述,您可能会发现link对Azure官方文档很有用。