Serverless 的定义

广义定义探索

云计算的十余年，让整个互联网发生了翻天覆地的变化，而 Serverless 作为云计算的产物，或者说是云计算在某个时代的表现，被很多人认为是真正意义上的云计算，UC Berkeley 甚至断言 Serverless 将会引领云计算的下一个十年，那么 Serverless 到底是什么呢？是否有明确的定义或者规范呢？

关于 Serverless 是什么这个问题，其实是可以通过不同角度来进行分析的，通过 Serverless 的组成来看，Martin Fowler 在 Serverless Architectures 一文中认为 Serverless 实际上是 BaaS 与 FaaS 的组合：BaaS and FaaS are related in their operational attributes (e.g., no resource management) and are frequently used together. The large cloud vendors all have "Serverless portfolios" that include both BaaS and FaaS products. 并针对 BaaS 和 FaaS 进行了详细的描述：

l  Serverless 最早用于描述那些大部分或者完全依赖于第三方（云端）应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端 App），建立在云服务生态之上，包括数据库（Parse、Firebase）、账号系统（Auth0、AWS Cognito）等。这些服务最早被称为 “(Mobile) Backend as a Service”，下文将对此简称为 “BaaS”。

l  Serverless 还可以指这种情况：应用的一部分服务端逻辑依然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、完全由第三方管理。这种情况称为 Functions as a service / FaaS。AWS Lambda 是目前的热门 FaaS 实现之一。

通过 Martin Fowler 的描述可以大概总结 FaaS, BaaS 以及 Serverless 的关系：

图 1.1 Serverless 架构的组成

而通过 Serverless 的一些特征特性来定义，CNCF WG-Serverless Whitepaper v1.0 中给了比较明确的说法：Serverless 是指构建和运行不需要服务器管理的应用程序概念。它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求。

同时 CNCF 关于 Serverless 的白皮书中也强调了，Serverless 所谓的“无服务器”并不是“没有服务器”，而是说 Serverless 的用户不再需要在服务器配置、维护、更新、扩展和容量规划上花费时间和资源，将更多的精力关注到业务逻辑本身，至于服务器，则“把更专业的事情交给更专业的人”去做，即由云厂商来提供统一的运维，针对这一部分在白皮书中的描述为：Serverless 并不意味着不再使用服务器托管和运行代码；也不意味着不再需要运维工程师。相反，它指的是 Serverless 的用户不再需要在服务器配置、维护、更新、扩展和容量规划上花费时间和资源。相反，所有这些任务和功能都由 Serverless 平台处理。因此，项目的研发人员专注于编写应用程序的业务逻辑，工程师们能够将他们的注意力提升到更关键的业务任务上。

在信通院云原生产业联盟所发布的《云原生发展白皮书（2020 年）》中对 Serverless 是什么也有相关的描述：无服务器（即 Serverless）是一种架构理念，其核心思想是将提供服务资源的基础 设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做 到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持 续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成 本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高 的业务逻辑的开发上。

图 1.2 不同角度上的 Serverless 的定义

如图 1.2 所示，总体来看，从 Serverless 的组成上来看，Serverless = FaaS + BaaS 是一个被普遍被认可的概念；从 Serverless 特征特性来看，Serverless 是运行在无状态的计算容器中，由事件触发，并且拥有弹性伸缩以及按量付费等能力，Serverless 让使用者不再花费更多的精力在服务器上，而是更加关注业务本身。在 2019 年 UC Berkeley 的文章 Cloud Programming Simplified: A Berkeley View on Serverless Computing 中也肯定了这一描述：简单地说，Serverless = FaaS + BaaS。在对于被认为是 Serverless 的服务，它必须具备弹性伸缩和按量付费的特点。（Put simply, serverless computing = FaaS + BaaS.  In our definition, for a service to be considered serverless, it must scale automatically with no need for explicit provisioning, and be billed based on usage. ）

Serverless 工作流程

在实际生产中，Serverless 架构通常情况也都是 FaaS 与 BaaS 的结合，并且具备弹性伸缩以及按量付费的特性。如图 1.3 所示，当开发者想要开发一个项目的时候，通常只需要根据 FaaS 提供商所提供的 Runtime，选择一个所熟悉的编程语言，然后进行项目开发、测试（图中步骤 1）；完成之后将代码上传到 FaaS 平台（图中步骤 2）；上传完成之后，只需要通过 API/SDK（图中步骤 3）或者一些云端的事件源（图中步骤 3）触发上传到 FaaS 平台的函数，FaaS 平台就会根据触发的并发度等弹性执行对应的函数（图中步骤 4），最后用户可以根据实际资源使用量进行按量付费（图中步骤 5）。

图 1.3 Serverless 工作流程

以一个 Web 应用为例：如图 1.4 所示，通常情况下一些 Web 应用都是传统的三层 C/S 架构，例如一个常见的电子商务应用，假设它服务端用 Java，客户端用 HTML/JavaScript：

图 1.4 传统 Web 应用三层 C/S 架构

在这个架构下服务端仅为云服务器，其承载了大量业务功能和业务逻辑，例如，系统中的大部分逻辑（身份验证、页面导航、搜索、交易等）都在服务端进行实现。当把它改造成 Serverless 应用形态：

图 1.5 Serverless 应用形态简图

在 Serverless 应用形态下，移除了最初应用中的身份验证逻辑，换用一个第三方的 BaaS 服务（步骤 1）；允许客户端直接访问一部分数据库内容，这部分数据完全由第三方托管，这里会用一些安全配置来管理客户端访问相应数据的权限（步骤 2）；前面两点已经隐含了非常重要的第三点：先前服务器端的部分逻辑已经转移到了客户端，如保持用户 Session、理解应用的 UX 结构、获取数据并渲染出用户界面等等。客户端实际上已经在逐步演变为单页应用（步骤 3）；还有一些任务需要保留在服务器上，比如繁重的计算任务或者需要访问大量数据的操作。这里以“搜索”为例，搜索功能可以从持续运行的服务端中拆分出来，以 FaaS 的方式实现，从 API 网关（后文做详细解释）接收请求返回响应。这个服务器端函数可以和客户端一样，从同一个数据库读取产品数据。 原始的服务器端是用 Java 写的，而 AWS Lambda（假定用的这家 FaaS 平台）也支持 Java，那么原先的搜索代码略作修改就能实现这个搜索函数（步骤 4）；还可以把“购买”功能改写为另一个 FaaS 函数，出于安全考虑它需要在服务器端，而非客户端实现。它同样经由 API 网关暴露给外部使用（步骤 5）；

在整个项目中，Serverless 的用户实际关心的也就只剩下函数中的业务逻辑，至于身份验证逻辑，API 网关以及数据库等原先在服务端的一些产品/服务统统交给云厂商提供。在整个项目开发、上线以及维护的过程中，用户并不需要关注服务器层面的维护，也无需为流量的波峰波谷进行运维资源的投入，这一切的安全性、弹性能力以及运维工作都交给云厂商来统一处理/调度，用户所需要关注的就是自己的业务代码是否符合自己的业务要求，同时 Serverless 架构下，用户也无需为资源闲置进行额外的支出，Serverless 架构的按量付费模型以及弹性伸缩能力、服务端低运维/免运维能力，可以让 Serverless 的用户的资源成本、人力成本、整体研发效能得到大幅度提升，让项目的性能、安全性、稳定性得到极大地保障。