最近我一直在研究 AWS Lambda 以及如何使用 .Net Core 构建无服务器 API。据我了解，您可以通过两种不同的方式进行操作。
1) 用 C# 编写多个单独的 Lambda 并将它们部署到 AWS。请求通过 API 网关进入，每个 lambda 充当端点。
2) 使用 .Net 核心构建无服务器 Web API。当您创建无服务器 Web API 项目时，会自动创建一个 Lambda，它会成为 Web API 的入口点。
1 与 2 之间是否存在任何限制，或者一种方法可能优于其他方法的用例？还是只是实现同一目标的两种不同方式？
【问题讨论】：
标签： amazon-web-services asp.net-web-api aws-lambda serverless
我认为您的选择不正确。构建 Lambda 支持的 API 的两个选项是：
1- 在一个或多个项目中构建 lambda 并将它们独立部署到 AWS。然后手动创建指向您的一个或多个 lambda 的 API Gateway 端点。
2- 使用无服务器项目将您的 lambda 表达式组合到一个项目中。在该项目中定义您的端点，并让 Cloudformation 创建 API Gateway 端点并将它们连接到部署时的 lambda。
利弊，
选项 1：
优点： 具有独立部署 lambda 的灵活性，您也可以按照自己的意愿配置 API 网关端点，而无需了解 Cloudformation 定义语法，根据我的经验，这需要一些时间。
缺点：如果您有很多 lambda，这将成为管理的噩梦。此外，您的端点定义不在源代码中，并且不会跟踪对端点配置的更改。
选项 2：
优点：如果您了解 Cloudformation，或者如果您想使用默认配置，则部署 lambda 并将其连接到 API Gateway 端点非常容易。 AWS 将为您创建终端节点，并将创建开发和生产阶段、策略、IAM 角色等。这由 Cloudformation 直接从 Visual Studio 部署导致整个部署和所有相关对象落入 AWS Cloudformation 中的同一“堆栈”下它可以很容易地更改、复制或删除。此外，您的基础架构现在是代码，对它的更改可以在您的 git 存储库中审核。
缺点：我认为最大的缺点是堆栈不跨越 VS 解决方案，而只是跨越项目，所以你所有的 lambdas 都必须存在于同一个项目中，这意味着如果你有很多，它们最终将全部集中在一个整体 lambda 二进制文件中。生成的大型项目二进制文件将花费您在 AWS 上的内存运行时间和效率问题。另一个缺点是，如果您想拥有特定的或与众不同的 API 网关，您需要了解 Cloudformation 语法才能更改您的 serverless.template 文件。
结论：我首选的解决方案是根据 API 对象将我的真实应用程序分成更小的相关 lambdas 块，并将这些 lambdas 放在几个无服务器应用程序项目中。例如，我有一个包含与订单 API 相关的所有 lambdas 的订单项目，以及一个包含与产品 API 等相关的 lambdas 的产品项目。它们都将存在于同一个解决方案中，并将单独部署。我目前正在研究一种一次性部署整个解决方案的方法。
【讨论】：