在 Azure 中，我们有两种独立的消息传递技术，并且没有很好地记录何时使用什么？虽然 EventGrid 真的很酷，但我没有遇到什么时候使用 EventGrid(scenarios) 与 Storage/ServiceBus 队列？有人可以帮忙吗？
例如如果我有以下情况：
标志的状态发生变化，基于此，我想触发一个算法，该算法将在数据库中进行重新计算、少量插入/更新等。
为了实现这一点 - 我可以使用 EventGrid 或存储队列。我们如何确定在这种情况下使用什么？我正在寻找某种指导。
【问题讨论】：
标签： azure servicebus azure-eventgrid
基本上，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-choosing-the-right-azure-messaging-service-for-your-data/
【讨论】：
事件就像来自服务的通知，用于通知世界发布者的域中发生了某些事情（类似于电子邮件通知）。发布者不希望采取任何行动。消息是您发送给特定接收者的命令，期望消息被处理（如异步发布请求）。
事件将以发布/订阅模式工作，并且可以为事件配置多个订阅者。需要对事件做出反应的服务将在事件发生时得到事件网格的通知（从事件网格到接收器的 http 调用）。该事件将保留在事件网格中，直到删除（清理）并且不保证保持原始顺序（无 FIFO）。
另一方面，消息将被添加到队列中，并在“消息处理器”完成后被删除。队列中的消息将保持原始顺序（FIFO）。消息处理器必须从队列中拉取消息。
在您的场景中，您可以将两者结合使用。服务 A 发送一个事件“StatusChanged”，然后您可以配置对该事件的订阅并将消息发送到队列，然后让您的逻辑来处理该消息。这将以完全异步的通信模式结束。这是支持处理器停机或太忙的情况的理想选择。传入的消息将简单地累积在队列中，并最终在服务备份并运行后得到处理。并且不影响发送“StatusChanged”事件的原始服务..
【讨论】：