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