Serverless是一种构建和管理基于微服务架构的完整流程，其中应用开发不使用常规的服务进程，仅依赖于第三方服务（如AWS Lambda服务）、客户端逻辑和服务托管远程过程调用的组合，可以帮助开发者更快速地开发软件。Serverless意味无维护，有了Serverless，我们几乎无需DevOps了。本文作者讲述了他学习Serverless，尝试托管API的经历。

最近，我想更改CardGames.io上的API，同时尝试一下Serverless框架。因为在过去的几年中，Serverless一直是技术界的热门话题，而我喜欢靠尝新来保持自己的技术水平不过时，所以我决定花几个小时来学习Serverless，看看用它来托管我们的API是否可行。

原有设置

CardGames.io托管在AWS上。我们使用S3来存储HTML页面、CSS、JavaScript和图像。我们有一个使用C#编写的API，该API托管在Elastic Beanstalk上，使用运行 .NET Core和Docker的Linux服务器。最后，我们在S3的静态文件和API上都部署了CloudFront CDN。

下图是我们今年8月的EC2账单。我们还有其他一些实例，但对于API，我们使用m1.small实例（是的，我们可能应该使用t2.small）和经典负载平衡。把图中红框部分加起来可以得出该月的费用为164.21美元，我甚至包括了整个EBS的部分，主要是因为我不确定它的哪一部分属于我们运行的其他EC2内容。

Elastic Beanstalk的AWS账单

我们有两个环境，每个环境都有1-3个实例，一个处于活动状态，剩下的则是非活动状态。之所以有两个环境，是因为在AWS的Docker中部署 .NET Core需要几分钟，因此我们部署到非活动环境，然后切换CNAME记录以切换到新部署的环境。部署缓慢是我想尝试新事物的原因之一。我们还有其他一些服务器在Beanstalk上运行node.js应用程序，这些服务器可以在几秒钟内部署，我也希望将其用于我们的API。

走向Serverless

我浏览了一个关于使用Serverless框架托管ASP .NET Web API的优秀教程。我发现，只需在现有的API项目中添加一个简单的配置文件、一个依赖项和一个小小的启动类即可。然后我就部署了，大概花了20秒，比部署到Beanstalk快得多。我猜这是因为Lambda内置了对 .NET Core的支持（尽管只有2.2版本），而在Beanstalk中，仅当你使用Docker并自行管理时才能支持。不管怎样，到目前为止我还是很高兴，还没有考虑自动扩展组、最大实例数之类的东西。

测试性能

AWS上的Serverless是Lambda，它实际是函数的宿主，而API网关是一个前端，它允许用户添加速率限制和API密钥等内容。我在us-west-2区域设置了Lambda函数，该区域就是我们托管Beanstalk服务器的那一个。然后，我设置CloudFront实例，将一个游戏的请求路由到新的Serverless设置，同时将另一个游戏路由到旧的Beanstalk设置。后来，我对两个URL（Serverless和Beanstalk）进行了简单测试。两个网址在我们的API中指向了完全相同的代码，将一个事件保存到数据库中。我为每次测试运行了100个请求，结果是：

性能对比

我发现，Serverless设置的速度始终慢15％（如果你认为总体运行速度也很慢，那是因为我是在冰岛运行的，可能会有些延迟）。这个结果令人失望，但也足够快了。我知道在API之前运行API网关会有一些开销，它提供了很多东西，有些我们可能用不上，所以结果虽然令人失望，但还不算糟糕！

价格

老实说，我之前根本没有考虑过价格。我觉得“为你所用的内容付费”听起来比为24/7运行的实例付费要便宜，因此我让新的Serverless设置运行了几天，然后检查我的账单。天啊！Lambda+API网关账单已经超过了一百美元！我先鼓捣了一通Lambda设置，减少了lambda函数使用的内存以减少费用。当我真正开始研究到底发生了什么事时才发现，罪魁祸首明显是API网关。以下是它的费用：

API网关定价

我们的API每天接受大约一千万个请求。光是API网关，每天就要花费大约35美元。除此之外，Lambda每天要花费大约10美元，尽管可以通过减少内存使用来降低一些。二者合计约为每天45美元，也就是每月1350美元，而Elastic Beanstalk大约是每月164美元，高出整整8倍！我喜欢新技术，入门也很快，但我不会为它每月额外支付约1200美元。所以，回到Beanstalk！

结论

好吧，我应该先好好看看AWS定价并做出一些计算，再考虑更改。但这样的话，我就只好去干正经事，而没法学到宝贵的技能了！我知道在某些情况下，API网关和Lambda优于Elastic Beanstalk，但我想我们的情况不在其中。也许你使用的是API密钥和速率限制之类由API网关提供的内容，那么就有必要为每一百万个请求支付3.5美元。对我们来说，只要可以在Lambda前面放一个普通的负载平衡器就更好了。据我所知，API网关对Lambda的http访问是必需的。

即使我们只为Lambda付费，以每天10美元的价格，我们每月仍需支付300美元，而不是164美元。我们有很多请求，但每个请求的内容很少，基本是一个数据库调用。以下是一个请求的报告，你可以看到我们的计算时间只有3.5毫秒，而要为100毫秒计费似乎是一个很大的浪费。

一个请求的Lambda报告

最后，我并不打算抨击API网关、Lambda或Serverless，只是想说明对于某些工作负载，它们比无聊的旧EC2和Elastic Beanstalk要昂贵得多。这就是我们坚持老路子的原因🙂。或许也有更好或更有效的设置方式，如果你看出了一些明显的错误，请务必在评论中指出来。

2019.9.26更新：这篇文章在3天内获得了超过10万的浏览量，并成为了Hacker News和reddit.com/r/programming的头条。我的确学到了一些东西。我应该在Lambda之前使用应用程序负载均衡器而非API网关；我应该将古老的m1.small实例升级为新的实例类型；使用运行时 .NET Core docker镜像而非SDK镜像；我能够将Beanstalk的部署时间降低到合理的30—40秒。

虽然，Serverless仍不适合我的用例，但这绝对是一次有趣的实验！

原文链接：
https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/

创作场景

Serverless：慢 15%，贵 8 倍？