在同一个 azure 函数应用程序下部署多个函数不起作用

Question

尝试将3个不同类型的函数（CosmosDBTrigger/TimerTrigger/HttpTrigger）部署在同一个azure函数应用服务账户中，附上文件夹结构以供参考。

功能未按预期工作，但在成功部署后抛出错误。

收到的期望：

函数 (CopyToQueue) 错误：Microsoft.Azure.WebJobs.Host：索引方法“CopyToQueue”时出错。Microsoft.Azure.WebJobs.Host：无法将参数“ inputCloudSyncJobModels ”绑定到类型 IEnumerable`1。确保绑定支持参数类型。如果您使用绑定扩展（例如 Azure Storage、ServiceBus、Timers 等），请确保您已在启动代码（例如 builder.AddAzureStorage()、builder.AddServiceBus() 中调用了扩展的注册方法)、builder.AddTimers() 等）。

函数声明之一如下：

       public static async Task Run([**TimerTrigger**(scheduleExpression: "%TimerConfig%")]TimerInfo myTimer,
            [CosmosDB(databaseName: "%DatabaseName%",
            collectionName: "%InputCollection%",
            SqlQuery ="%JobsSelectQuery%",
            ConnectionStringSetting = "CosmosDBConnectionString")]
            IEnumerable<object> **inputCloudSyncJobModels**,
            [Queue(queueName: "%JobsQueueName%", Connection = "StorageConnectionString")] IAsyncCollector<string> outputCloudQueueModels,
            Microsoft.Extensions.Logging.ILogger log, ExecutionContext context)

如果我在不同的单独 azure 函数应用程序服务下部署相同的函数，则它们无需任何修改即可运行。

当这些功能部署在相同的 azure 功能应用服务下时，请建议如何使这些功能成为工作功能。

Answer 1

我不同意Marc 的回答。虽然它可能会偏离文档化的标准，但从架构的角度来看，在同一个 App Service 下包含多个相关功能是非常好的。这在使用服务主体秘密和对象 ID 时非常方便。

解决方案：

将所有三个函数打包在不同的目录中，即 CosmosDBTrigger、TimerTrigger、HttpTrigger 作为单独的函数，但对这三个函数使用一个 SINGLE host.json。请注意：您需要在一个文件中包含所有三个函数的主机信息。然后在部署后，您将在单个应用程序服务下看到多个功能。同样在单击资源后的门户中，您将被重定向到应用服务仪表板，然后在功能选项卡下，您可以分别访问每个功能。

Answer 2

Azure Functions 的部署单位是每个应用服务一个 Function App（项目）。您的屏幕截图表明您将三个单独的功能应用部署到一项应用服务。我建议您将这三个项目合并为一个项目，这样它最终会像这样：

- MyFunctionApp
  - MyTimerTriggerFunction.cs
  - MyQueueTriggerFunction.cs
  - MyCosmosDBTriggerFunction.cs
  - MyGraphApiWebhookFunction.cs
  - Models
  - ...
  - host.json
  - local.settings.json

这也是文档中描述的推荐做法。我建议向项目添加子文件夹，以便您可以将相关函数和依赖类分组在一起。

我还在博客中介绍了何时将函数组合在一起的一些准则。

我当前使用的解决方案结构的现实示例。

更新

正如评论中提到的，虽然从技术上来说显然可以将多个 Function App 项目（GitHub 问题）部署到一个 Function App Service，但我建议不要这样做，因为：

1. 它偏离了记录的标准，因此熟悉该解决方案需要新开发人员付出额外的努力。
2. 当前的开发工具不支持这种结构。这意味着您必须执行额外的任务（手动或脚本化）才能在本地和 CI/CD 管道中运行和调试函数应用。
3. 通过 GitHub 上提到的解决方案，您最终仍然得到一个 Function App。该应用程序将包含各种包含函数的程序集，但函数应用程序作为一个整体进行管理和缩放。如果您在考虑扩展性、可用性和弹性方面的要求因某个功能而异，我强烈建议您将这些功能放在单独的功能应用程序中（再次请参阅博客文章）。

由于您担心的是复杂性和维护性的增加，我想说，只要您/您的团队应用干净的编码原则，将（一组内聚的）功能放入一个项目中就会降低复杂性和维护性。