Serverless和微服务(容器化)架构有什么区别？

在运营一个持续集成(CI)公司多年后，你会发现架构决策中的许多隐藏成本。在本文，我想谈谈 Serverless 和它的主要替代方案——微服务(容器化)架构，它们之间的实际区别。

1架构介绍：Serverless 和容器 +CDN

我们在过去几年看到的新产品中的绝大多数后端架构都属于这两者之一。

Serverless

Serverless核心思想是指定一个策略来创建新的 Web 服务器，而不是自己启动它们。这样一来，如果你的产品在某个地方出彩，获得巨大的流量爆发，你的云提供商可以启动许多 Web 服务器副本，然后在流量减少时关闭这些 Web 服务器。

serverless 通常与其 AWS 商标名 Lambda 互用

当然，serverless 最终还是会使用 Web 服务器。关键是你不必自己去创建这些服务器。你所要做的只是指定构建它们的方法，然后你的云提供商会随着并发请求数量的增加或减少来创建 Web 服务器的副本。即使对于用户很少的小项目，你也可以通过在夜间没有人访问你的网站时关闭 Web 服务器来节省资金。

容器 + CDN

你可以将托管网站的计算成本最高的部分包给其他人，而非指定一个方法来创建 Web 服务器。这就是 CDN 的思路。当一个 Web 服务器的运行速度变慢，通常是由数百个请求要获取相同的不怎么变的资源。CDN 会为你负责这些常见的请求，例如静态图片。

在这种架构中，你的网站用户会从 CDN 请求资源，CDN 将响应大部分(大约 90%)请求。只有那些不能明显缓存的请求会被转发到你的容器。

概述：serverless vs 容器

Serverless“Web 服务器”通常是如何创建真正的 Web 服务器的方法，然后你的云服务商会在一个访问者首次请求某些东西时启动一个 Web 服务器。

容器通常启动速度慢得多，因此你需要保持至少一台 Web 服务器 24/7 运行，以防有人访问你的网站。

2Serverless 理论上看起来更便宜

当 AWS Lambda 在 2014 年推出时，它听起来不可思议：1GB 内存，每毫秒 0.0000000167 美元的计算量。一个典型的 API 请求可能是 20ms，因此你需要为每个请求支付 0.000000334 美元。

由于大多数工作负载都非常“火爆”，因此即使是用 Lambda 托管一个非常流行的服务，你也只需要支付不到 100 美元每年。

相比之下，对大多数产品来说，一个类似的容器 +CDN 架构可能耗费每年 500 美元。

当然，这是一个非常简单的比较(弹性负载均衡、CDN 入口 / 出口、serverless 也可以使用 CDN 等...)，但对于今天的大多数在线产品来说是正确的。在其它同等的情况下，serverless Web 服务器的成本是类似的容器的 10%-20%。

3开发者工资是 serverless 的隐藏成本

基础设施成本是一个很好的指标——很容易预测，是比较一个“好架构”与一个“坏架构”的便捷方法。

然而，基础设施成本与开发人员的工资相比却相形见绌。每年 500 美元的容器会由一名每年 75000 美元的开发者维护。

实际上，人力成本是很多公司低估的。如果你有一个本地无法复现的 bug，开发人员使用一个闭源的 AWS 账户会很难复现和调试它。

三个因素结合在一起让用 serverless 进行开发变得异常困难：

你不能本地模拟 serverless 实例，只能在云上模拟。

很少有公司能创建它们的生产环境的基础设施的副本。开发人员通常会花几个小时来申请合适的环境，并确保没有其他人同时使用这个环境。

开发人员很少能访问生产环境资源，因此它们不得不花费数个小时协调一个编程会话才能在生产环境调试。

世界各地的 slack 工程频道的一个常见场景

如果单个开发人员每周修复一个 bug，并且由于上述因素，修复每个 bug 所需的时间延长一个小时，那么你的公司每年会为单个开发人员的生产力损失支付 1872 美元。这个数字已经是最初成本差异的 4 倍。

相反，一个容器架构可能完全运行在一个开发人员的电脑上，因此每个开发人员都可以在他们自己的笔记本上重现 bug，而不必使用一个演示(staging)环境。

4另一项成本：serverless 会给客户带来更多 bugs

出于与前一点相似的原因，使用一个持续集成 / 持续部署系统自动测试一个 serverless 架构要困难得多。

容器化架构更容易进行测试，因为你可以在单个 VM 中运行它。想要运行持续集成，serverless 架构需要请求你的云服务商为每次更改进行部署。

系统的最终测试是端到端(end-to-end，E2E)测试：通过创建一个假用户，然后像一个真用户一样与整个应用程序进行交互，来验证通用工作流程。如果可以根据需要创建架构副本，这些测试就能针对提出的更改自动运行。

在许多公司中，demo 演示中的一个 bug 可能意味着损失 6-7 位数的销售额。这些 bug 通常是影响不同组件交互的看似无害的更改结果。如果开发人员不在每次更改后测试这些流程是否继续生效，那么就很容易损坏一个“立即支付(pay now)”按钮或者登入。

如果整个堆栈能运行在单个机器上，那么它就可以不怎么麻烦地运行在一个持续集成服务商上。相比之下，一个 serverless 栈可能需要为每个更改在你的云服务商中从头创建整个环境，这会花费 10 倍更长的时间。

5解决方案

显然，对于服务器的解决方案是让供应商采用一个通用标准(AWS kubeless 或 AWS OpenFAAS)。只要 serverless 与闭源云产品同名，那么就会因为开发人员的生产力的损失而大大增加成本。

实际上，最好的解决方案是完全避免使用 AWS Lambda 或 Cloudflare Workers 这样的平台作为核心基础设施，直到能自行托管它们进行问题复现和测试。

对于几乎每一个架构决策，托管成本都比开发者行动缓慢的成本要重要得多。在考虑到需要使用基础设施工作的开发人员的时间成本之前，不要因为价格来进行架构决策。