**简介：**Serverless 架构被越来越多的业务所采纳，成为其技术选型，大多数开发者已经跨越对 Serverless 概念了解，切实向落地实践出发。本文带大家一探究竟，为什么说 Serverless 可以帮助开发者聚焦核心业务价值，以及有哪些场景更适合 Serverless 架构！
作者 | 江昱（阿里云 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 也仅仅是一个过渡的产物，但是这就要交给时间去验证了。
本文为阿里云原创内容，未经允许不得转载。
