4

在 Azure 中，我们有两种独立的消息传递技术，并且没有很好地记录何时使用什么？虽然 EventGrid 真的很酷，但我没有遇到过什么时候使用 EventGrid(scenarios) 与 Storage/ServiceBus 队列？有人可以帮忙吗？

例如，如果我有以下情况：

标志的状态发生变化，基于此，我想触发一个算法，该算法将在数据库中进行重新计算、少量插入/更新等。

为了实现这一点 - 我可以使用 EventGrid 或存储队列。我们如何确定在这种情况下使用什么？我正在寻找某种指导。

4

2 回答 2

7

基本上，Azure 事件网格处理事件，Azure ServiceBus 处理消息。消息是由服务生成的要使用或存储的原始数据。事件也是消息（轻量级），但它们通常不传达发布者的意图，除了通知。

1）如果目的只是为了存储信息，可以使用ServiceBus。

2) 如果接收到的信息用于触发另一个服务 Azure Event Grid 可以使用。

在此处查找更多信息

https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services https://azure.microsoft.com/en-us/blog/events-data-points-and-messages -选择正确的天蓝色消息服务为您的数据/

于 2018-07-20T06:59:07.597 回答
1

事件就像来自服务的通知，用于通知世界在发布者的域中发生了某些事情（类似于电子邮件通知）。发布者不希望采取任何行动。消息是您发送给特定接收者的命令，期望消息被处理（如异步发布请求）。

事件将以发布/订阅模式工作，并且可以为事件配置多个订阅者。需要对事件做出反应的服务将在事件发生时得到事件网格的通知（从事件网格到接收器的 http 调用）。该事件将保留在事件网格中，直到删除（清理）并且不保证保持原始顺序（无 FIFO）。

另一方面，消息将被添加到队列中，并在“消息处理器”完成后将其删除。队列中的消息将保持原始顺序（FIFO）。消息处理器必须从队列中提取消息。

在您的场景中，您可以将两者结合使用。服务 A 发送一个事件“StatusChanged”，然后您可以配置对该事件的订阅并将消息发送到队列，然后让您的逻辑来处理该消息。这将以完全异步的通信模式结束。这是支持处理器停机或太忙的情况的理想选择。传入的消息将简单地累积在队列中，并在服务备份并运行后最终得到处理。并且不影响发送“StatusChanged”事件的原始服务..

于 2021-07-07T01:55:29.967 回答