共计 6965 个字符，预计需要花费 18 分钟才能阅读完成。
作者：刘宇（江昱）
从云计算到 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 发表了一篇对于云计算的文章，在文章中，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 产品和服务，之所以能够失去宽广开发者的认可，其根本原因是阿里云 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 架构的关注。
