小编说：软件行业是一个飞速发展的行业，不断推出新技术，以及令人目不暇接的概念和术语。厘清各种概念和术语的含义，对于分析技术发展趋势，决定是否需要及时入坑很有必要。今天我们就来聊一聊最近被热烈讨论的Serverless，以及与之相关的两个概念BaaS及FaaS。本文编译自What’s Serverless？（O’Reilly电子书）作者：Mike Roberts，John Chapin。相关图书推荐《Serverless架构：无服务器单页应用开发》

国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云相继推出Serverless产品，Serverless实际上涵盖了很多技术，可以分为两类：BaaS和FaaS。

BaaS

BaaS（Backend as a Service，后端即服务）是指我们不再编写和/或管理所有服务端组件。与虚拟实例和容器相比，在概念上它更接近SaaS（软件即服务）。SaaS主要是业务流程的外包——HR、销售工具，或者从技术端来讲，像Github这样的产品，而BaaS则是要把应用拆分为更小的颗粒，其中一部分完全使用外部产品实现。

BaaS 服务都是领域通用的远程组件（而不是进程内的库），可以以 API 的形式使用，深受移动 App 或者单页Web app开发团队的欢迎。因为这些团队通常会使用大量的第三方服务，否则他们就要自己花很多精力做这些事情。我们来看一些例子。

Google Firebase是完全由云厂商（Google）管理的数据库，可以直接在移动或者Web应用中使用，而无须经过我们自己的中间层应用服务器。这解释了BaaS的一个方面：用服务替我们管理数据组件。

BaaS服务还允许我们倚赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而其实对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。

BaaS这个词是随着移动应用开发火起来的。事实上，它有时指的是MBaaS（Mobile Backend as a Service）。然而，使用完全托管在外部的产品来开发应用，这个理念并不是移动开发，或者更一般地说，前端开发，所独有的。比如，我们可以不再管理EC2机器上的MySQL数据库服务器，转而使用Amazon的RDS服务，或者我们可以用Kinesis取代我们自己的Kafka消息总线。其他数据基础设施服务还有：文件系统/对象存储（如Amazon S3）、数据仓库（如Amazon Redshift），而更面向逻辑的服务，比如语音分析（如Amazon Lex）以及前面提到的认证，也可以直接在服务端组件中使用。这其中有很多服务都可以认为是Serverless，但并非全部都是。

FaaS/Serverless计算

事实上，Serverless 还有一半是 FaaS（Function asa Service，也即函数即服务）。FaaS 是Compute as a Service（计算即服务）的一种形式。事实上，有些人（特别是AWS）说FaaS就是Serverless计算。当然，不可否认，AWS的Lambda是如今被采用得最广泛的FaaS实现。

FaaS是一种构建和部署服务端软件的新方式，面向部署单个的函数或者操作。关于Serverless许多时髦的词儿都来自FaaS。很多人认为Serverless就是FaaS，其实他们是只知其一不知其二。

我们部署服务端软件的传统方式都是这样开始的：先要有一个主机实例，一般是一个虚拟机（VM）或者容器（见图1），然后把应用部署在主机上。如果主机是VM或者容器，那么我们的应用就是一个操作系统进程。通常我们的应用里包含各种相关操作的代码——比如一个Web服务可能要收回和更新资源。

图1 传统服务端软件的部署

FaaS改变了这种部署模式（见图2）。我们去掉主机实例和应用进程，仅关注表达应用逻辑的那些操作或者函数。我们把这些函数上传至由云厂商提供的FaaS平台。

图2 FaaS软件部署

但是在一个服务器进程中，函数不是一直处于运行状态的，它们只会在需要的时候才运行，其他时间都是空闲状态（见图3）。我们可以对FaaS平台进行配置，让它为每一个操作监听特定事件。一旦该事件发生，平台就会实例化Lambda函数，然后再用这个触发事件来调用该函数。

图3 FaaS函数生命周期

一旦这个函数执行完毕，FaaS平台就可以随意销毁它。或者，平台将其保留一会儿，直到有另一个事件需要处理。

FaaS本质上是事件驱动的途径。除了提供一个平台保存和执行代码，FaaS供应商还会将各种同步和异步事件源集成起来。比如 HTTP API Gateway 就是一个同步源；而托管的消息总线、对象存储，或者协调的事件就是异步源。

2014年秋 Amazon 发布了 AWS Lambda，经过3年时间，该产品已经逐渐成熟，开始被一些企业采纳。有些Lambda函数的使用量非常少，一天就几次，而也有些公司使用Lambda每天处理数十亿事件。截至本文写作之时，Lambda已经集成了15种以上的不同事件源，可以满足各种不同应用的需求。

除了大家所熟识的 AWS Lambda 之外，微软、IBM及Google等大公司，以及一些更小的厂商比如Auth0，也提供商业FaaS。正如各种Computer-as-a-Service平台（IaaS、PaaS、Container-as-a-Service）一样，现在也有一些开源FaaS项目，你可以在自己的硬件或者公有云平台上运行。目前这类私有FaaS还处于混战时代，并没有明显的冒尖者。Galactic Fog、IronFunctions及Fission（使用的是Kubernetes），以及IBM公司自己的OpenWhisk均属于开源系的FaaS。

Serverless的关键

从表面上看，BaaS和FaaS是两码事——前者是把应用中的各个部分完全外包出去，后者是一种新的运行代码的托管环境。那么，为什么要把它们都划归为Serverless呢？关键在于，它们都不需要你管理自己的服务器主机或者服务器进程。一个完全Serverless的app不需要你考虑架构中的任何东西。你的应用逻辑——不管是自己编程实现，还是使用第三方服务集成——运行在一个完全弹性的操作环境里。你的状态也是以同样弹性的形式存储的。

Serverless并不意味着没有服务器，而是你不需要操心服务器相关的事情。

跨越式变革

Serverless是变革。过去十年来，我们已经把应用和环境中很多通用的部分变成了服务。Serverless也有这样的趋势——如把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们都看作某种形式的商品——厂商提供服务，我们掏钱购买。这是云计算向纵深发展的一种自然而然的过程。

但是，Serverless给应用架构带来巨大的变化。直到现在，大多数云服务并没有从根本上改变我们设计应用的方式。比如，使用Docker时，把一个小“箱子”放到应用边上，但是它仍然是一个箱子，而我们的应用也没有显著改变。当我们把自己的MySQL实例托管到云上时，还是要思考需要怎样的虚拟机来处理负载，考虑故障转移问题。

Serverless带来跃进式的变化。Serverless FaaS开启的是一种全新的应用架构，完全由事件驱动。更细粒度的部署，需要在 FaaS 组件外面持久化状态。Serverless BaaS把我们从编写逻辑组件中解放出来，但是我们必须将应用与云厂商提供的特定接口与模式集成。

说一千道一万，Serverless应用如此特别，它长什么样呢？有什么优缺点，适合什么样的场景呢？只有自己做一个应用来亲身体会一下，才有发言权。