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

我正在学习消息传递系统，这些术语把我弄糊涂了。

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

先进先出，拉动机制，1消费者每个队列但有多少生产者？

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

event bus-pub/sub 模型，任意数量的消费者和任意数量的生产者处理事件？

就术语而言，人们是否交替使用 message bus和 event bus？

事件和消息之间有什么区别? 在这种情况下，它们只是同义词吗？

event hub-pub/sub 模型、分区、重放，用户可以将事件存储在外部存储器中或接近实时数据分析。活动中心到底是什么？

event grid-它可以用作事件集线器的下游服务。它到底做了什么 event hub没有做的事情？

有没有人能提供一些历史背景，比如每种技术如何演变成另一种技术，每种技术又如何与一些实际用例相联系？

我发现 消息总线与消息队列很有用

38543 次浏览
小开

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

从历史上看，“我”事件和信息有更多不同的含义 - 事件是术语，用于指在同一过程中的通信，而 - 信息指跨不同进程的通信。

小开

关于“巴士”，我可以给你一些“历史”信息，因为我学会了一个音响工程师。在音乐混音器中，还有一个“总线”和“路由”用于混合信号。在一个混合器的情况下，我们正在谈论电信号，无论是在混合或没有！

关于消息传递系统，可以把“ bus”、“ hub”和“ grid”看作是同义词！它们都是同一件事的华丽词藻。他们试图表达某种运输系统，包括某种路线，因为你总是有生产者和消费者-这可以是 N: M 关系。取决于用例。

队列通常有一点不同，但其效果可能是相同的。排队的意思是东西排成一条线，就像人们排队买东西一样！(戏票...)

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

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

小开

我发现 这个对比来自 Azure 文档非常有用。下面是事件和消息之间的关键区别。

事件与消息服务

有一个重要的区别需要注意 交付事件的服务与交付 信息。

事件

事件是条件或状态的轻量级通知 事件的发布者不期望 事件的使用者决定如何处理 事件可以是离散的单元或者是一系列事件的一部分。

离散事件报告状态更改并可执行操作 下一步，消费者只需要知道发生了什么。 事件数据有关于发生了什么的信息，但是没有 触发事件的数据。例如，一个事件通知 消费者已经创建了一个文件。它可能包含一般信息 关于文件，但它没有文件本身。离散事件 是需要扩展的无服务器解决方案的理想选择。

系列活动 事件是有时间顺序的，并且是可以分析的 使用者需要有序的一系列事件来 分析一下发生了什么。

信息

消息是服务生成的要消费或存储的原始数据 消息包含触发消息的数据 消息的发布者希望了解 消费者处理消息。两者之间存在一个契约 例如，发布者发送包含原始数据的消息, 并期望使用者根据该数据创建一个文件并发送一个 工作完成后作出反应。

比较这些不同的服务也进行了讨论，所以一定要检查出来。

小开

即使所有这些服务都处理从源到目标的数据传输，并且看起来相似，归属于保护伞消息传递服务，但是它们的意图不同。

高级别定义:

  • Azure 事件网格 -事件驱动的发布-订阅模型(响应式编程)
  • Azure Event Hubs -多源大数据流管道(想想遥测数据)
  • Azure Service Bus -传统的企业代理消息传递系统(类似于 Azure Queue，但根据用例 全面比较提供许多高级特性)

事件坐标和 活动中心的区别

  1. 事件栅格 不能保证事件的顺序，但是 活动中心使用有序序列的分区，所以它可以维护同一个分区中事件的顺序。
  2. 事件集线器 只接受摄取数据的端点，而不提供将数据发送回发布者的机制。另一方面，事件坐标发送 HTTP 请求来通知发布者中发生的事件。
  3. 事件网格 可以触发 Azure 函数。在 活动中心的例子中，Azure 函数需要提取和处理一个事件。
  4. 事件网格 是一个分布式系统，而不是一个排队机制。如果一个事件被推入，它会立即被推出，如果它没有得到处理，它就永远消失了。除非我们将未交付的事件发送到存储帐户。这个过程被称为死字。
  5. 在 活动中心中，数据可以保存长达7天，然后重播。这使我们能够从某个时间点恢复或从较早的时间点重新启动，并在需要时重新处理事件。

活动中心和 服务巴士的区别

对于外部发布者或接收者来说，服务巴士和 活动中心可能看起来非常相似，这就是为什么很难理解两者之间的区别以及什么时候使用什么。

  1. Event Hubs 专注于事件流，其中 服务巴士更像是一个传统的消息传递代理。
  2. 服务总线 用作骨干，将云中运行的应用程序与其他应用程序或服务连接起来，并在它们之间传输数据，而 活动中心更关心的是接收大量的数据，这些数据具有高通过率和低延迟。
  3. Event Hubs 将多个事件生产者与事件接收者解耦，而 服务巴士旨在将应用程序解耦。
  4. 服务总线 消息传递支持消息属性“ Time to Live”，而事件集线器的默认保留期为7天。
  5. 服务总线 具有消息会话的概念。它允许基于会话 ID 属性关联消息，而事件集线器不允许。
  6. 服务总线 消息被接收方提取出来，不能再次处理，而事件集线器消息可以被多个接收方摄取。
  7. 服务总线 使用队列和主题术语，而使用 活动中心分区术语。

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

发生了一些事情

做点什么或者给我点什么

正如@Louie Almeda 所说，您可能会发现这个 链接对于正式的 Azure 文档非常有用。


提交答案