阿里云产品经理刘宇：Serverless 的前世今生

云布道师

2022 年 9 月 24 日，阿里云用户组（AUG）第 12 期活动在厦门举办。活动现场，阿里云 Serverless 产品经理刘宇，向参会企业代表分享了Serverless 架构的前世今生。本文根据演讲内容整理而成，希望和大家一起探索 Serverless 架构。

从云计算到 Serverless 架构

从云计算到云原生再到 Serverless 架构，技术飞速发展的轨迹都有一定规律可循，那么 Serverless 架构为何而来，因何而生呢？

 云计算的诞生

从世界第一台通用计算机 ENIAC 开始，计算机科学与技术的发展就从未停止过前进的脚步，近些年来，更是日新月异。有不断突破和创新的人工智能领域，有 5G 带来更多机会的物联网领域，还有不断走进寻常百姓家的云计算。

在图中可以看到三个关键词，这是 2003 年到 2006 年间谷歌发表的三篇重要论文，分别指明了 HDFS（分布式文件系统），MapReduce（并行计算）和 Hbase（分布式数据库）的技术基础以及未来机会，正式奠定了云计算的发展方向。关于这三篇论文，或者说三个技术点，也有人曾说，“因为它们，云计算才正式拉开帷幕”。

云计算发展是飞速的，也是有目共睹的；但是随着云计算的进程，另一个名词诞生并迅速占领了“风口大旗”，被大众更为广泛地关注，那就是——云原生。

通过对云计算与云原生的文字组成结构分析，可以看到云原生实际上就是在云与计算之间，加了一个 Native。我们可以这么认为，云计算的飞速发展，无论是从技术迭代还是概念升级，最终产生了如今耳熟能详的：云原生计算。

云计算是什么？其实早在 1961 年云计算的雏形概念就已经诞生了。在麻省理工学院百周年纪念典礼上，约翰·麦卡锡（ 1971 年图灵奖获得者），第一次提出了一个概念，这个概念后来被喻为是云计算的“最初的、超前的”遐想模型。它的翻译大意为：“计算机在未来，将变成一种公共资源，会像生活中的水、电、煤气一样，被每一个人使用。”

时间到了 1996 年，云计算这个词被正式提出。而后再到了 2009 年，UC Berkeley（加利福尼亚大学伯克利分校）在发布的论文中，对云计算进行了较为细致描述。他说云计算是一个即将实现的古老梦想，是计算作为基础设施这一长久以来梦想的新称谓，它正快速变为商业现实。同时，他在论文中明确地为云计算下了定义：云计算包含互联网上的应用服务，以及在数据中心提供这些服务的软硬件设施。

 云原生的火热

时至今日，云原生技术的发展同样迅猛。那么，什么是云原生呢？在阿里云智能基础产品事业部负责人蒋江伟的文章《什么是真正的云原生》中，给出了一个非常明确的解释：因云而生的软件、硬件、架构，就是真正的云原生；因云而生的技术，就是云原生技术。出生于云，成长在云，因云而生，就是云原生。

那么云原生都包括哪些东西呢？耳熟能详的技术，加上云原生三个字，就都是云原生相关技术了，例如：数据库 → 云原生数据库；网络 → 云原生网络等。在 CNCF Landscape 中，可以看到云原生基金会对云原生产品维度的一个描述，包括了数据库、流、消息、容器镜像、servicemesh、网关、K8S 等，当然，还包括一个非常热门的词汇：Serverless。

 Serverless 架构的出现

在很多时候 Serverless 架构被称为是一种粘合剂，它将云原生的其他很多产品和用户的业务进行了链接，同时又提供了极其诱人技术红利，为此也被很多项目、业务所选择。那么，究竟什么是 Serverless 架构？

通过 Serverless 的结构，不难发现其所要传递的心智，Server 指的是服务器，Less 表示的是更少的精力，所以 Serverless 架构所传递的心智是：把更专业的事情交给更专业的人，开发者能够较少地关注服务器等底层相关内容，把更多的精力放在更具价值的业务逻辑之上。

2009 年，UC Berkeley 发表的那篇著名的关于云计算的文章，提出了包括服务的可用性，数据安全性和可审计性等在内的十项云计算所面临的各种困难和挑战，并断言云计算将会引领未来的十年。

2019 年，恰好时隔十年，UC Berkeley 再次发文，从多个角度说明了什么是 Serverless 架构，例如，从结构角度，肯定了 Serverless 是 FaaS 与 BaaS 的结合；从特性角度，对于被认为是 Serverless 架构的产品或者服务需要具备按量付费和弹性伸缩的特点；并非常“激进”地表示 Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，由此也意味着服务器 - 客户端模式的终结。

从 IaaS，到 PaaS，再到 Serverless，云计算的发展，越来越清晰，也越来越明确，去服务器化也越来越明显。

无论此时我们说云原生，还是 Serverless 架构，云的概念确实是在不断地升级，云的技术也在不断地迭代，而这一切的改变其实都是为了效能提升，为了安全提升，为了成本降低，生产力驱动。

什么是 Serverless 架构？

尽管对于 Serverless 架构的定义，并没有一个非常明确的表述，但是 Serverless 是 FaaS 与 BaaS 的组合这种说法，却被很多人所接受。所谓的 FaaS 就是函数即服务，而 BaaS 则指的是后端即服务，两者搭配，共同成为 Serverless 架构不可获取的部分，为开发者提供降本提效的技术红利。

诚然，CNCF 云原生基金会在 Serverless 白皮书中，肯定了 Serverless 是 FaaS 与 BaaS 的结合这种说法；而 UC 伯克利在论文中，肯定这种说法的同时，也从特性角度指出，对于被认为是 Serverless 架构的产品或者服务，还需要具备按量付费和弹性伸缩等特点，但是这也都是 2019 年的“描述”了。

时至今日，Serverless 架构已经完成了“自我更新与迭代”。在信通院发布的 Serverless 的白皮书中，明确指出 Serverless 架构计算平台包括了函数纬度和应用纬度两种形态。而随着时间的发展，阿里云领先性地推出了 Serverless 应用引擎（SAE），以应用为维度进行 Serverless 化的平台，换句话说，它其实可以是应用 Serverless 化的最佳实践。

至此，Serverless 架构的组成已经逐渐明确：

• 从结构角度，Serverless 是计算平台与 BaaS 产品的结合。计算平台包括了事件触发的函数计算，也包括了应用Serverless化的最佳实践 Serverless 应用引擎。BaaS 层面则包括了 Api 网管，CDN，对象存储，数据库等一系列的云服务。

• 从特性角度，就像 UC Berkeley 所说，对于被认为是 Serverless 架构的产品或者服务，还需要具备按量付费和弹性伸缩等特点。

 Serverless 架构和传统架构的区别

作为云时代新的计算范式，Serverless 架构本身属于一种天然的分布式架构，其工作原理较于传统架构虽没有翻天覆地的变化，但也是有细微的不同。

如图所示，传统架构下，开发者开发完成应用之后，还需要购买虚拟机服务，初始运行环境，安装需要的软件（例如 MySQL 等数据库软件，Nginx 等服务器软件等），完成环境的准备之后，还需要上传开发好的业务代码，启动该应用，此时用户才可以通过网络请求，成功的访问到目标应用。

但是，如果应用的请求量过大或者过小，开发者 or 运维人员还需要针对实际的请求数量进行相关资源的扩充或缩容，并在负载均衡&反向代理模块增加相对应的策略，以确保扩缩容操作的及时生效。同时，在做这些操作的时候还要保证线上用户不会受到影响。

而在 Serverless 架构下，整个应用发布的过程和工作的原理，将会发生一定的变化。

当开发者开发完整业务代码之后，只需要部署或更新到对应的 FaaS 平台即可，完成之后根据真实的业务需求，进行相关的触发器配置，例如为了对外提供 Web 应用服务，可以配置 HTTP 触发器等，此时用户就可以通过网络，访问到开发者所发布的应用。

在这个过程中，开发者不需要再额外关注服务器的购买、运维等相关的操作，也无需对一些软件的安装、应用资源的扩缩容进行额外的精力支出。开发者需要关注的仅仅是自身的业务逻辑，至于在传统架构下需要安装配的各种服务器软件等，都变成了配置项交给云厂商来管理；同样，传统架构下需要根据服务器的利用而进行资源的扩缩行为，也全都自动化地交给云厂商来实现。

传统意义上的弹性伸缩，指的是当项目的容量规划与实际集群负载间出现矛盾时，即当现有集群的资源无法承载压力时，通过调整集群的规模或者进一步分配相对应的资源，以保障业务的稳定性。当集群负载较低时，系统可以尽量降低集群的资源配置从而减少闲置资源的浪费，以进一步节约成本开销。但是在 Serverless 架构下，弹性伸缩被进一步泛化，即在用户侧的表现，取消了项目本身容量规划的过程，而是完全由平台调度决定资源的增加与缩减。

在 UC Berkeley 的文章中，对 Serverless 架构特点与优势的描述，有这样的表达：“代码的执行不再需要手动分配资源。不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘等），只需要提供一份代码，剩下的交由 Serverless 平台去处理就行了。当前阶段实现平台分配资源时还需要用户方提供一些策略，例如单个实例的规格和最大并发数，单实例的最大 CPU 使用率。理想的情况是通过某些学习算法来进行完全自动的自适应分配”，其实作者在此处所描述的“完全自动的自适应分配”指的就是 Serverless 架构的弹性伸缩的特点。

Serverless 架构下的弹性伸缩指的是，Serverless 架构可以根据业务流量波动，自动进行资源的分配和销毁，并最大程度化地平衡稳定性、高性能、提升资源利用率。即当开发者完成业务逻辑的开发，把业务代码部署到 Serverless 平台之后，平台通常并不会立即分配计算资源，而是将业务代码与配置等相关内容进行持久化，当流量请求到来时，Serverless 平台会根据真实流量以及配置情况，自动的进行实例的启动，反之也会自动的进行实例的缩减，甚至在某些时候实例的个数可以缩减到 0，即平台并未分配资源给对应函数。

Serverless 架构的核心技术红利——弹性伸缩能力，在一定程度上也代表着提升资源利用率，朝着绿色计算方向不断前进的过程。

在上图弹性伸缩部分：左侧是传统云主机架构下流量与机器负载示意图，右侧是 Serverless 架构弹性模式下流量与负载的示意图，在这两个图中，橙色面积部分表示的是用户侧所感知的资源负载能力，蓝色的折线表示的是某网站在某天的流量走势图。通过这两张图对比，不难发现，传统云主机架构下，需要人工进行资源的增加与缩减，变化的粒度是主机级别，所以实现性受到严重考验，粒度过粗仍然没办法有效地平衡资源浪费与性能稳定之间的关系。

在图中，蓝色线以上的橙色面积，是被浪费掉的资源；右侧是 Serverless 架构弹性模式下流量与负载的示意图，在这个图中可以清晰地看到负载能力始终是和流量是匹配的，即并不需要像左侧传统云主机架构，需要在技术人员的人为干预下应对流量的波峰波谷；这一切的弹性能力（包括扩容和缩容），均由云厂商提供；这种模式下所带来的好处一方面是降低业务运维人员的压力，降低其工作复杂度；另一方面可以看到在用户侧的感知是真实的资源消耗与所需的资源消耗是成正相关的，可以极大程度地降低资源浪费的情况，在一定程度上也是符合绿色计算思想的。

所谓的按量付费是一种先使用后付费的计费方式，通过按量付费，用户无需提前购买大量资源，而是可以根据资源的使用量进行后付费。即便非 Serverless 架构的产品或者服务，也具备一定的按量付费能力，例如云主机等产品均有按量付费的选项。但是之所以 Serverless 架构可以将按量付费作为一种技术红利，其很大的一部分原因在于它按量付费的粒度会更细，在用户侧的资源利用率表现为近乎 100%（实际上资源利用率没有达到 100%，仅仅指代的是在请求粒度下，用户侧在 Serverless 架构下的一种感知）。

以某网站为例，在白天时资源利用率相对较高，夜晚时间段资源利用率相对较低，但是一旦购买了服务器等资源，实际上无论当天流量多少，费用都是持续支出的过程。即便采用按量付费的模型，也会因为计费粒度过粗，而没办法最大可能性地提升资源利用率。按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供 5%～15% 的平均最大处理能力的输出，这无疑也证明了传统服务器的资源使用率过低和浪费过多的情况。

而 Serverless 架构的出现，可以让用户委托服务提供商管理服务器、数据库和应用程序甚至逻辑，这样的做法一方面减少了用户自己维护的麻烦，一方面用户可以根据自己实际使用函数的粒度进行成本的支付。对于服务商而言，他们可以将更多的闲置资源进行额外的处理，从成本的角度、“绿色”计算的角度来说，都是非常不错的。而从另一个角度，尽管 Serverless 架构的按量付费模型也是按照资源使用量进行收费的，但是计费粒度更为细腻：

• 请求次数角度：Serverless 架构的计费粒度是请求级别的，而传统的云主机等架构的计费粒度是实例级别的（往往这种实例级别的所支持的请求个数远远大于 1）；
• 计费时间角度：Serverless 架构的计费时间通常为秒级（但是现在阿里云支持毫秒级计费或者是百毫秒级计费）而对于传统的云主机架构，计费时间粒度往往是小时级；

同样在上图中的按量部分，是该网站的某天的流量图，图中的蓝色的折线为一个网站在某天的流量走势。通过对比“传统云主机架构流量与费用支出示意”与“Serverless 架构弹性模式下费用支出示意图”不难发现，左侧的传统云主机架构下流量与费用支出示意图，通常业务在上线之前是需要进行资源使用量评估的，当该网站的资源使用量评估之后，购买了一台可以承受每小时最大 1300PV 的服务器，那么在一整天的时间内，这台服务器所提供的算力总量为橙色面积，所需的费用也是橙色面积对应算力的费用。

但是我们明显可以看到，真正有效的资源使用与费用支出仅仅是流量曲线下面的面积，而流量曲线上方的橙色面积部分则为资源损耗与额外的支出部分；而右侧的 Serverless 架构弹性模式下费用支出示意图，费用支出和流量基本是成正比的，即当流量处于一个较低水位时，对应的资源使用量是相对较少的，同样对应的费用支出也是相对较少的；当流量处于一个比较高的数值时，借助 Serverless 架构的弹性伸缩能力与按量付费能力，资源使用量和费用支出将会成正相关增长；在整个过程中，能够清晰看到并未像左侧传统云主机架构下流量与费用支出示意图，产生明显的资源浪费与额外的成本支出。

视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、鉴黄鉴恐等，以满足不同场景下的需求。

除此之外，Serverless 还可以在实时文件处理，实时流处理、机器学习、IOT 后端、移动应用后端、web 应用程序等多种场景下发挥作用。

全球领先的 Serverless 平台

阿里云是国内较早一批提供 Serverless 服务的厂商，在过去几年的实践中，也取得了优异的成绩。包括但不限于，2021 年 Q1 Forrester 评测中，阿里云的 Serverless 产品能力位居中国第一；CNCF 2020 年云原生调研报告中，阿里云 Serverless 市场份额是国内第一；信通院 2020 年中国云原生用户调研报告中，阿里云 Serverless 用户占比同样国内第一。

 阿里云 Serverless 产品布局

从上图中，可以看到在最底层是计算平台和 BaaS 产品层。计算产品部分，有事件驱动的—— 函数计算 FC，也有应用 Serverless 化的最佳实践——Serverless 应用引擎 SAE；在 BaaS 服务联动部分，有不同层面的服务，数据库，网络，消息等，而这些产品也正在不断的 Serverless 化，从云到云原生再到 Serverless 化；在上层有开发者工具和应用中心，为广大开发者提供前后端一体化、WebAPI 以及数据库处理、AI 推理等一系列的 All On Serverless 解决方案和场景。

 让 Serverless 更简单：Serverless Devs

在生态层面，阿里云 Serverless 团队开源了无厂商锁定工具——Serverless Devs，秉承着让 Serverless 更简单，可以在 Serverless 应用全生命周期发挥作用的态度，Serverless Devs 不仅仅在底层规范模型上，推动信通院一同发布 Serverless 工具链模型，也在工具层面捐赠项目到 CNCF Sandbox，成为了全球首个 CNCF Serverless Tools 中的 Sandbox 项目。

综上所述，做 Serverless 架构，阿里云是认真的，也是专业的。感谢大家对阿里云 Serverless 架构的关注。

你可能还想看关注我们

欢迎关注加星标✨ 每日推送不错过