amazon-web-services - AWS Lambda - 使用 .NET Core 构建无服务器 API
问题描述
最近我一直在研究 AWS Lambda 以及如何使用 .Net Core 构建无服务器 API。据我了解,您可以通过两种不同的方式进行操作。
1) 在 C# 中编写多个单独的 Lambda 并将它们部署到 AWS。请求通过 API 网关进入,每个 lambda 充当端点。
2) 使用 .Net 核心构建无服务器 Web API。当您创建无服务器 Web API 项目时,会自动创建一个 Lambda,它会成为 Web API 的入口点。
1 对 2 是否有任何限制,或者一种方法可能比其他方法更有益的用例?还是只是实现同一件事的两种不同方式?
解决方案
我不认为你的选择是正确的。构建 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 的产品项目。它们都将存在于同一个解决方案中,并将单独部署。我目前正在研究一种一次性部署整个解决方案的方法。
推荐阅读
- java - Spring Boot 错误控制器检索原始请求
- c# - 取消会议的事件?
- angular - 如何检测Angular 6中子指令的变化
- java - 文件扫描器:未报告的异常 FileNotFoundException;必须被抓住或宣布被扔掉
- r - 如何自动将一些系数相乘并添加到R中的数据框中?
- php - 使用 MULTIPLE Inputs 上传多个文件
- string - String vs Varchar Hive 查询性能
- sql - T-SQL 查询:查找最频繁的值对
- github - Jenkins - 如果从管道作业中发布新标签,则触发构建
- angular - 我的 Angular 6 http put 请求出现错误