最近，我想更改 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 内容。
我们有两个环境，每个环境都有 1-3 个实例，一个处于活动状态，剩下的则是非活动状态。之所以有两个环境，是因为在 AWS 的 Docker 中部署 .NET Core 需要几分钟，因此我们部署到非活动环境，然后切换 CNAME 记录以切换到新部署的环境。部署缓慢是我想尝试新事物的原因之一。我们还有其他一些服务器在 Beanstalk 上运行 node.js 应用程序，这些服务器可以在几秒钟内部署，我也希望将其用于我们的 API。
我浏览了一个关于使用 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 网关，每天就要花费大约 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 毫秒计费似乎是一个很大的浪费。
最后，我并不打算抨击 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/
活动推荐
10月17日 09:00-12:15 坐标上海·万豪酒店， QCon全球软件开发大会「免费」高效运维实践专场将介绍二进制包 DevSecOps 解决持续交付中的痛点，探讨基于事件和知识图谱技术的 AIOps 运维实践，以及如何运用科技手段驱动团队高质、高效完成产品。
点击「阅读原文」或者扫描图片二维码即可抢占与行业技术专家近距离接触的机会。
1253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
