1

我们的应用程序由 7 个具有一定互通性的微服务组成。目前我们正在使用微服务发布事件的简单存储队列（事件数量相对较少）。然后我们为每个可能调用另一个微服务的队列创建一个 azurefunction。这对我们来说很好，现在服务使用了大约 20 个具有相应功能的队列。

现在我们需要处理一个 blobstorage 事件，我做了一些谷歌搜索，然后开始变得非常困惑。突然有很多问题：

  • 我们是否应该切换到 Azure 事件网格
    • 它处理 blobstorage 没有任何限制（功能 blobstorage 触发器有一些）
    • 它允许多个订阅者（存储队列不允许）
    • 它有很多模糊 - 也许这是新的推荐方式
    • 我喜欢一个核心的想法，但它让我想起了一些关于 biztalk...
  • 我应该切换到 Azure 服务总线
    • 它有一个很好的工具（ServiceBusExplorer）来监控队列和监听器，我可以重新发布任何失败的事件
    • 它很好地展示了我的天蓝色功能订阅者
  • 我应该继续只使用存储队列吗
    • 监控有点困难，但效果很好

对于这个问题的任何建议或见解，我将非常感谢。

谢谢

4

3 回答 3

4

当您将通知浮动到多个订阅者时，EventGrid 非常棒。你是这种情况吗？

一个例子是延迟消息。使用队列，您可以延迟消息，而不是使用 EventGrid。何时选择存储队列或服务总线取决于您的具体要求。您需要重复数据删除吗？还是下单发货？如果你这样做了，Service Bus 就是你的选择。否则存储队列就足够了。

于 2018-03-08T09:41:47.343 回答
3

首先，我想推荐这两篇文章，它将澄清您对这些服务的大部分疑问：

关于事件网格，它就像发布者和订阅者之间的桥梁，发布者将发送消息并忘记它是否已被处理，如果接收者\订阅者不承认它已处理，事件网格将处理重试处理成功。

正如您所提到的，存储队列有局限性，例如 blob 触发的功能，可能还有服务总线，但这取决于您的设计要求。我想指出一些您在迁移到事件网格之前可能会考虑的事情。

  • 存储队列和服务总线不关心您的消息架构，在事件网格中，您必须根据他们的架构创建自定义事件来包装您的事件，因此发布者和订阅者必须了解事件网格，这不是一个大问题交易，但现在双方都耦合到事件网格。

  • 如果你想将事件直接发送到你的微服务，你必须在你的服务中实现订阅验证，否则服务将无法接收事件

  • 事件网格仅在 24 小时内重试您的消息传递，如果您的服务关闭或超过 24 小时未正确处理消息，它将使事件死亡。目前，没有办法查询死消息。存储队列和服务总线可配置您保留消息的时间，并且可以保留很多天。

  • 您的服务 web-hook 必须在 60 秒内确认收到事件（http 200 或 202），否则将视为失败。如果您的操作更长，您应该将其发送到队列并处理来自您的服务的锁定。

可能还有更多限制，但这些是我现在记得的，可能很快就会改变，我认为 Event Grid 仍然是早期的一项伟大技术，还有很多需要改进的地方，我只会重新开始作为 Azure 的中心管理事件，我认为它还没有准备好用作应用程序集成商。

关于您对队列管理器的评论，对于 Service Bus，您有 Service Bus Explorer，对于 Azure Storage，您有 Azure Storage Explorer，您可以在其中检查队列中的消息，这与 Service Bus 不同，但有帮助。

于 2018-03-11T13:19:25.713 回答
0

这在很大程度上取决于您如何使用队列消息，您可以查看此比较：https ://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-和服务总线队列比较对比

如果您不需要排序，并且对消息量、大小或 TTL 没有严格限制，则可以坚持使用存储队列。

于 2018-03-08T10:37:53.567 回答