干货 | 详解 Serverless 服务，它会颠覆你对云的理解（附视频）

业界认为，Serverless 代表了新的软件设计范式，可能也颠覆了我们一般对云的理解。本次硬创公开课，雷锋网就邀请到了 Strikingly 创始团队成员及首席架构师龚凌晖，来讲讲 Serverless 服务到底是什么，它的发展状况又是怎么样的。

Strikingly 是自助式建站平台，提供模版、设计资源、编辑器等，可以在短时间内容搭建自己的网站，提供托管服务。它是第一家从 YC 孵化的国内初创公司，主要帮助不懂技术但又有建站需求的用户服务。

龚凌晖，Strikingly 创始团队成员，第一个工程师。毕业于复旦大学计算机学院，在加入 Strikingly 之前，曾在 Morgan Stanley 的 Enterprise Infrastructure 部门任职。2013 年加入 Strikingly 之后，做过产品，搞过运维自动化，研究过 Web Analytics 和 SEO，玩过数据分析，目前在团队中负责后端开发，系统运维以及数据分析等部门的项目研发和团队管理。

以下是雷锋网整理的公开课主要内容，更完整内容可观看上面雷锋网公开课的视频：

我们从 2014 年开始使用 AWS。2014 年，亚马逊发布了 Serverless 服务，当时它还是一个颠覆性的想法，少有人使用。我们也是在去年初才把 Serverless 引入到系统中。

那么什么是 Serverless 服务呢？

早期的互联网应用依赖传统 IDC 做系统架构，要有专业的运维人员管理计算资源，还要对系统负载做严格的评估和预测，这样才有时间购买新服务器。后来虚拟化技术提高了灵活性，计算资源拥有者可以把资源打包，按使用时间计费，这也就诞生了 IaaS 服务。

IaaS 对系统的可拓展性和成本控制都有很大作用，但对刚起步的公司来讲，虚拟化仍不够，所以云平台在虚拟化的基础上作了进一步抽象，让开发者只关注应用逻辑，而不用管服务器配置和应用部署，这也就是 PaaS。

不过虽然简化了系统的复杂性和开发应用的迭代速度，PaaS 依然要调整计算资源的数量来适应系统变化，那如果计算资源可随系统的变化自动伸缩呢？这也就是 Serverless 诞生的原因。

Serverless 不是没有服务器，它与传统去计算服务形态的区别主要包括：

更细粒度的计算资源分配；

基本无需预先计划计算资源；

高度弹性可扩展；

按需使用，按使用量付费。

不过这些可能也是云计算的特别，而真正的区别就像上图中的比喻，从自行打井水到筒装水再到按需随时使用的自来水，Serverless 就像是水龙头，它把服务的灵活性做到了极致，本质是最细粒度的云平台服务形态。

在业界的现状

最前沿的 Serverless 厂商无疑是亚马逊 AWS，它从 2006 年开始提供云计算服务，这种领先也一直延续。微软 Azure 与阿里云也相继推出 Serverless 服务。

为什么 AWS 要开发 Serverless？其实用户对云的方便与灵活有越来越高的要求，所以 Serverless 是一个必定出现的趋势，即使不是 AWS，其它厂商也会提出来。下图是 AWS Serverless 服务发布的时间表。

可能其中最出名的是 Lambda，但 Serverless 包括了方方面面，比如 S3 就是一个很典型的 Serverless 服务，按照存储的数据量和访问量收费。

有一个值得关注的点是，2014 年 AWS 发布了 Lambda，但 Serverless 是在近两年后才逐渐引起关注。这是因为 2014 年容器技术才刚成为关注点，而 Serverless 太过于前卫，所有的云厂商都没想明白怎么样去发展它，而且生态也不成熟，在落实到工程中仍有很多问题。

AWS 用了一年多时间推动 Serverless，同时相关的工具也得到了发展，让部分用户尝到了甜头，这也引起了其它厂商的跟进，纷纷在 2016 年推出服务。其它厂商追赶的时候，AWS 也把 Lambda 拓展到了其它服务，比如物联网和海量数据运输。

Google 云平台在 2008 年发布 App Engine 就进入云服务，目前它的 Serverless 服务 Cloud Functions 还处于试用阶段。微软 Azure 云与阿里云也在 2016 年发布了 Azure Functions 和 Function Compute，都是试用。

Serverless 长什么样？

接下来介绍几个典型的 Serverless 服务，以及如何构建实用的解决方案。

下图把 AWS 的服务分成三类。一是基于 EC2 直接构建服务。第二类是托管服务，不需要对底层的虚拟机进行管理，只需配置资源大小，它会自动分配资源。托管服务在各云厂商之间的差异较大，也是竞争所在。第三类是 Serverless 服务，完全由 AWS 托管，甚至不用预先分配计算资源，也不用考虑实现弹性伸缩，只需要用就可以了。

有代表性的 Serverless 服务有下列一些。

一是 Lambda

这是基于事件驱动的 Serverless 服务。它一不需要管理服务器和抽象的计算资源；二由事件驱动，可自动扩展计算能力；三是实现成本控制，按使用量收，计时可精确到 4 秒。

如何用 Lambda 呢？一是把现有的代码包装成 Lambda 函数；二是选择计算单元的大小，AWS 提供了单一唯独的指标，只需要选择运行时所需要的内存大小，就可自动适配 GPU，I/O 等；三是代码打包上传到 AWS；四是指定事件触发方式，如来自 API 的请求和 SNS 的消息，它有与其它服务交互的能力。

Lambda 使用中要注意的是：

它是一个无状态的计算模型，因此要避免运行过程中安装代码依赖；

二是它的实现机制有一个流量预测算法，但它无法在没有流量的情况下进行预测，因此在一段时间没有执行后，再启动时会有延时，因此要视情况避免冷启动；

三是内置了版本和别名机制，需要合理利用；

四是正确编译平台相关代码。

DynamoDB

它是 AWS 内部分布式 NoSQL 数据库服务。它的主要特性如下：由 AWS 完全托管，不需要任何设置就可以获得快速稳定的读写性，存储空间也会随着数据量增长而增长。它也支持 Lambda，这样同时支持精细到每一项数据的访问控制。

Aurora

它是 AWS 兼容第三方接口的关系型数据库服务，目前还在预览阶段。它的出现是因为，传统数据库解决方案不是为云平台设计的，需要用云的思维重新定义。

AWS 引入了 SOA 理念，重新打造数据库引擎，把传统数据组件分解成一个个的独立模块，再通过自己云平台中已经有的服务来实现这些服务模块。这使得用户不用担心数据库升级，容量扩展这些令人头疼的问题。

如上图，整个数据库服务被分成数据层和控制层，控制层由 DynamoDB 来存储元数据，Route 53 提供服务发现，SWF 负责 SOA 中的工作协调。数据层则使用了可靠性强的 S3 来实现数据的高可用存储。

AWS 通过共享存储也实现了读写分离和高可用性，可以满足大部分用户对数据库的要求。Aurora 的价格几乎接近开源数据库的价格，只是约高端商业数据库价格的十分之一。

下图是 Aurora（蓝色）与 MySQL（绿与红）数据库在读写上的性能对比。

总体来说，从经济成本，管理成本和实际效用上，都超越了传统数据库。

Serverless 设计模式

经典 3 层 web 应用

典型的 web 应用通常分为动态与静态资源。在设计中，可以用 S3 作为静态资源的存储，同时用 CloudFront 的 CDN 加速服务。动态这一块 DynamoDB 作为网站数据存储，通过 API Gateway 和 Lambda 实现前端的静态页面调度。整个架构中都用的是 Serverless 服务。

还可以设计更复杂的架构，如下图：

静态部分还是 S3 与 CloudFront，但加入了高级功能。动态部分加入 IAM 支持，同时在 API Gateway 这一层加入流量控制，认证等。 还可以加入防火墙服务 WAF。

不过 Serverless 架构中的组件过多，如果 API 有数十甚至上百个节点，Lambda 函数也会这么多，手动管理会十分不方便。因此亚马逊也推出了相应的方案 SAM。如下图：

AWS CloudFormation 是亚马逊专门用来配置和管理计算资源的服务，SAM 是它的一个子集，可以用它打包整个架构设计，自动把所有东西同时打包配置好，做到自动化。

数据批处理

很多数据批处理的逻辑都可以分解成 Map-Reduce 的合理操作。但亚马逊 Lambda 提供的思路是，把原始数据存在云端，然后定义 filter（把输入的数据分配到多个 maper 上），maper（执行映射逻辑，并把映射结果存在 DynamoDB），reducer（处理映射逻辑，把最终结果存在 S3 上）三个 lambda 函数。由于 S3 和 DynamoDB 的事件都能触发 Lambda 函数执行，整个过程可以完全自动完成并自动伸缩。另由于起点和终点都是 S3，所以可以把多个 Map-Reduce 逻辑串联，构成更复杂的处理模型。

数据流式处理

Kinesis 是亚马逊处理流数据的品牌。下图是简化版且 S3 和 Lambda 数据流两步归集的处理系统。

第一步要用 Lambda 实现初步处理器 Stream Processor，它处理流数据后会把结果保存在 S3 上。第二是用 CloudWatch 定时器功能周期性触发 Lambda 函数，把中间结果进一步处理，把最终结果存在 S3 上。为了提高效率，第二步中的 Lambda 是一个任务分配器，可以同时触发多个具体处理数据的 Lambda 函数，同时对多个 S3 中的中间结果对象做处理。

这里有一个隐患，它来自 Lambda 和 Kinesis 集成方案的技术性区别。两者对接时，前者的并行能力会受到后者并行能力的限制。同时运行的 Stream Processor 的数量不能超过 Kinesis 的数据流分配的数据，这会导致数据流的推积。

解决方法是，如果瓶颈在于对接 Kinesis 的 Lambda 函数， 那可以缩短函数的执行时间。具体而言，Lambda 函数不负责具体的数据处理，而是应该把它给更多 Lambda 并行处理。由于从 Lambda 函数触发其它 Lambda 函数没有并行限制，那可以做到即时处理 Kinesis 过来的数据。

Serverless 的优势与劣势

前文已经提及它的优势，现在再来谈谈它的问题与挑战。总的来说，一些传统开发的技术和经验不适用。

首先是服务细粒度增加了开发大型应用的难度。传统 web 应用可以管理成百上千的 API，但在 Serverless 中需要开发者有足够的管理能力进来应对。

其次是 Serverless 只能选用云厂商支持的特定的技术栈，对代码的行为有一定限制。

建立本地开发环境较为困难，调试不便。现在有人在本地用 Docker 模拟运行环境，这值得一试，但无法完全接近生产环境。

应用安全模型不够成熟，如何实现加密、认证、权限管理都需要时间来检验。

Serverless 的意义

对开发工程师来说，Serverless 是一个新的职业发展机遇。它不会完全替代现有的传统开发与部署模式，但一定会在某些领域大放异彩。它也降低了开发高并发应用的门槛，能为应用实现高可扩展与高可用性。

对运维工程师来说，可以更清楚认识到在云计算时代系统运维这个职业的危机。云计算的一个发展趋势是，云厂商把自己在架构和运维实践上的经验产品化，提供给用户，而它们的共有特征是对运维的依赖越来越小，开发工程师可以独立完成系统部署。

不过这个职业的发展方向是兼顾开发，做运维自动化。Serverless 也给希望向自动化运维方向转型的工程师提供了职业发展机遇，可以利用 Serverless 新的运维逻辑，完成运维自动化。

对 CTO 和架构师来说，Serverless 可以帮助理解全新的架构设计思路， 把系统架构中一部分用 Serverless 实现，提供开发和运维效率，用低成本实现可扩展性和可用性。

对 CEO 与产品经理来说，理解 Serverless 有助于判断某个产品特性是否适合这一服务进行快速实现。

对于学生来说，学习更新的知识总没错，学习 Serverless 可以帮助理解新的软件设计范式，为自己的职业发展做准备

可以说，Serverless 代表了全新的软件设计范式，需要用新的思路来看待云计算，它已经颠覆了对云的理解。