问题描述
在Azure函数中，你可以创建一个函数来监听消息总线、blob存储等事件的某种变化...
如果您正在使用 azure 函数，并且您的目标是通过侦听事件（例如消息总线、blob 存储或任何其他内置触发器）来处理某些事情，那么您是否有任何理由要将事件网格放在中间层 ？即，不是 azure 函数直接侦听 blob 存储更改，而是希望 azure 函数侦听正在侦听 blob 存储更改事件的事件网格。
谢谢
解决方法
这取决于您的需求。以存储和 blob 为例，如果您只需要在创建 blob 时收到通知，匹配您使用 BlobTrigger 配置的任何路径、名称、扩展名和其他过滤器，那么使用 EventGrid 就没有意义了。
但是，如果您需要配置一个函数以同时使用多个存储帐户，则需要 BlobTrigger 不支持的高级过滤，或者在特殊事件上触发（例如，当创建、删除或删除目录时）重命名），那么你需要 EventGrid。
一个稍微（但不太牵强）的例子如下：
考虑到每当在存储 1、2、3 ... n 中创建 blob 时，您都需要一个函数来触发。事实上，它可以是任意数量的不同存储，并且会随着时间而变化。现在，您需要为每个存储设置一个函数，定义一个 BlobTrigger，或者一个函数，定义多个 BlobTrigger，并在应用程序设置中配置大量连接字符串。这显然不是很方便维护，因为每次需要触发更改的任意数量的存储（主要是添加新存储时）时，您都必须更改函数。
EventGrid 来救援。您现在可以通过订阅管理触发函数的内容，每个存储一个，而无需更改函数的代码。您当然需要一种不同的方法来与存储进行通信，而不是通常的连接字符串；你可能需要像 StorageManagementClient 这样的东西。当然，您会丢失自动 blob 绑定。这可以通过实现您自己的扩展（自定义绑定）来规避。 I've already written an answer 涵盖了如何做到这一点（尽管它用于将数组/列表绑定到 HttpTrigger）。
您可能还可以使用 EventGrid 自动化订阅管理（或者更确切地说，通知一些代码来创建订阅）。示例：所有存储都集中在一个资源组中。 EventGrid 支持在资源组中的某些内容发生更改时触发，并且使用 EventGrid 订阅的高级过滤器，您应该能够将其配置为仅在创建或删除存储帐户时触发。
无论如何，这确实是一个需要的问题。上面的例子可能有点牵强。但是也有一些用例，Functions 本身不支持，像 EventGrid 这样的东西可以让它工作。
,是的，这取决于场景。