我应该改变我们的微服务通信方式吗？答案

【问题标题】：Should I change how our microservices communicate?我应该改变我们的微服务通信方式吗？
【发布时间】：2018-03-08 09:26:18
【问题描述】：

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

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

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

非常感谢您对此问题的任何建议或见解。

谢谢

【问题讨论】：

标签： azure azure-functions azureservicebus azure-storage-queues azure-eventgrid

【解决方案1】：

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

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

【讨论】：

谢谢。目前不需要延迟消息。目前只有一个订阅者。目前没有订购交货。但是，另一方面 - 是的，多个订阅者对于一些事件来说会很好，重复可能是一个问题......基于此 - 你的建议是使用所有三个吗？
如果发布/订阅很重要，存储队列不是一个好的选择，服务总线和事件网格更好。请记住，Event Grid 不会为您提供重复数据删除功能。您必须为每个订阅者提供一个 webhook 才能推送消息。迷人的部分是订阅者不必投票。甚至没有长民意调查。您必须查看您的具体要求，并在两者之间做出更合适的决定，或者您是否想将两者介绍给他们擅长的领域。
除了 Sean 的回答之外，事件网格还适用于跨区域、云和本地系统的近实时分布式事件驱动 Pub/Sub 模型。这是一种推送模型，每秒向每个区域分发 1000 万个事件，每个区域最多有 1000 个订阅者。事件通过重试机制以持久模式传递给事件接收器（订阅者）。它非常适合事件驱动的无服务器应用程序架构。
@SeanFeldman 您可以让 eventgrid 将事件推送到函数或逻辑应用程序，然后也将消息转发到服务总线队列。我认为对于 blob 事件，eventgrid 是要走的路。 azure 团队将迁移到 blobtrigger 的 eventgrid 实现（webjob/function sdk）
@thomas 确切地说，但前提是这些是 HTTP 触发的 ? 最终，Azure 上的任何资源都会发出事件，但如果你不能为入站呼叫挖洞，那将无济于事。顺便说一句，EventGrid 和服务总线之间的集成已经在这里，但仅适用于高级层。最终将在标准低音井。

【解决方案2】：

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

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

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

存储队列和服务总线不关心您的消息架构，在事件网格中，您必须根据其架构创建自定义事件来包装您的事件，因此发布者和订阅者必须了解事件网格，这没什么大不了的，但是现在您将双方都耦合到了事件网格。
如果你想将事件直接发送到你的微服务，你必须在你的服务中实现订阅验证，否则服务将无法接收到事件
事件网格仅在 24 小时内重试传递您的消息，如果您的服务关闭或超过 24 小时未正确处理消息，它将使事件死亡。目前，没有办法查询死消息。存储队列和服务总线可配置您将消息保留多长时间，并且可以保留很多天。
您的服务 web-hook 必须在 60 秒内确认收到事件（http 200 或 202），否则将视为失败。如果您的操作更长，您应该将其发送到队列并处理来自您的服务的锁定。

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

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

【讨论】：

2021 更新：您不必为 EventGrid 事件使用 EventGridEvent 架构，并不是说使用它是一件坏事，但您也可以按照 docs.microsoft.com/en-us/azure/event-grid/cloud-event-schema Seperate 使用 Cloud Events v1.0点，如果无法在 24 小时内将事件传递给订阅者，它们可以死信到存储帐户（Blob 容器），您可以将诊断记录到工作区，或从该操作触发更多事件或警报。

【解决方案3】：

这很大程度上取决于你如何消费队列消息，你可以看看这个比较：https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

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

【讨论】：