【问题标题】:Azure event grid vs service busAzure 事件网格与服务总线
【发布时间】:2020-11-11 18:08:57
【问题描述】:

可以说事件网格只是服务总线的一个子集吗?我发现服务总线可以做事件网格可以做的所有事情,甚至更多。

【问题讨论】:

标签: azureservicebus azure-eventgrid


【解决方案1】:

可以说事件网格只是服务总线的一个子集吗?

我不会试图将这些服务等同起来。它们都处理消息,但目的却截然不同。以及使用时的实现细节。

Azure 服务总线是一种企业消息传递产品。它涵盖了排队、发布/订阅,并具有多种基于计算的功能。接收是通过轮询(长轮询)完成的,通常,一个命名空间是在单个组织内部/由单个组织访问的。

Azure 事件网格是一种通知服务。它的唯一目的是在事件生成器和订阅者之间启用发布/订阅。它没有排队语义。消息传递是基于推送的,与服务总线不同,只有少数基于计算的功能可用。该服务旨在允许多方之间进行通信,并且可以作为发布者和/或订阅者跨越多个组织。

我发现服务总线可以做事件网格可以做的所有事情,甚至更多。

看起来可能是这样,但并不完全如此。 Azure 服务总线和事件网格的限制和约束完全不同。例如,Azure 服务总线命名空间仅限于单个区域。事件网格是全局的,没有那种约束。服务总线需要有限数量的连接来轮询消息,而事件网格有大量可以推送消息的订阅者。当然,交付方式不同(轮询与推送)等等。

如果您需要在组织内发布/订阅,Service Bus 可以。一旦您需要推送有关组织外部某些事件的通知,这就是事件网格的亮点。两者也可以混合使用。可以使用服务总线队列或主题对来自事件网格的事件进行排队以平衡工作负载。

【讨论】:

  • 您能否将事件中心也与事件网格/服务总线进行比较?谢谢
  • 事件中心是一个摄取器。它的目的是允许捕获大量消息(想想遥测类型的卷)进行处理。最明显的区别是数据被存储而不是在任何地方传递。您需要自己创建“阅读器”并管理光标。或者,可以将数据卸载到存储帐户或数据湖中以供以后处理。我通常通过关注单个事件的价值来区分 EH 和 EG。对于 EH,单个事件是没有意义的。流作为一个整体很重要。对于 EG,每个事件都很重要,因为它具有商业价值。
  • 我已阅读您的回答。我仍然相信,如果你有一个为你提供 Pub/Sub 和排队功能的 Azure 服务总线,你就不需要一个事件网格。当您有一个队列并且逻辑应用可以订阅队列以获取消息时,为什么您仍应在它们之间使用事件网格?这是不必要的。因为只要有新消息进入队列(或主题),逻辑应用就会得到它。为什么我需要通过事件网格通知逻辑应用程序?
  • 如果你有一个 Azure 服务总线访问。当您有多个订阅者对您的信任网络之外的事件感兴趣时,您不会将连接字符串分发给您的服务总线。相反,您希望将通知/消息推送到订阅者将提供的 webhook。想象一下成百上千的感兴趣的订阅者,并且需要使用更新的连接字符串来修改它们。这实际上取决于您正在处理的场景。如果您可以信任订阅者连接到代理,那很好,只使用 ASB。否则,EG。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-01-04
  • 2021-08-17
  • 1970-01-01
  • 1970-01-01
  • 2021-12-19
  • 1970-01-01
  • 2020-06-28
相关资源
最近更新 更多