在 Azure 中，我们有两种独立的消息传递技术，并且没有很好地记录何时使用什么？虽然 EventGrid 确实很酷，但我没有遇到何时使用 EventGrid（场景）与存储/ServiceBus 队列？有人可以帮忙吗？
例如如果我有以下情况：
标志的状态发生变化，基于此，我想触发一个算法，该算法将在数据库中进行重新计算、少量插入/更新等。
为了实现这一点 - 我可以使用 EventGrid 或存储队列。我们如何确定在这种情况下使用什么？我正在寻找某种指导。
基本上，Azure 事件网格处理事件，Azure ServiceBus 处理消息。消息是由服务生成的要使用或存储的原始数据。事件也是消息（轻量级），但除了通知之外，它们通常不传达发布者的意图。
1）如果目的只是为了存储信息，可以使用ServiceBus。
2) 如果接收到的信息用于触发另一个服务，则可以使用 Azure 事件网格。
在此处查找更多信息
https://learn.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）。
另一方面，消息将被添加到队列中，并在“消息处理器”处理完毕后被删除。队列中的消息将保持原始顺序（先进先出）。消息处理器必须从队列中提取消息。
在您的场景中，您可以结合使用两者。服务 A 发送一个事件“StatusChanged”，然后您可以配置对该事件的订阅并将消息发送到队列，然后让您的逻辑处理该消息。这最终将形成完全异步的通信模式。这非常适合支持处理器停机或太忙的情况。传入的消息将简单地累积在队列中，并最终在服务备份并运行后得到处理。并且不会影响发送“StatusChanged”事件的原始服务..
这是 Azure 课程。
当您想要一个简单且易于编码的队列系统时，请使用存储队列。对于更高级的需求，请使用服务总线队列。如果单个消息有多个目标，但需要类似队列的行为，请使用服务总线主题。