花了1000G，终于弄清楚了Serverless （中）：Serverless 架构的优缺点

Serverless 的优点

在我使用 Serverless Framework 开发 AWS Serverless 应用的过程当中，最方便的莫过于，第一次部署和第二次、第三次部署没有什么区别。只须要执行 serverless deploy，几分钟后，咱们代码就运行在线上。若是是一个传统的 AWS 应用，我须要 SSH 到个人服务器上部署，这样才能写好个人自动部署脚本。除此，我还须要担心这个过程当中，有哪些用户有使用。

除了，我以为的部署方便，还有就是价格合理。个人 AWS EC2 实例上运行着个人博客、以及其余的一些网络。然而，我那 PV 只有 500 左右的博客，大部分时间都是在空转。便以为有些浪费，但是运行才收费的 Serverless 就不会有这样的问题。可让我大胆地去使用这些服务。固然了，还有其它一些显著的优点。

下降启动成本

当咱们做为一家公司开发一个 Web 应用时，在开发的时候，咱们须要版本管理服务器、持续集成服务器、测试服务器、应用版本管理仓库等做为基础的服务。线上运行的时候，为了应对大量的请求，咱们须要一个好的数据库服务器。当咱们的应用面向了普通的用户时，咱们须要：

• 邮件服务，用于发送提醒、注册等服务
• 短信服务（依国家实名规定），用于注册、登陆等用户受权操做

对于大公司而言，这些都是现成的基础设施。可对于新创企业来讲，这都是一些启动成本。

减小运营成本

对于初创公司来讲，他们没有基础设施，也没有财力，也可能没有能力去建设基础设施。采用云服务每每是最好的选择，能够节省大量的资金。他们能够将注意力放在：创造对用户有价值的产品上。若是一家创业公司采用云服务，而不是本身搭建服务器。那么，他就会拥有更多的时间开发业务功能，而不是关注在这些。只须要为运行时的软件付钱。

而采用函数计算的 Serverless 与云服务器最大的不一样之处在于：云服务器须要一直运行，而函数计算是按需计算。按需计算就意味着，在请求到来的时候，才运行函数。没有请求的时候，是不算钱的。

项目初期，其用户数每每是缓慢增加的，而咱们在选择服务器的时候，每每会依可能出现的用户来估算。在这个时候，每每会浪费一些没必要要的成本。不过，就算用户忽然间爆发，Serverless 应用也能够轻松处理。只须要修改一下数据库配置，再从新部署一份。

下降开发成本

一个成功的 Serverless 服务供应商，应该能提供一系列的配套服务。这意味着，你只须要在配置文件上写下，这个数据库的表名，那么咱们的数据就会存储到对应的数据库里。甚至于，**若是一个当服务提供者提供一系列的函数计算模板，那么咱们只须要写好咱们的配置便可。这一系列的东西均可以自动、高效的完成。

在这种状况下，使用某一个云服务，就会调用某一个系统自带的 API 同样简单。

固然，将应用设计成无状态应用，对于早期的系统，多是一种挑战。除此，诸如 AWS 这样庞大的系统，对于新手程序员来讲，也不能容易消化掉的一个系统。

实现快速上线

对于一个 Web 项目来讲，启动一个项目须要一系列的 hello, world。当咱们在本地搭建环境的时候，是一个 hello, world，当咱们将程序部署到开发环境时，也是一个部署相关的 hello, world。虽然看上去有些不一样，可是总的来讲，都是 it works!。

Serverless 在部署上的优点，使得你能够轻松地实现上线。

更快的部署流水线

实际上，Serverless 应用之因此在部署上有优点，是由于其至关于内建自动化部署——咱们在开发应用的时候，已经在不断地加强部署功能。

在咱们平常的开发中，为了实现自动化部署，咱们须要先手动部署，以设计出一个相关无错的部署配置，如 Docker 的 Dockerfile，又或者是 Ansible 的 playbook。除此，咱们还须要设计好蓝绿发布等等的功能。

而在函数计算、Serverless 应用里，这些都是由供应商提供的功能。每次咱们写完代码，只须要运行一下：sls deploy 就足够了。在诸如 AWS Lambda 的函数计算里，函数通常在上传后几秒钟内，就能作好调用准备。

这就意味着，当咱们和平常同样，使用一个模板来开发咱们的应用。咱们就能够在 Clone 完代码后的几分钟内，完成第一次部署。

惟一的难点，多是要选用什么配置类型的服务，如选用哪一个级别吞吐量的 DynamoDB、哪一个内存大小的 Lambda 计算。

更快的开发速度

因为 Serverless 服务提供者，已经准备好了一系列的基础服务。做为开发人员的咱们，只须要关注于如何更好去实现业务，而非技术上的一些限制。

服务提供者已经向咱们准备，并测试好了这一系列的服务。它们基本上是稳定、可靠的，不会赶上特别大的问题。事实上，当咱们拥有足够强大的代码，如使用测试来保证健壮性，那么结合持续集成，咱们就能够在 PUSH 代码的时候，直接部署到生产环境。固然，可能不须要这么麻烦，咱们只须要添加一个 predeploy 的 hook，在这个 hook 里作一些自动测试的工做，就能够在本地直接发布新的版本。

这个过程里，咱们并不须要考虑太多的发布事宜。

系统安全性更高

依我维护我博客的经验来看，要保持服务器一直运行不是一件容易的事。在不经意的时候，总会发现有 Cracker 在攻击你网站。咱们须要防范不一样类型的攻击，如在个人服务器里一直有黑客在尝试密码登陆，但是个人博客的服务器是要密钥才能登陆的。在一次神奇的尝试登陆攻击后，个人 SSH 守护进程崩溃了。这意味着，我只能从 EC2 后台重启服务器。

有了 Serverless，我再也不须要担忧有人尝试登陆系统，由于我都不知道怎么登陆服务器。

我再也不须要考虑系统底层安全问题，每次登陆 AWS EC2，我总须要更新一遍软件；每当我看到某个软件有漏洞时，如以前的 OpenSSH，我就登陆上去看一下版本，更新一下软件。真 TM 费时又费力，尚未一点好处。

惟一须要担忧的，多是有人发起 DDOS 攻击。而根据Could Zombie Toasters DDoS My Serverless Deployment?的计算，每百万的请求，大概是 0.2 刀，每小时 360000000 个请求，也就 72 刀。

适应微服务架构

如咱们所见在最近几年里看到的那样，微服务并不没有大量地替换掉单体应用——毕竟使用新的架构来替换旧的系统，在业务上的价值并不大。所以，对于不少企业来讲，并无这样的强烈需求及紧迫性。活着，才是一件更紧迫的事。

而 Serverless 天生就与微服务架构是相辅相成的。一个 Serverless 应用拥有本身的网关、数据库、接口，你可还以使用本身喜欢的语言（受限于服务提供者）来开发服务。换句话来讲，在这种情形下，一个 Serverless 多是一个完美的微服务实例。

在可见的一二年里，Serverless 将替换到某些系统中的一些组件、服务。

自动扩展能力

Serverless 的背后是 诸如 AWS Lambda 这样的 FaaS（Function as a Services）。

对于传统应用来讲，要应对更多的请求的方式，就是部署更多的实例。然而，这个时候每每已经来不及了。而对于 FaaS 来讲，咱们并不须要这么作，FaaS 会自动的扩展。它能够在须要时尽量多地启动实例副本，而不会发生冗长的部署和配置延迟。

这依赖于咱们的服务是无状态的，咱们才能次无忌惮地不断运行起新的实例。

Serverless 的问题

做为一个运行时，才启动的应用来讲，Serverless 也存在着一个个咱们所须要的问题。

不适合长时间运行应用

Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，应用将会须要一个启动时间，即冷启动。这个时候，能够结合 CRON 的方式或者 CloudWatch 来按期唤醒应用。

若是你的应用须要一直长期不间断的运行、处理大量的请求，那么你可能就不适合采用 Serverless 架构。在这种状况下，采用 EC2 这样的云服务器每每是一种更好的选择。由于 EC2 从价格上来讲，更加便宜。

引用 Lu Zou 在 《花了 1000G，我终于弄清楚了 Serverless 是什么（上）：什么是 Serverless 架构？》上的评论：

EC2 至关于你买了一辆车，而 Lambda 至关于你租了你一辆车。

长期租车的成本确定比买车贵，可是你就少掉了一部分的维护成本。所以，这个问题其实是一个值得深刻计算的问题。

彻底依赖于第三方服务

是的，当你决定使用某个云服务的时候，也就意味着你可能走了一条不归路。在这种状况下，只能将不重要的 API 放在 Serverless 上。

当你已经有大量的基础设施的时候，Serverless 对于你来讲，并非一个好东西。当咱们采用 Serverless 架构的时候，咱们就和特别的服务供应商绑定了。咱们使用了 AWS 家的服务，那么咱们再将服务迁到 Google Cloud 上就没有那么容易了。

咱们须要修改一下系列的底层代码，能采起的应对方案，即是创建隔离层。这意味着，在设计应用的时候，就须要：

• 隔离 API 网关
• 隔离数据库层，考虑到市面上尚未成熟的 ORM 工具，让你即支持 Firebase，又支持 DynamoDB
• 等等

这些也将带给咱们一些额外的成本，可能带来的问题会比解决的问题多。

冷启动时间

如上所说，Serverless 应用存在一个冷启动时间的问题。

据 New Relic 官方博客《Understanding AWS Lambda Performance—How Much Do Cold Starts Really Matter?》称，AWS Lambda 的冷启动时间。

AWS 启动时间

又或者是我以前统计的请求响应时间：

Serverless 请求时间

尽管这个冷启动时间大部分状况下，能够在 50ms 之内。而这是对于 Node.js 应用来讲，对于拥有虚拟机的 Java 和 C# 可能就没有那么幸运了。

缺少调试和开发工具

当我使用 Serverless Framework 的时候，遇到了这样的问题：缺少调试和开发工具。后来，我发现了 serverless-offline、dynamodb-local 等一系列插件以后，问题有一些改善。

然而，对于日志系统来讲，这仍然是一个艰巨的挑战。

每次你调试的时候，你须要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器。而后 Fuck 了，我并不能老是快速地定位出问题在哪。因而，我修改了一下代码，添加了一行 console.log，而后又一次地部署了下代码。问题解决了，挺好的，我删了一下 console.log，而后又一次地部署了下代码。

后来，我学乖了，找了一个相似于 log4j 这样的能够分级别纪录日志的 Node.js 库 winston。它能够支持 error、warn、info、verbose、debug、silly 六个不一样级别的日志。

构建复杂

Serverless 很便宜，可是这并不意味着它很简单。

早先，在知道 AWS Lambda 以后，我原本想进行一些尝试。可是 CloudForamtion 让我以为太难了，它的配置是如此的复杂，而且难以阅读及编写（JSON 格式）。

考虑到 CloudForamtion 的复杂度，我是在接触了 Serverless Framework 以后，才从新燃起了一些信心。

Serverless Framework 的配置更加简单，采用的是 YAML 格式。在部署的时候，Serverless Framework 会根据咱们的配置生成 CloudForamtion 配置。

在那篇《Kinesis Firehose 持久化数据到 S3》想着的数据统计文章里，咱们介绍了 Serverless 框架的配置。与通常的 Lambda 配置来讲，这里的配置就稍微复杂一些。然而，这也并不是是一个真正用于生产的配置。个人意思是，真实的应用场景远远比这复杂。

语言版本落后

在 Node.js 6 出来的时候，AWS Lambda 只支持 Node.js 4.3.2；在 Node.js 9.0 出来的时候，AWS Lambda 支持到 6.10.3。

以下是 AWS Lambda 支持如下运行时版本：

• Node.js – v4.3.2 和 6.10.3
• Java - Java 8
• Python – Python 3.6 和 2.7
• .NET 内核 – .NET 内核 1.0.1 (C#)

对于 Java 和 Python 来讲，他们的版本上可能基本都是够用的，我不知道 C# 怎么样。可是 Node.js 的版本显然是有点老旧的，可是都 Node.js 9.2.0 了。不过，话说来讲，这可能与版本帝 Chrome 带来的前端版本潮有一点关系。

节选自《Serverless 架构应用开发指南 》