为“无服务器”正名

无服务器（Severless)不是一个好的术语，但它却被用来描述一个强大且经常被误解的概念。

本文将讨论“无服务器”的缺点和优点，并为其改变构建应用程序的方式带来的好处辩护——进一步向无服务器架构发展。

现有的一些定义：

AWS——无服务器允许你构建和运行应用程序和服务，而无需考虑服务器。

Paul Johnston——无服务器的解决方案是，如果没有人使用它，就没有任何运行成本。

Mike Roberts——无服务器架构是在应用程序设计中包含第三方“后端即服务”（BaaS）服务和/或包含在“函数即服务”（FaaS）平台上托管的临时容器中运行的自定义代码。

这些定义都非常简洁和巧妙，但它们缺乏实用性细节，而这些细节是理解无服务器方法能力的关键。

作为一个补充说明，在早些时候，我在一条推特主题中给出一个简单定义。

上面使用的符号“⊂”是指左边东西是右边东西的子集，也就是说，FaaS 是无服务器的子集。

更深入的讨论

自 2014 年 AWS Lambda 发布以来，人们经常将 FaaS（函数即服务）和无服务器作为同义词使用。

FaaS 是一个计算服务术语，它允许代码的功能以一种隔离方式运行。这些函数在响应事件（如 HTTP 调用）时运行，一个系统抽象了服务器的底层复杂性，包括操作系统和所有的细节或配置和扩展。

FaaS 是许多无服务器架构的关键组成部分，但你可以实现一个不使用 FaaS 的无服务器架构，也能实现一个使用 FaaS 的非无服务器架构。在很大程度上，FaaS 是一种无服务器的计算方法，但是，对于许多应用程序架构来说，计算（即运行代码）并不是其唯一的一个方面。

应用程序架构可能需要很多东西，例如：计算、存储、监控……

AWS 提供的几个无服务器架构组件示例

如前所述，FaaS 函数是由事件（events）触发的，例如 HTTP 调用。上图中的其他无服务器服务都可以由事件触发，甚至能自己生成事件，从而触发更多的服务。迁移到能高效利用这些服务的架构，通常就是迁移到事件驱动的架构。

最近，事件驱动架构的概念开始与无服务器架构这个术语一起出现。

随着 AWS 等云提供商针对无服务器架构发布越来越多的服务，这种术语链接正在进一步扩展。这并不是什么新鲜事，无服务器从早期阶段就经常被描述为“scale to zero”——这种扩展和计费的方法显然与基于事件的服务紧密结合在一起。

事件驱动架构的一个例子是 AWS 发布的一个新的重要的无服务器服务——可以说是 Lambda 以来最大的服务之一。

EventBridge 是 AWS 针对无服务器全托管事件总线给出的答案。它使得事件可以通过更少的代码、更好的可观测性和一些非常超前的附加功能（如新推出的EventBrige模式注册表）在不同服务间流动。

模式注册表（The Schema Registry）可自动检测并将大型分布式架构的所有事件聚合到一个集中式注册表中——甚至为开发人员提供自动生成代码绑定的 SDK 来从 IDE 访问事件。

潜在解决方案空间在扩大

潜在解决方案空间包括上图所示的所有服务。

以及 AWS 和其他云提供商的许多其他服务。

以及未来十年将会发布的服务。

以及由富有创造力的工程师自行构建的无服务器系统，他们将这些组件块以连云提供商都没预料到的方式组合在一起，构建出新的、令人兴奋的东西。

毕竟，EventBridge 源于 AWS 发现了 Cloudwatch 事件被用来触发 Lambdas 的奇妙方式。

这种现象的另一个例子可能是简单的无服务器事件调度系统，我们搭配使用 Step Functions 和 Lambda 构建该系统，我们的另一篇文章对此进行了详细介绍。

那么，为何我们没全都采用无服务器呢？

首先，很难从一个经常被误用的术语“无服务器” 中看到这个潜在解决方案空间。

特别是当某个框架选择使用它作为自己的名称时——这是一个令人惊叹的工具，但无助于保留术语背后的复杂语义。

现在，显然不仅仅是因为一个词汇的问题减缓了无服务器架构的普及。这是一个范式转变，可能比之前的“云”更有影响力。

构建由服务器、自管理系统和永久状态组成系统的过程中成长起来的工程师，不得不转向事件驱动的思考方式，这种方式似乎具有无限的计算规模和存储空间——同时还面临着新的挑战、约束，而且缺少工具和最佳实践。

例如，迁移到更偏向无服务器的架构，通常涉及到采用 DynamoDB（或类似的东西）来代替过去的关系型数据库。NoSQL 现在已经不是什么新东西了，但是将它用于所有核心业务需求的想法是——这是因为整个系统现在的规模更大，而且具备之前人们并不了解的事件驱动的特性。

这并不容易——DynamoDB 很复杂，要做好就更复杂了。抛弃过去熟悉的 Web 应用程序框架——不是通过低成本的修改来保持函数的轻量化，而是将典型的框架责任转移给云提供商——这些都不是小事！

当你能清楚地看到“潜在空间”时，才能让收益大于成本

人们不会为了迁移系统和转变观念而经历这种痛苦。正如在许多其他文章中讨论的那样，无服务器架构允许开发人员专注于编写最能体现业务价值的代码，同时降低 TCO（总拥有成本）、增加可伸缩性并同时减少碳足迹（carbon footprint）。

无以言表

有时候，无法用言语来表达。有时候，要用一个词来描述潜在解决方案所涉及的范围之广、形式之多，实在是太过复杂。

但是，作为一个在许多新的无服务器服务出现前就存在的词，它做得还不错。事实上，这证明了这个我们正努力把它从这个空间中分离出来的词的力量。

如果这个词是 FunctionFull ，那么随着这个 space 的扩大，我们就不可能一直使用它，如果没有无服务器这颗北斗星引导我们走向一个无形的特性，也许我们不会以这种方式扩展这个空间。

目前，至少对我来说，无服务器设法完成了一项艰巨工作，定义了一个非常灵活且复杂空间的边界。

英文原文：

In Defence of “Serverless” —the term