我们的应用程序由7个微服务组成，这些微服务具有一些相互通信。目前我们正在使用微服务发布事件的简单存储队列（事件数量相对较低）。然后我们为每个可能调用另一个微服务的队列设置了azure函数。这对我们来说工作正常，现在服务使用大约20个具有相应功能的队列。
现在我们需要处理一个blobstorage事件，我做了一些谷歌搜索，开始变得非常困惑。突然间出现了很多问题：
我真的很感谢对这个问题的任何建议或见解。
由于
答案 0 :(得分：3)
当您向多个订阅者发送通知时，EventGrid非常棒。那是你的情况吗？
一个例子是推迟消息。使用队列，您可以推迟消息，而不是使用EventGrid。无论何时选择存储队列或服务总线取决于您具有的特定要求。你需要重复数据删除吗？还是订购了？如果你这样做，Service Bus就是这样。否则存储队列就足够了。
答案 1 :(得分：3)
首先，我想推荐这两篇文章，它将澄清您对这些服务的大部分疑虑：
关于事件网格，它就像发布者和订阅者之间的桥梁，发布者将发送消息并忘记它是否已被处理，如果接收者\订阅者不承认，事件网格将处理重试已成功处理。
正如您所提到的，存储队列具有局限性，例如blob触发功能，可能还有Service Bus，但这取决于您的设计要求。在转到Event Grid之前，我想指出一些你可能会考虑的事情。
存储队列＆amp; Service Bus不关心你的消息模式，在Event Grid中你必须根据他们的模式创建一个自定义事件来包装你的事件，所以发布者和订阅者必须理解Event Grid，这不是什么大问题，但是现在你的双方都加入了Event Grid。
如果您想将活动直接发送到您的微服务，您必须在您的服务中实施订阅验证，否则该服务将无法接收活动
事件网格仅重试24小时内的邮件传递，如果您的服务已关闭或未正确处理邮件超过24小时，则会导致事件失效。目前，无法查询死信息。存储队列和服务总线可以配置多长时间保留消息，并且可以保存多天。
您的服务网络挂钩必须在60秒内确认事件的收据（http 200或202），否则将认为失败。如果您的操作时间长，则应将其发送到队列并处理来自您服务的锁定。
可能还有更多限制，但这些是我现在记得的可能很快就会改变的，我认为Event Grid在早期仍然是一项伟大的技术，并且还有很多需要改进的地方，我只会重新开始Azure管理事件的中心，我认为它不适合用作应用程序集成商。
关于队列管理器的注释，对于Service Bus，您有Service Bus资源管理器，对于Azure存储，您有Azure存储资源管理器，您可以在其中检查队列中的消息，与服务总线不同，但是帮助
答案 2 :(得分：0)
这在很大程度上取决于您如何使用队列消息，您可以查看此比较：https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
如果您不需要订购，如果您对邮件量，大小或TTL没有强烈限制，则可以坚持使用存储队列。