在Azure中，我们有两种独立的消息传递技术，何时使用什么还没有很好的记录？虽然EventGrid确实很酷，但我没有遇到何时使用EventGrid（场景）vs Storage / ServiceBus队列？有人可以帮忙吗？
例如如果我有以下情况：
标志的状态发生变化，因此，我想触发一种算法，该算法可以在数据库中进行重新计算，很少的插入/更新等操作。
要实现此目的-我可以使用EventGrid或Storage Queue。我们如何确定在这种情况下使用什么？我在寻找某种指导。
答案 0 :(得分：2)
基本上，Azure Event Grid处理事件，Azure ServiceBus处理消息。消息是由服务产生的要使用或存储的原始数据。事件也是消息（轻度），但是除了通知外，它们通常不会传达发布者的意图。
1）如果仅是为了存储信息，则可以使用ServiceBus。
2）如果接收到的信息用于触发其他服务，则可以使用Azure事件网格。
在此处找到更多信息
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/
答案 1 :(得分：0)
事件就像来自服务的通知，通知全世界发布者的域中发生了某些事情（类似于电子邮件通知）。出版商不希望采取任何行动。消息是您发送给特定接收方的命令，期望消息得到处理（如异步发布请求）。
事件将以发布/订阅模式运行，并且可以为事件配置多个订阅者。需要对事件做出反应的服务将在事件发生时得到事件网格的通知（从事件网格到接收器的 http 调用）。事件将保留在事件网格中直到删除（清理），并且无法保证保持原始顺序（无 FIFO）。
另一方面，消息将被添加到队列中，一旦“消息处理器”完成处理，消息就会被删除。队列中的消息将保持原始顺序（FIFO）。消息处理器必须从队列中拉取消息。
在您的场景中，您可以结合使用两者。服务 A 发送一个事件“StatusChanged”，然后您可以配置对该事件的订阅并将消息发送到队列，然后使用您的逻辑来处理该消息。这将以完全异步的通信模式结束。这是支持处理器停机或太忙的情况的理想选择。传入的消息将简单地累积在队列中，并最终在服务恢复并运行后进行处理。并且不会影响发送“StatusChanged”事件的原始服务..