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

Question

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

下面的所有消息传递系统都提供了具有不同功能集的服务之间的松散耦合。
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有帮助的

Answer 1

即使所有这些服务都处理从源到目标的数据传输，并且可能看起来很相似，属于它们在意图上有所不同的伞形消息传递服务。
高级定义:

Azure 事件网格 – 事件驱动的发布订阅模型(想想响应式(Reactive)编程)

Azure 事件中心 – 多源大数据流管道(想想遥测数据)

Azure 服务总线 - 传统的企业代理消息传递系统(取代 Azure 队列存储)

之间的区别事件网格 & 事件中心

事件网格 不保证事件的顺序，但 事件中心 使用有序序列的分区，因此它可以维护同一分区中事件的顺序。

事件中心 仅接受用于摄取数据的端点，并且不提供将数据发送回发布者的机制。另一方面，事件网格 发送 HTTP 请求以通知发布者中发生的事件。

事件网格 可以触发 Azure 函数。在的情况下事件中心 ，Azure 函数需要拉取和处理事件。

事件网格 是一个分发系统，而不是一个排队机制。如果一个事件被插入，它会立即被推出，如果它没有得到处理，它就永远消失了。除非我们将未传递的事件发送到存储帐户。这个过程被称为死信。

在 事件中心 数据最多可保存 7 天，然后重播。这使我们能够从某个点恢复或从较旧的时间点重新启动并在需要时重新处理事件。

之间的区别事件中心 & 服务总线
致外部发布者或接收者 服务总线 和 事件中心 可能看起来非常相似，这就是很难理解两者之间的差异以及何时使用什么的原因。

事件中心 专注于事件流，其中 服务总线 更像是传统的消息传递代理。

服务总线 用作将在云中运行的应用程序连接到其他应用程序或服务并在它们之间传输数据的主干，而 事件中心 更关心接收海量数据，高吞吐量，低延迟。

事件中心 将多个事件生成器与事件接收器分离，而 服务总线 旨在解耦应用程序。

服务总线 消息传递支持消息属性“生存时间”，而事件中心的默认保留期为 7 天。

服务总线 有消息 session 的概念。它允许根据 session ID 属性关联消息，而事件中心则不允许。

服务总线 消息被接收器拉出并且无法再次处理，而事件中心消息可以被多个接收器摄取。

服务总线 使用队列和主题的术语，而 事件中心 使用分区术语。

使用这个宽松的一般经验法则。
出事了 – 偶数集线器
做点什么或给我点什么 – 服务总线
正如@Louie Almeda 所说，您可能会发现此 link到官方 Azure 文档很有用。