AWS Lambda-使用.NET Core构建无服务器API [英] AWS Lambda - Building serverless API using .NET Core

问题描述

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

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

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

是否存在1对2的限制，或者用例中一种方法可能比其他方法更有利?还是只是两种不同的方式来达成同一件事?

解决方案

我认为您的选择不正确.构建Lambda支持的API的两个选项是:

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

2-使用无服务器项目将lambda组合到一个项目中.在该项目中定义您的端点，并让Cloudformation创建API Gateway端点，并在部署时将其连接到您的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项目.它们都将存在于同一解决方案中，并将分别部署.我目前正在研究一种可以立即部署整个解决方案的方法.

Recently I have been looking into AWS Lambdas and how to build Serverless API using .Net Core. From what I understand, you can do it in 2 different ways.

1) Write multiple separate Lambdas in C# and deploy them to AWS. Requests come in via API gateway and each lambda acts as an endpoint.

2) Build a Serverless Web API using .Net core. When you create the serverless Web API project a Lambda is automatically created which becomes the entry point to the Web API.

Are there any limitations of 1 vs 2, or use cases where one approach might be beneficial over other? Or is it just 2 different ways of achieving the same thing?

解决方案

I don't think your options are correct. The two options for building a Lambda backed API are:

1- Build lambdas and deploy them independently to AWS in one or more project. Then Manually create API Gateway endpoints that point to your one or more lambdas.

2- Use a Serverless project to combine your lambdas in one project. Define your endpoints in that project and have Cloudformation create the API Gateway endpoints and hook them up to your lambdas on deployment.

As far as pros and cons,

Option 1:

Pros: has the flexibility of deploying lambdas independently, also you can configure your API Gateway endpoints however way you want without having to understand Cloudformation definition syntax which took some ramp up time in my experience.

Cons: If you have a lot of lambdas this becomes a management nightmare. Also your endpoint definition is not in the source code and changes to the endpoint configuration will not be tracked.

Option 2:

Pros: If you figure out Cloudformation or if you want to go with the default configuration deploying a lambda and hooking it to an API Gateway endpoint is super easy. AWS will create the endpoint for you and will create dev and prod stages, policies, IAM roles, etc. This being deployed by Cloudformation directly from Visual Studio causes the whole deployment and all related objects to fall under the same "Stack" in AWS Cloudformation which can be changed, repliocated, or deleted very easily. Also your Infrastructure is now code and changes to it are auditable in your git repo.

Cons: The biggest con in my opinion is the fact that the stack doesn't span the VS Solution but rather just the project, so all your lambdas have to live in the same project which means that if you have a lot they will end up all in one monolith lambda binary. The generated large project binary will costing you memory runtime on AWS and efficiency problems. The other con is that if you want to have specific or out of the ordinary API Gateway you will need to understand Cloudformation syntax to change your serverless.template file.

Conclusion: My preferred solution was to divide my true application into smaller chunks of related lambdas based on the API object and place these lambdas in a few Serverless application projects. For example I have an order project which contains all lambdas related to the order API, and a Product project that contains the lambdas related to product API etc. Both of them would live in the same solution and would get deployed separately. I'm currently working on a way to deploy the entire solution at once.

这篇关于AWS Lambda-使用.NET Core构建无服务器API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！