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