作者 | 江昱（阿里云 Serverless 产品经理）

抛砖引玉：从云计算到 Serverless

2009 年，UC Berkeley 发表了：Above the Clouds: A Berkeley View of Cloud Computing 一文，在该文章中首次对云计算做出定义：云计算蕴含互联网上的应用服务及在数据中心提供这些服务的软硬件设施。居诸不息，随着云计算飞速发展，云计算的状态也在一直的演进，从 IaaS 到 PaaS，再到 SaaS，云计算也逐步地“找到了正确的倒退方向”。

（云计算倒退状态）

2012 年由 Iron.io 的副总裁 Ken Form 所写的一篇名为 Why The Future of Softwareand Apps is Serverless 的文章中，提出了一个新的观点：即便云计算曾经逐步的衰亡，然而大家依然在围绕着服务器转。不过，这不会继续太久，云利用正在朝着无服务器方向倒退，这将对应用程序的创立和散发产生重大影响。并首次将“Serverless”这个词带进了公众的视线。

到了 2017 年，各大云厂商基本上都曾经在 Serverless 进行了根底的布局，尤其是国内的几大云厂商，也都先后在这一年迈入“Serverless 时代”。

从下图咱们能够看到，在 IaaS 到 PaaS 再到 SaaS 的演进过程中，云计算所体现出的去服务器化越来越显著，那么前文中 Ken Form 所提出来的 Serverless 又是什么，它在云计算倒退的过程中，又在表演什么角色呢，它的去服务器化又到了什么水平呢？

What is Serverless？

Serverless 翻译成中文是无服务器，所谓的无服务器并非是说不须要依附服务器等资源，而是说开发者再也不必过多思考服务器的问题，能够更专一在产品代码上，同时计算资源也开始作为服务呈现，而不是作为服务器的概念呈现。

Serverless 是一种构建和治理基于微服务架构的残缺流程，容许用户在服务部署级别而不是服务器部署级别来治理用户的利用部署。与传统架构的不同之处在于，它齐全由第三方治理，由事件触发，存在于无状态（Stateless），暂存（可能只存在于一次调用的过程中）在计算容器内，Serverless 部署利用无需波及更多的基础设施建设，就能够根本实现主动构建、部署和启动服务。

近些年来，微服务（Micro Service）是软件架构畛域另一个热门的话题，如果说微服务是以专一于繁多责任与性能的小型功能块为根底，利用模组化的形式组合出简单的大型应用程序，那么能够进一步认为 Serverless 架构能够提供一种更加“代码碎片化”的软件架构范式，而这一部分称之为 Function as a Services（FaaS）。而所谓的“函数”提供的是相比微服务更加细小的程序单元。

例如，能够通过微服务代表为某个客户执行所有 CRUD 操作所需的代码，而 FaaS 中的函数能够代表客户所要执行的每个操作：创立、读取、更新以及删除。当触发“创立账户”事件后，将通过函数的形式执行相应的“函数”。单就这一层意思来说，能够简略地将 Serverless 架构与 FaaS 概念等同起来。然而就具体的概念粗浅摸索的话，Serverless 和 FaaS 还是不同的，Serverless 和 FaaS 被广为承受的关系是：

Serverless= FaaS + BaaS（+ …..）

在这个关系中，能够看到 Serverless 的组成除了 FaaS 和 BaaS（Backend as a Service）之外，还有一系列的省略号，其实这是 Serverless 给予给大家的遥想空间，给予这个时代的一些期待。

在前人的形容中 Serverless 架构从构造上，行为上以及个性上的定义，能够总结演绎成下图的模式：

「从组成定义来看」

Martin Fowler 认为，在 Serverless 架构中，利用的一部分服务端逻辑仍然由开发者实现，然而和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、齐全由第三方治理，这种状况称为 FaaS。除此之外，Serverless 架构还要有局部依赖于第三方（云端）利用或服务来治理服务器端逻辑和状态的利用，而这些服务即是所认为的“BaaS”局部。

「从行为定义来看」

CNCF 在以上根底对 Serverless 架构的定义，进一步的欠缺形容：

Serverless 是指构建和运行不须要服务器治理的应用程序概念。它形容了一种更细粒度的部署模型，其中将应用程序打包为一个或多个性能，上传到平台，而后执行、扩大和计费，以响应过后确切的需要。

「从个性定义来看」

2019 年 UC Berkeley 在文章 CloudProgramming Simplified: A Berkeley View on Serverless Computing 中从 Serverless 架构个性的角度，对什么是 Serverless 也进行了补充和形容：简略地说，Serverless = FaaS + BaaS。在对于被认为是 Serverless 的服务时，它必须具备弹性伸缩和按量付费的特点；

在信通院云原生产业联盟所公布的《云原生倒退白皮书（2020 年）》中对 Serverless 的概念也有相干的形容：无服务器（即 Serverless）是一种架构理念，其核心思想是将提供服务资源的基础设施形象成各种服务，以 API 接口的形式供应用户按需调用，真正做到按需伸缩、按应用免费。这种架构体系结构打消了对传统的海量继续在线服务器组件的需要，升高了开发和运维的复杂性，升高经营老本并缩短了业务零碎的交付周期，使得用户可能专一在价值密度更高的业务逻辑的开发上。

随着各大厂商逐步布局 Serverless 畛域，Serverless 逐步地从启蒙阶段，市场教育阶段迈向更深一步的生产利用与最佳实际阶段的方向后退，下文中咱们会具体介绍。

Serverless 的倒退历程

在 2017 年，CNCF Serverless WG 成立了，并且开始以社区的力量推动 Serverless 疾速前行，包含 CNCF Serverless Whitepaper、CloudEvents 等相干的立项钻研与摸索，2017 年末，eWEEK 的 ChrisJ. Preimesberger 发表文章 Predictions 2018: Why ServerlessProcessing May Be Wave of the Future 来表白在“全新的阶段下”大家对 Serverless 的认识和期盼，在这篇文章中诸多来自出名团队以及公司的相干负责人对 Serverless 表白了本人的想法：Serverless 可能是继容器之后的将来，能够预感 Serverless 将不断扩大影响力；重塑软件的构建形式。

而到了 2018 年，Serverless 的倒退速度要比设想中的更加疾速，国内外云厂商一直发力推出新技术，同年 CNCF 也正式公布了 Serverless 畛域的白皮书：CNCF Serverless Whitepaper V1.0，说明 Serverless 技术详情、生态系统状态，为 CNCF 的下一步动作做领导。同时 CloudEvnent 标准，进入 CNCF Sandbox。

在这一年，UC Berkeley 发文 Serverless Computing: One Step Forward, Two Steps Back，表白了对 Serverless 的担心和挑战，作者认为 Serverless 会对开源服务翻新有所阻塞。其实，任何一个新的技术、概念呈现都会遇到肯定的挑战和担心，就如同当年云计算呈现时，也被一些人认为只是又一个商业炒作的概念，当然事实也证实，任何一个新的事物，只有在经验各种挑战和质疑之后，能力更茁壮地成长。

从 2019 年开始，Serverless 进入到了一个真正意义上的生产利用，最佳实际疾速倒退阶段，这一年对 Serverless 而言是具备里程碑式意义的，被很多人定义为“Serverless 正式倒退的元年”。

在这一年不仅有 KubeCon 在中国上海的 CloudNativeCon 中对于 Serverless 的“海量主题演讲”，更有 UC Berkeley 最新的文章，Cloud Programming Simplified: A Berkeley View on Serverless Computing。

在这篇文章中，经验了一年的倒退，UC Berkeley 的学者们也从一年前的质疑，乐观转变成了自信与期待，并这篇文章中犀利断言 Serverless 将会在接下来的十年被采纳并失去飞速的倒退，认为 Serverless 将引领云计算的下一个十年，并且重点论述了以下新观点：

• 新的 BaaS 存储服务会被创造，以扩大在 Serverless 计算上可能运行更加适配的应用程序类型。这样的存储可能与本地块存储的性能相匹配，而且具备长期和长久可供选择。
• 比现有的 x86 微处理器更多的异构计算机。
• 更加平安、易用的编程，不仅具备高级语言的形象能力，还有很好的细粒度的隔离性。
• 基于 Serverless 计算的价格将低于 Serverful 计算，至多不会高于 Serverful 计算。
• Serverless 将会接入更多的后盾撑持服务，如 OLTP 数据库、音讯队列服务等。
• Serverless 计算一旦获得技术上的冲破，将会导致 Serverful 服务的下滑。
• Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，因而也意味着服务器 – 客户端模式的终结。

除了这些断言，Berkeley 也对什么是“Serverless”给出了本人的想法：

Put simply, Serverless computing = FaaS + BaaS. In our definition,for a service to be considered serverless, it must scale automatically with noneed for explicit provisioning, and be billed based on usage.

能够看到，从 IaaS 到 FaaS 再到 SaaS，再到现在的 Serverless，云计算的倒退在近十余年中产生了天翻地覆的变动，置信随着 5G 时代的到来，Serverless 将会在更多畛域施展至关重要的作用。

Serverless 的最佳利用场景

Serverless 架构作为云原生技术将来的演进方向，无服务器架构技术也从张望逐步落地，据 Gartner 的过往预测数据显示：到 2020 年寰球将有 20% 的企业部署无服务器架构。Serverless 将进一步开释云计算的能力，将平安、牢靠、可伸缩等需要交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高利用开发效率。同时这个形式促成了社会分工协作，云厂商能够进一步通过规模化、集约化实现计算成本大幅优化。

聚焦业务外围价值

随着云服务的倒退，计算资源被高度抽象化，从物理机到云服务器，再到容器服务，计算资源逐步变得更加细腻化。Serverless 架构将会成为将来云计算畛域中重要的技术架构，被更多的业务所驳回，成为其技术选型，那么再进一步的深究，Serverless 在什么场景下能够有十分优良的体现，在什么类型的场景下可能体现得并不是很现实呢？或者说，有哪些场景更适宜 Serverless 架构呢？

Serverless 架构的利用场景，通常是由其个性决定方向，所反对的触发器决定具体场景。

CNCF Serverless Whitepaper v1.0 所形容的用户场景

如图上图所示，在 CNCFServerless Whitepaper v1.0 对于 Serverless 架构所适宜的用户场景包含：

• 异步的并发，组件可独立部署和扩大的场景
• 应答突发或服务使用量不可预测的场景
• 短暂、无状态的利用，对冷启动工夫不敏感的场景
• 须要疾速开发迭代的业务，因为无需提前申请资源，因而能够放慢业务上线速度

CNCF 基于 Serverless 架构的个性给出了四个用户场景之外，还联合常见的触发器提供了具体的例子：

• 响应数据库更改（插入、更新、触发、删除）的执行逻辑
• 对物联网传感器输出音讯（如 MQTT 音讯）进行剖析
• 解决流解决（剖析或批改动态数据）
• 治理单次提取、转换和存储须要在短时间内进行大量解决（ETL）
• 通过聊天机器人界面提供认知计算（异步）
• 调度短时间内执行的工作，例如 CRON 或批处理的调用
• 机器学习和人工智能模型
• 继续集成管道，按需为构建作业提供资源，而不是放弃一个构建从主机池期待作业分派的工作

以上是从实践上形容了 Serverless 架构适宜的场景或业务，云厂商将会站在本身的业务角度，整体来形容 Serverless 架构的典型场景。通常状况下，对象存储为触发器在 Serverless 架构的典型利用场景包含视频解决、数据 ETL 解决等；API 网关更多会为用户赋能对外的拜访链接以及相关联的性能等，当以 API 网关作为 Serverless 相干产品的触发器时，常见的利用场景就是后端服务，包含 App 的后端服务，网站的后端服务甚至是微信小程序等相干产品的后端服务，同时像一些智能音箱也会凋谢相干的接口，这个接口也是能够通过 API 网关登程云函数，取得相应的服务等；除了对象存储触发以及 API 网关触发，常见的触发器还有音讯队列触发器，Kafka 触发器，日志触发器等。

常见利用场景

「Web 利用 / 挪动利用后端」

Serverless 架构和云厂商所提供的其余云产品进行联合，开发者可能构建可弹性扩大的挪动或 Web 应用程序 – 轻松创立丰盛的无服务器后端，而且这些程序可在多个数据中心高可用运行，毋庸在可扩展性、备份冗余方面执行任何管理工作。例如 Web 利用解决示例：

（Web 利用后端解决示例）

「实时文件 / 数据处理」

视频利用、社交利用等场景下，用户上传的图片、音视频往往总量大、频率高，对解决零碎的实时性和并发能力都有较高的要求。

例如：对于用户上传的图片，能够应用多个函数对其别离解决，包含图片的压缩、格局转换、鉴黄鉴恐等，以满足不同场景下的需要。例如：

（实时文件解决示例）

通过 Serverless 架构所反对的丰盛的事件源，通过事件触发机制，能够通过几行代码和简略的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行荡涤、对 MNS 音讯进行自定义生产等：

（实时数据处理示例）

「离线数据处理」

通常要对大数据进行解决，须要搭建 Hadoop 或者 Spark 等相干大数据的框架，同时要有一个解决数据的集群。通过 Serverless 技术，只须要将取得到的数据一直的存储到对象存储，并且通过对象存储相干触发器触发数据拆分函数进行相干数据或者工作的拆分，而后再调用相干处理函数，解决实现之后，存储到云数据库中。

例如：某证券公司每 12 小时统计一次该时段的交易状况并整顿出该时段交易量 Top 5；每天解决一遍秒杀网站的交易流日志获取因售罄而导致的谬误从而剖析商品热度和趋势等。函数计算近乎有限扩容的能力能够使用户轻松地进行大容量数据的计算。

利用 Serverless 架构能够对源数据并发执行多个 mapper 和 reducer 函数，在短时间内实现工作；相比传统的工作形式，应用 Serverless 架构更能防止资源的闲置节约从而节省成本，整个流程能够简化为：

（数据 ETL 解决示例）

「人工智能畛域」

在 AI 模型实现训练后，对外提供推理服务时，能够应用 Serverless 架构，通过将数据模型包装在调用函数中，在理论用户申请达到时再运行代码。绝对于传统的推理预测，这样做的益处是无论是函数模块还是后端的 GPU 服务器，以及对接的其余相干的机器学习服务，都是能够进行按量付费以及主动伸缩，从而保障性能的同时也确保了服务的稳固：

「IoT 等物联网畛域」

目前很多厂商都在推出本人的智能音箱产品，用户能够对智能音箱说出一句话，智能音箱能够通过互联网将这句话传递给后端服务，而后取得到反馈后果，再返回给用户。通过 Serverless 架构，能够将 API 网关、云函数以及数据库产品进行联合来代替传统的服务器或者是虚拟机等。

通过这样的一个架构，一方面，能够确保资源的按量付费，只有在应用的时候，函数局部才会计费，另一方面当用户量减少之后，通过 Serverless 实现的智能音箱零碎的后端，也会进行弹性伸缩，能够保障用户侧的服务稳固，当要对其中某个性能进行保护，相当于对单个函数进行保护，并不会对主流程产生额定危险。相对来说会更加平安、稳固等：

（IoT 后端解决示例）

「监控与自动化运维」

在理论生产中，常常须要做一些监控脚本来监控网站服务或者 API 服务是否衰弱，包含是否可用、响应速度等。传统的办法是通过一些网站监控平台（如阿里云监控等）来进行监控和告警服务，这些监控平台的原理是通过用户本人设置要监控的网址和预期的工夫阈值，由监控平台部署在各地区的服务器定期发动申请对网站或服务的可用性进行判断。

当然，这些服务很多都是大众化的，尽管说通用性很强，然而实际上并不一定适宜。例如，当初须要监控某网站状态码，不同区域的延时，并且设置一个延时阈值，当网站状态异样或者延时过大时，通过邮件等进行告诉告警，针对这样一个定制化需要，目前来说大部分的监控平台很难间接实现，所以定制开发一个网站状态监控工具就显得尤为重要。

除此之外，在理论的生产运维中，还十分有必要对所应用的云服务进行监控和告警，例如在应用 Hadoop、Spark 的时候要对节点的衰弱进行监控；在应用 K8S 的时候要对 API Server、ETCD 等多维度的指标进行监控；在应用 Kafka 的时候，也要对数据积压量，以及 Topic、Consumer 等指标进行监控；这些服务的监控，往往不能通过简略的 URL 以及某些状态来进行判断，在传统的运维中，通常会在额定的机器上设置一个定时工作，对相干的服务进行旁路监控。

Serverless 架构的一个很重要利用场景就是运维、监控与告警，通过与定时触发器进行联合应用，能够非常简单地实现某些资源衰弱状态监控与感知，并进行一些告警性能建设、自动化运维能力建设：

（网站监控告警示例）

结语

从虚拟空间到云主机，从自建数据库等业务，到云数据库等服务，云计算的倒退是迅速地，将来的方向和状态却是含糊的，没人晓得云计算的终态是什么。诚然，当初有人说 Serverless 实现了当初了云计算指标，Serverless 才是真正的云计算，然而没人能够必定地说，Serverless 就是云计算的终态体现，主观地说，或者，Serverless 也仅仅是一个过渡的产物，然而这就要交给工夫去验证了。