我需要重构 .Net Web API，我正在考虑转向无服务器，并且我正在尝试了解将代码迁移到 Azure Functions 的最佳选择。
据我所知，降低成本和冷启动时间的正确方法是拆分 API:拥有许多小型 Web API 比拥有所有方法的单个 Web API 要好得多。小 API 消耗内存更少，冷启动更快。
在同一个项目中拥有更多函数并不能解决问题，因为它们将全部部署在同一个函数应用程序中，因此只有一个 dll、内存高、冷启动慢。 因此，我应该创建多个 Azure Function 项目，并将每个项目部署在不同的 Function App 中。
如果以上所有内容都正确，我们终于解决了问题: 我将构建代码和存储库，以便我拥有一个包含多个 Azure Function 项目的解决方案。如何拥有 CI/CD (Azure DevOps)，以便在推送存储库时仅部署更新/修改/新的 Azure 函数项目？我只需要部署修改后的 Azure Function 项目，以免所有 Function Apps(以及代码未更改的应用程序)变冷。
这不太重要，但我还需要为所有 API 提供一个 URL，因此 https://myapi.azurewebsites.net/api/Function1 , https://myapi.azurewebsites.net/api/Function2等而不是https://myapi1.azurewebsites.net/api/Function1 , https://myapi2.azurewebsites.net/api/Function1等等。使用上面的结构可以吗？
最佳答案
您需要有多个 CI/CD 管道，且触发器仅限于特定文件夹:
trigger:
paths:
include:
- function-a/*
exclude:
- '*'
为此，仅当在 function-a 文件夹中完成更改时，才会触发管道。为了限制开发管道所需的工作，您应该考虑使用模板。您可以在这里找到更多相关信息:
这样你就可以避免重复自己。
编辑
要统一您的 API，您可以使用 Azure Functions Proxies
With this feature, you can specify endpoints on your function app that are implemented by another resource. You can use these proxies to break a large API into multiple function apps (as in a microservice architecture), while still presenting a single API surface for clients.
关于azure-devops - 当我推送整个解决方案的存储库时，是否可以仅部署更新的 Azure Function 项目？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61475946/