FaaS、PaaS 和无服务器体系结构的优势

本文介绍了无服务器技术，并将其与 PaaS 和 SpaaS 进行了对比，同时介绍了无服务器体系结构的收益和成本，还有框架方面的需求。

最开始，“无服务器”意在帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”，而是指由第三方供应商负责后端基础结构的维护，以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。这种服务基础结构通常可以叫做后端即服务（Backend-as-a-Service，BaaS），或移动后端即服务（Mobile Backend-as-a-service，MBaaS）。

但 Amazon 在 2014 年发布的 AWS Lambda 让“无服务器”这一范式提高到一个全新的层面，为云中运行的应用程序提供了一种全新的系统体系结构。至此再也不需要在服务器上持续运行进程以等待 HTTP 请求或 API 调用，而是可以通过某种事件机制触发代码的执行，通常这只需要在 AWS 的某台服务器上运行一个简单的功能。

使用这一范式的开发者无需考虑服务器细节，只需要负责编写发生某些事件后所需执行的代码。云供应商将负责提供用于运行这些代码的服务器，并在必要时对服务器进行缩放。执行完毕后，承担这些功能的容器会立刻停用，并且执行过程以 100 毫秒为单位进行度量，用户只需为运行代码过程中所消耗的资源付费。一些人将这种模式叫做功能即服务（Function-as-a-Service，FaaS），另一种“即服务”（Yet-Another-as-a-Service，YassS），自从云计算技术登场后这样的称呼越来越多了。

Amazon 并不是唯一的 FaaS 供应商。其他厂商，例如 Google Cloud Functions 、 Microsoft Azure Functions 、 IBM OpenWhisk ，以及 Iron.io 和 Webtask 等各种开源实现都提供了类似的服务。

无服务器体系结构很适合搭配NanoService 使用。如果说微服务（MicroService）是为了提供相对小规模的业务能力，那么可以认为NanoService 提供的是这种能力的碎片。例如，可以通过微服务代表为某个客户执行所有CRUD 操作所需的代码，而NanoService 可以代表客户所要执行的每个操作：创建、读取、更新，以及删除。当触发“创建帐户”事件后，将通过AWS Lambda 函数的方式执行相应的NanoService。但这种时候很少使用NanoService 这样的称呼，大部分人更愿意将其称为微服务，或者就叫做“服务”。

一些人认为 FaaS 就是另一种形式的 PaaS ，但 Intent Media 的工程副总裁 Mike Roberts有自己的不同看法：

大部分 PaaS 应用无法针对每个请求启动和停止整个应用程序，而 FaaS 平台生来就是为了实现这样的目的。…

FaaS 和 PaaS 在运维方面最大的差异在于缩放能力。对于大部分 PaaS 平台，用户依然需要考虑缩放，例如在使用 Heroku 时需要考虑到底需要运行几个 Dyno。但是对于 FaaS 应用，这种问题完全是透明的。就算将 PaaS 应用设置为自动缩放，依然无法在具体请求的层面上进行缩放（除非提供非常具体的流量塑形配置文件），而 FaaS 应用在成本方面效益就高多了。

Roberts 并不认为大家都需要抛弃 PaaS 转为拥抱 FaaS，原因有几个：“工具，以及 API 网关的完善程度可能是最大的问题。此外 PaaS 中实施的 12-Factor Apps 可能会使用应用内只读缓存以优化性能，这种情况就不适合使用 FaaS 功能。”

自称为资深思想家和“话痨”的 Camille Fournier 发布了一条推文质疑说：“如果无服务器服务将成为类似存储过程那样的重要概念，一个本来挺好的想法可能很快就会产生大量技术债。”作为对这个问题的回应，Roberts 认为，只有在无服务器功能仅仅是“一小段用于对数据库的访问进行封装（Wrap）”的情况下，FaaS 才能称之为SpaaS（Stored-Procedures-as-a-Services，存储过程即服务）。但FaaS 的功能还可以用于其他很多用途，因此不适合这样进行类比。Roberts 同时还补充说，与存储过程不同，无服务器的功能不依赖具体的语言或框架供应商，可以轻松实现测试和版本控制等功能。

谈到无服务器体系结构，ThoughtWorks 公司的开发者Badri Janakiraman补充了 FaaS 导致的一种变革：长久以来，用于包含大部分逻辑的服务器流程可以拆解为大量专有的，以及第三方服务，同时对应用程序的控制转移到了客户端：

无服务器应用程序通常需要借助大量第三方服务实现原本由自己的服务器所承担的任务。这些服务相互交织组成了丰富的服务生态系统，例如 Amazon AWS 和 Azure ，或者也可以通过“大包大揽”的方式通过一个服务提供一系列能力，例如 Parse 或 Firebase 。这些服务所提供的抽象可以是基础结构层面的（例如消息队列、数据库、边缘缓存…），也可能是高级别的（例如联合身份、角色和能力管理、搜索…）。

对于常规用途的基于服务器的 Web 应用程序，其主要职责之一在于控制请求响应周期。服务器端的控制程序负责处理输入，引用相应的应用程序行为，构建动态的响应，这一过程通常需要使用模板化的引擎。在无服务器应用程序中，应用程序的行为与第三方服务交织在一起，客户端的控制流和动态的内容生成取代了服务器端的控制程序。富 JavaScript 应用程序、移动应用（以及越来越多的电视机或嵌入式物联网应用）通过调用 API 并使用客户端 UI 框架生成动态内容，借此对不同服务之间的交付进行协调。

对于实施无服务器应用程序所能获得的收益，Janakiraman 认为包括：成本大幅降低，开发者不需要为云中运行的整个服务器付费，只需要为执行代码过程中消耗的资源付费；可缩放能力，可以通过事件触发的方式轻松地对不同服务进行缩放，而无须考虑基础结构的运维和维护。在成本方面 Janakiraman 认为“将一个应用程序拆分为相互交织的不同服务，观念上的负担会非常大，所用服务的种类越多这种负担就会越大”，并且开发测试工作的复杂度会增加。

使用无服务器方法通过 FaaS 创建整个后端系统时还有一项隐含成本， serverless.com 在自己的文档中谈到了这个问题：

虽然 AWS Lambda 提供了强大的应用程序开发 / 运行新方法，但在完全基于 AWS Lambda 开发首个项目时我们意识到自己急需一种新的结构。对 Lambda 所引入的所有容器进行管理这是一项困难的任务。对于包含多名开发者、多种阶段，或需要为多个区域提供支持的团队，很快就会开始变得手忙脚乱。

为此 Serverless Inc. 制订了 Serverless Framework ，希望借助这个开源项目帮助开发者通过 FaaS 顺利构建 Web、移动，以及物联网应用程序。该框架目前可适用于 AWS Lambda，但框架的创建者预计未来还将支持其他供应商。这个框架提供了多种功能，包括在本地或远程运行和测试 Lambda 函数，部署 Lambda 函数，将 REST API 部署至 AWS API 网关，部署 Lambda 事件，为多个 AWS 地区提供支持等。目前可支持的语言包括 JavaScript/Node.js，对 Python 和 Java 的支持正在开发中，稍后可能还会增加对其他语言的支持。

其他无服务器框架还包括 Apex ，该框架具备类似的功能，可支持 JavaScript/Node.js、Go、Java 和 Python，未来还计划支持其他供应商。

对于希望进一步了解无服务器体系结构的人，amazon.com 的 CTO Werner Vogels 发布了一系列使用 AWS Lambda 构建应用程序的参考体系结构。他还提供了各种指南，帮助开发者创建移动后端、实时文件处理能力、Web 应用程序、物联网后端，以及基于 Kinesis 的实时流处理能力。这些参考体系结构中体现的基本原则也适用于其他 FaaS 供应商，不过具体使用到的服务可能会有所变化。