前言

上文说到云计算的十余年发展让整个互联网行业发生了翻天覆地的变化，Serverless 作为云计算的产物，或者说是云计算在某个时代的表现，被很多人认为是真正意义上的云计算，关于“Serverless 是什么”这个问题，其实是可以通过不同角度来分析的。

Martin Fowler 在 “Serverless Architectures” 一文中从 Serverless 组成角度给出了 Serverless 的定义，他认为 Serverless 实际上是 BaaS 与 FaaS 的组合，并针对 BaaS 和 FaaS 进行了详细的描述。

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

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

通过 Martin Fowler 的描述可以总结出 FaaS、BaaS 以及 Serverless 之间的关系为下图所示。

Serverless 架构的组成

从 Serverless 的结构上来看，Serverless = FaaS + BaaS 是一个被普遍认可的概念；从 Serverless 的特性上来看，Serverless 运行在无状态的计算容器中，由事件触发，并且拥有弹性伸缩以及按量付费等能力，让使用者不用花费更多的精力在服务器上，而是更加关注业务本身。

不同角度上的 Serverless 的定义

Serverless 工作流程

在实际生产中，Serverless 架构通常都是 FaaS 与 BaaS 的结合，并且具备弹性伸缩和按量付费的特性。

当开发者想要开发一个项目的时候：

通常只需要根据 FaaS 提供商所提供的 Runtime，选择一个熟悉的编程语言，然后进行项目开发、测试（图中步骤 1）
完成之后将代码上传到FaaS平台（图中步骤 2）
上传完成之后，只需要通过 API/SDK；或者一些云端的事件源（图中步骤 3）
触发上传到 FaaS 平台的函数，FaaS 平台就会根据触发的并发度等弹性执行对应的函数（图中步骤 4）
最后用户可以根据实际资源使用量进行按量付费（图中步骤 5）

Serverless 工作流程

我们来看一个 Web 应用的例子。通常情况下一些 Web 应用都是传统的三层 C/S 架构，例如一个常见的电子商务应用，假设它的服务端用 Java，客户端用 HTML/JavaScript。

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

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

Serverless 应用形态简图

在 Serverless 应用形态下，移除了最初应用中的身份验证逻辑，换用一个第三方的 BaaS 服务（上图中步骤 1）；允许客户端直接访问一部分数据库内容，这部分数据完全由第三方托管，会用一些安全配置来管理客户端访问相应数据的权限（上图中步骤 2）；前面两点已经隐含了非常重要的第三点：先前服务端的部分逻辑已经转移到了客户端，如保持用户 Session、理解应用的 UX 结构、获取数据并渲染出用户界面等。

客户端实际上已经在逐步演变为单页应用（上图中步骤 3）；还有一些任务需要保留在服务器上，比如繁重的计算任务或者需要访问大量数据的操作。这里以“搜索”为例，搜索功能可以从持续运行的服务端中拆分出来，以 FaaS 的方式实现，从 API 网关（后文做详细解释）接收请求并返回响应。这个服务端函数可以和客户端一样，从同一个数据库读取产品数据。原始的服务端是用 Java 写的，而 AWS Lambda（假定用的这家 FaaS 平台）也支持 Java，那么原先的搜索代码略作修改就能实现这个搜索函数（上图中步骤 4）；还可以把“购买”功能改写为另一个 FaaS函数，出于安全考虑，它需要在服务端而非客户端实现。它同样经由API网关暴露给外部使用（上图中步骤 5）。

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

Serverless 的配套服务

1、开发者工具

Serverless 开发者工具包括命令行工具、编辑器插件以及其他工具。

一般情况下，命令行工具有厂商一方工具和开源建设的三方工具两种，例如 AWS Lambda 的 SAM CLI、阿里云函数计算的 Funcraft 等就是典型的一方工具。这类工具的特点是和厂商、产品的匹配度非常高，一些特性的支持比较迅速，缺点是比较保守。Serverless Devs、Serverless Framework 就是典型的三方工具，这两个工具都支持 AWS Lambda、阿里云函数计算、腾讯云云函数等云厂商的 FaaS 产品。

从客户端表现上来看，其都是 Serverless 开发者工具，都是组件化的命令行工具，也都支持多云；从形态上来看，Serverless Framework 更注重部署与运维方向， Serverless Devs 更注重 Serverless 应用的全生命周期。同时，Serverless Devs 相对 Serverless Framework 而言，增加了可视化界面。

Serverless Devs GUI 首页

如图所示，通过该界面，用户可以快速地部署应用。

Serverless Devs GUI 可视化 Yaml 编辑页

用户可以快速地管理云上 Serverless 相关资源，如图所示。

Serverless Devs GUI 项目管理页

Azure Functions 也提供了 Visual Studio Code 插件，如下图所示。Visual Studio 中的 Azure Functions 项目模板可用于创建项目，创建的项目可发布到 Azure 中的函数应用中。用户可使用函数应用将函数分组为一个逻辑单元，以便于管理、部署和共享资源。

Azure Functions 提供的 VSCode 插件

阿里云在开发者工具层面提供了 VSCode 插件，如图所示。

同时，阿里云函数计算还提供了 Cloud Toolkit 工具，实现了在本地 Jet Brains IDE 中运行、下载云端函数，创建、上传本地函数。以 IntelliJ IDEA 为例，其函数管理界面如下图所示。

阿里云函数计算 VSCode 插件函数管理界面

2、Serverless Workflow

Serverless Workflow（Serverless 工作流）是一个用来协调多个分布式任务执行的全托管云服务。

如图所示，在 Serverless 工作流中，用户可以用顺序、分支、并行等方式来编排分布式任务。Serverless 工作流会按照设定好的步骤可靠地协调任务，跟踪每个任务的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。

Serverless 工作流通过提供日志记录和审计来监视任务的执行，方便用户轻松地诊断和调试应用。Serverless 工作流简化了开发和运行业务流程所需要的任务协调、状态管理以及错误处理等烦琐的工作，让用户聚焦业务逻辑开发。

Serverless 工作流示例

Serverless 工作流可以协调分布式组件编排不同基础架构、不同网络、不同语言编写的应用，抹平混合云、专有云过渡到公共云或者从单体架构演进到微服务架构的落差。Serverless 工作流提供了丰富的控制逻辑，例如顺序、选择、并行等，让用户以更少的代码实现复杂的业务逻辑。Serverless 工作流为用户管理流程状态，提供内置检查点和回放能力，以确保应用程序按照预期逐步执行。错误重试和捕获可以让用户灵活地处理错误。Serverless 工作流根据实际执行步骤转换个数收费，执行结束不再收费。Serverless 工作流自动扩展，让用户免于管理硬件预算和扩展。

Serverless 应用的可观测性

Serverless 应用的可观测性是被很多用户所关注的。可观测性是通过外部表现判断系统内部状态来衡量的。在应用开发中，可观测性帮助用户判断系统内部的健康状况，在系统出现问题时，帮助用户定位问题、排查问题、分析问题；在系统平稳运行时，帮助用户评估风险，预测可能出现的问题。在 Serverless 应用开发中，如果观察到函数的并发度持续升高，很可能是业务推广团队努力工作使业务规模迅速扩张。为了避免达到并发度限制阈值，开发者就需要提前提升并发度。以阿里云函数计算为例，阿里云函数计算在可观测性层面提供了多种维度，包括 Logging、Metric 以及 Tracing 等。