AWS Lambda - 使用 .NET Core 构建无服务器 API

Question

最近我一直在研究 AWS Lambdas 以及如何使用 .Net Core 构建无服务器 API。据我了解，您可以通过两种不同的方式来做到这一点。

1) 在 C# 中编写多个单独的 Lambda 并将它们部署到 AWS。请求通过 API 网关传入，每个 lambda 充当端点。

2) 使用 .Net 核心构建无服务器 Web API。当您创建无服务器 Web API 项目时，会自动创建一个 Lambda，它成为 Web API 的入口点。

1 对 2 是否有任何限制，或者一种方法可能优于其他方法的用例？或者它只是实现同一件事的两种不同方式？

Answer 1

我不认为你的选择是正确的。构建 Lambda 支持的 API 的两个选项是：

1- 构建 lambda 并将其独立部署到一个或多个项目中的 AWS。然后手动创建指向一个或多个 lambda 的 API 网关端点。

2- 使用无服务器项目将 lambda 组合到一个项目中。在该项目中定义您的端点，并让 Cloudformation 创建 API 网关端点并将它们在部署时连接到您的 lambda。

就利弊而言，

选项1：

优点：具有独立部署 lambda 的灵活性，您还可以按照您想要的方式配置 API 网关端点，而无需了解 Cloudformation 定义语法，根据我的经验，这需要一些启动时间。

缺点：如果你有很多 lambda，这将成为管理的噩梦。此外，您的端点定义不在源代码中，并且不会跟踪对端点配置的更改。

选项2：

优点：如果您了解 Cloudformation 或者您想使用默认配置，那么部署 lambda 并将其连接到 API 网关端点非常简单。AWS 将为您创建终端节点，并创建开发和生产阶段、策略、IAM 角色等。由 Cloudformation 直接从 Visual Studio 进行部署会导致整个部署和所有相关对象落入 AWS Cloudformation 中的同一“堆栈”下可以很容易地更改、复制或删除。此外，您的基础设施现在是代码，对其所做的更改可以在 git 存储库中进行审核。

缺点：在我看来，最大的缺点是堆栈并不跨越 VS 解决方案，而只是跨越项目，因此所有 lambda 都必须位于同一个项目中，这意味着如果你有很多，它们最终会一切都集中在一个 lambda 二进制文件中。生成的大型项目二进制文件将消耗您在 AWS 上的内存运行时间和效率问题。另一个缺点是，如果您想要特定的或不寻常的 API 网关，您将需要了解 Cloudformation 语法来更改 serverless.template 文件。

结论：我的首选解决方案是根据 API 对象将我的真实应用程序划分为更小的相关 lambda 块，并将这些 lambda 放入一些无服务器应用程序项目中。例如，我有一个订单项目，其中包含与订单 API 相关的所有 lambda，以及一个产品项目，其中包含与产品 API 等相关的 lambda。它们都将位于同一个解决方案中，并单独部署。我目前正在研究一种立即部署整个解决方案的方法。