Azure 事件网格与服务总线

Cap*_*row 3 azureservicebus azure-eventgrid

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

Sea*_*man 19

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

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

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

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

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

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

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

  • _如果_您有 Azure 服务总线_访问_。当您有多个订阅者对您的信任网络之外的事件感兴趣时,您不会向他们分发到您的服务总线的连接字符串。相反,您希望将通知/消息推送到订阅者将提供的 Webhook。想象一下数百甚至数千感兴趣的订阅者,以及需要使用更新的连接字符串来修改它们。这实际上取决于您正在处理的场景。如果您可以信任订阅者连接到代理,那就太好了,只使用 ASB。否则,EG。 (5认同)
  • 事件中心是一个摄取器。其目的是允许捕获大量消息(考虑遥测类型的消息量)以进行处理。最明显的区别是数据被存储而不是传送到任何地方。您需要创建“阅读器”并自己管理光标。或者,可以将数据卸载到存储帐户或数据湖中以供以后处理。我通常通过关注单个事件的价值来区分 EH 和 EG。对于 EH,单个事件毫无意义。整个流很重要。对于 EG,每项活动都很重要,因为它具有商业价值。 (2认同)