在同一个Azure功能应用程序下部署多个功能不起作用

Question

尝试在同一个Azure功能应用程序服务帐户中部署3种不同类型的功能（CosmosDBTrigger / TimerTrigger / HttpTrigger），并附上文件夹结构以供参考。

功能无法正常运行，但在成功部署后会引发错误。

收到的奖励：

函数（CopyToQueue）错误：Microsoft.Azure.WebJobs.Host：错误索引方法“ CopyToQueue”。 Microsoft.Azure.WebJobs.Host：无法绑定参数“ inputCloudSyncJobModels ”以键入IEnumerable`1。确保绑定支持参数类型。如果您使用绑定扩展（例如Azure存储，ServiceBus，Timer等），请确保已在启动代码中调用了扩展的注册方法（例如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's answer。尽管它可能会偏离已记录的标准，但是从体系结构的角度来看，最好在同一App Service中包含多个相关功能。使用服务主体机密和对象ID时，这非常方便。

解决方案：

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

Answer 2

Azure功能的部署单位是每个应用程序服务一个功能应用程序（项目）。屏幕快照表明您将要部署到一个应用程序服务的三个独立的功能应用程序。我建议您将三个项目合并到一个项目中，这样它就可以像这样：

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

这也是in the docs中所述的推荐做法。我建议将子文件夹添加到项目中，以便可以将相关功能和相关类分组在一起。

我还blogged about some guidelines何时将功能分组在一起。

我目前使用的solution structure的真实示例。

更新

如评论中所述，尽管从技术上来说似乎可以deploy multiple Function App projects (GitHub issue)到一项功能应用服务，但我还是建议不要这样做，因为：

1. 它偏离了已记录的标准，因此熟悉该解决方案需要新开发人员付出更多的努力。
2. 当前的开发工具不支持此结构。这意味着您必须手动或编写脚本来执行其他任务，才能在本地和CI / CD管道中运行和调试功能应用程序。
3. 有了GitHub上提到的解决方案，您仍然可以得到一个Function App。该应用程序将包含各种包含函数的程序集，但Function App将被管理并缩放为一个。如果您考虑扩展，可用性和弹性的需求因一项功能而异，我强烈建议将这些功能放在单独的功能应用程序中（再次请参见the blogpost）。

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