在过去的几年中，无服务器一直是科技界的热门话题。我想通过尝试一些新方法来保持我的技术水平最新，所以我决定花几个小时来学习无服务器，并看看以这种方式托管我们的API是否有意义。
我学习了关于使用Serverless框架托管ASP.NET Web API 的非常不错的教程，发现我只需要向我现有的API项目中添加一个简单的配置文件，添加一个依赖项和一个小的启动类。然后我部署了它，大概花了20秒钟左右，比部署到Beanstalk好得多。我猜这是因为Lambda内置了对.NET Core的支持（尽管只有2.2），而在Beanstalk中，仅当您使用Docker并自行管理时才支持。无论如何，到目前为止，我还是很高兴，没有考虑自动缩放组，最大实例数或任何其他东西。
测试性能
在AWS上无服务器的是Lambda（它实际上是函数的宿主）和API Gateway（它是使您添加速率限制，API密钥等内容）的前端。我在us-west-2区域设置了Lambda函数，该区域与托管Beanstalk服务器的区域相同。然后，我将CloudFront实例设置为将对一个游戏的请求路由到我们的新的无服务器设置，以及将另一个游戏的请求路由到我们的旧Beanstalk设置。然后，我对两个URL（一个无服务器，一个Beanstalk）进行了简单测试。两个网址都在我们的API中命中了完全相同的代码，从而将一个事件保存到数据库中。我为每个请求运行了100个请求。
我始终发现，无服务器设置的速度要慢15％。（此外，如果您认为总体运行速度很慢，那么我是从冰岛运行的，因此会有一些延迟）。令人失望，但是它仍然足够快，我只是想知道在API之前运行API Gateway会有一些开销，即使我们不使用它们，它也提供了很多东西。
价钱
老实说，我之前根本没有考虑过定价。我只是觉得“为您所用的内容付费”听起来比为24/7上的实例付费要便宜。因此，我让新的无服务器设置运行了几天，然后开始检查我的账单。哎呦！Lambda + API网关账单已经超过一百美元！我首先开始搞乱Lambda设置，为lambda函数提供更少的内存以减少费用，但是当我真正查看正在发生的事情时，很明显，主要是API网关费用高。
我们的API每天接受大约一千万个请求。仅用于API Gateway每天大约35美元。最重要的是，Lambda每天的费用约为10美元，尽管可以通过使用更少的内存来减少。两者合计约为每天45 $，或每月1350 $，而Elastic Beanstalk 约为每月164 $。这是8倍更贵！我喜欢新技术，并且可以快速部署，但是我不会每月额外支付约1200美元。
结论
我确定在某些情况下，API Gateway和Lambda优于Elastic Beanstalk。我想我们的用例不是其中之一。也许如果您使用的是API密钥，速率限制和API Gateway提供的其他内容，则有必要为一百万个请求支付3.50美元。对我们来说，如果我们可以在Lambda前面放一个普通的负载平衡器，那就更好了。据我所知，API网关对于HTTP访问Lambda是必需的。
最后，在这里我一般不打算抨击API Gateway，Lambda或无服务器，只是表明对于某些工作负载，它们比无聊的旧EC2和Elastic Beanstalk昂贵得多。
来自HM的讨论和优化建议：
PSA：将现有的应用程序一对一地移植到无服务器几乎无法按预期进行。建议优化几点：
1.不要使用.NET，它的启动时间很糟糕。Lambda全部涉及零成本的水平缩放，但是如果您的运行时需要100毫秒以上的时间进行初始化，那将不起作用。性能敏感功能的唯一有效选项是JS，Python和Go。
2.尽可能使用托管服务。您永远不要在Lambda中处理登录事件，这是Cognito的。
3.考虑事件而不是REST操作。考虑哪些事件必须击中您的API，什么可以由托管服务直接处理或由您在边缘处理。例如。永远不要通过Lamdba函数上传图像，而是通过签名的URL直接将其上传到S3，然后让S3发出更改事件以触发下游处理。
4.使用GraphQL汇集来自前端的API请求。
5.对于高吞吐量的API，Websocket便宜。
6.广泛使用缓存。可以从缓存处理的请求永远不会到达Lambda。
7.始终考虑节省劳动力，尤其是人员。