Serverless“革命”为什么已停滞不前？

本文要点

• 近几年，一些人预测无服务器计算将迎来新计算时代的蓬勃发展，让应用无需操作系统就能执行。虽然有人说这种框架将会解决在可扩展性上存在的许多问题，但事实并非如此。
• 虽然在许多人看来，无服务器技术是一个新的概念，但其根源可以上溯到2006年Zimki PaaS和Google App Engine对无服务器框架的探索。
• 导致无服务器革命停滞不前的原因，可归纳为从编程语言支持受限到性能问题等四个方面。
• 无服务器并非没有用武之地。但不应视其可直接替代服务器。在某些应用开发环境中，无服务器是非常便利的工具。

服务器已死，服务器永存！

为无服务器革命摇旗呐喊的声音正此起彼伏。如果快速回顾过去几年内的一些行业新闻，很容易得出结论说传统服务器模型已失效，而且在未来几年内无服务器架构将统治一切。

但业内人士都知道，也正如我们在“无服务器计算现状”一文中所指出的，事实并非如此。尽管有许多文章对无服务器革命的优点侃侃而谈，但这些优点依然尚未落地。事实上，最近有研究表明这一革命可能已经停滞不前。

必需承认，无服务器模型的部分承诺已经实现，但也只是一小部分而已。

本文将对这一现状背后的原因做出解答。尽管在一些具有明确定义的特定场景中下，无服务器模型的确展现了巨大的实用性，但此类系统看上去缺乏敏捷性和灵活性，阻碍了它们的广泛采用。

无服务器计算的承诺

在解释无服务器计算所存在的问题之前，先了解一下其承诺提供的功能。“无服务器革命的承诺”一文给出了详细列举，在当时看来是雄心勃勃。

对于初次接触无服务器概念的人而言，在此给出一个扼要定义。无服务器计算指应用或应用的某一部分在通常是远程托管的执行环境中按需运行的架构。也就是说，无服务器系统也可内部托管。过去几年中，构建有弹性的无服务器系统一直是系统管理员和 SaaS 公司的主要关注点。据称该架构提供了如下关键优势，所以优于“传统”的服务器和客户端模型：

1. 无服务器模型无需用户自身去维护操作系统，甚至无需去构建兼容特定操作系统的应用。相反，开发人员可以生成通用的代码，上传到无服务器框架，看着它运行就好了。
2. 在无服务器框架上使用资源通常是按分钟计费，甚至可按秒计费，意味着客户只需为他们代码的实际运行时间付费。这与传统的基于云的虚拟机形成了鲜明的对比。在传统的基于云的虚拟机上，用户最终会为一台大量时间闲置的计算机付费。
3. 可扩展性也是一大优势。无服务器框架中的资源支持动态分片，这意味着能够应对突发的需求峰值。

简而言之，上述优势表明无服务器模型应该能提供灵活、便宜、可扩展的解决方案。考虑及此，人们难免会对如此好的新理念相见恨晚。

无服务器是个新理念吗？

事实上它早已存在。用户只需为代码实际运行时间付费的理念，早在 2006 年就作为 Zimki PaaS 的一部分提供，Google App Engine 大体在同一时间也给出了非常相似的解决方案。

事实上，现在所说的“无服务器”模型要比当前许多称为“云原生”的技术都更历史悠久，并且可以实现相同的目的。正如有人已指出的，无服务器模型本质上只是已存在数十年的SaaS 业务模型的扩展。

需要注意的是，无服务器模型并非“函数”即服务（FaaS）架构，尽管二者之间存在一定关联。FaaS 本质上是无服务器架构中侧重于计算的部分，因此是无服务器的一个组成部分，代表不了整个系统。

那么为什么无服务器在现在得到了热捧？那是因为随着互联网渗透到发展中国家的速度持续提高，对计算资源的需求也随之水涨船高。例如，许多电子商务行业发展迅速的国家，根本不具备处理运行这些平台应用的计算基础架构。这就产生了租用无服务器平台的需求。

无服务器存在的问题

问题在于，无服务器模型本身就有问题。不要误会，我并不是说无服务器模型本身是不好的，或是在某些情况下无法为某些公司提供可观的价值。但是，无服务器将迅速取代传统架构这一“革命”的核心主张是永远不会发生的。

下面分别给出原因。

编程语言受限

大多数无服务器平台仅支持运行特定语言编写的应用。这严重地限制了系统的敏捷性和适应性。

诚然，大多数的无服务器平台都提供了对大部分主流编程语言的支持。AWS Lambda 和Azure Functions 还提供包装器功能，能使用未受系统支持的语言运行应用和“函数”，虽然通常会在性能上付出代价。因此对于大多数机构而言，语言上的限制在大多数情况下并没有什么影响。但是这就是问题所在。无服务器模型的一个优势就是支持以更便捷的方式运行那些非主流、不常使用的程序，只需为程序的执行时间付费。而这些非主流、不常使用的程序，常常使用一些并不常用、晦涩难懂的编程语言编写。

这导致无服务器模型的一个主要优势无法发挥。

供应商锁定

无服务器平台（或至少以目前的实现方式看）的第二个问题是，在运维层面上很少存在彼此相似的平台。在“函数”的编写、部署和管理的方式上，几乎不存在跨平台的标准。这意味着将“函数”从一个特定于供应商的平台迁移到另一个平台是非常耗时的。

迁移到无服务器的最大难处，并非那些通常只是一些代码片段的计算“函数”（译者注：在译文中统一使用“函数”表示”Function“，指相比微服务更加细小的程序单元），而是应用中与关联系统纠缠不清的对象存储、身份管理和队列等方式。应用中的“函数”是可以迁移的，但应用的其余部分却不那么容易移植。这与无服务器所承诺的廉价、敏捷的平台是完全背道而驰的。

难免有些人会争辩说，无服务器模型是新的理念，还没有时间去标准化它们的工作方式。但正如我在上文中指出的，无服务器并非什么新理念。而且容器等其他许多云原生技术已经通过开发和广泛采用基于社区的强大标准变得更具可用性。

性能

无服务器平台的计算性能难以衡量，部分原因在于提供此类服务的公司出于一些既得利益会隐藏该信息。大多数服务提供商宣称，如果无法避免的延迟问题不存在，那么在远程无服务器平台上运行”函数“可达到与内部服务器上相同的运行速度。

但一些事实证据却给出了相反的结论。如果某个“函数”之前未在特定平台上运行过，或是在一段时间内未运行，那么就需要耗费一些时间做初始化。可能是因为这些代码已经被迁移到那些不常访问的存储介质中。和性能统计一样，大多数无服务器计算厂商对此也不会公布具体的情况。

当然，该问题有多种解决方法。一种方法是使用任何一种无服务器平台所运行的云原生语言对”函数“进行优化，但这在一定程度上破坏了平台所宣称的“敏捷性”。

另一种方法是确保调度频繁运行那些对性能要求高的程序，以保持它们的“新鲜度”。当然，考虑到用户会为程序的运行时间付费，这种方法与无服务器平台更具成本效益的说法产生了矛盾。云服务提供商已经引入了一些降低冷启动的新方法，但许多提供商都需要“缩为一体”的模型，这破坏了FaaS 的初衷。

内部运行的无服务器系统会降低“冷启动”问题，但该做法本身就引入了额外成本，是仅适用于资源丰富团队的一个小众选择。

无法运行整体应用

为何无服务器架构不会很快取代传统模型？最后也可能是最关键的一个原因在于，用户通常无法在无服务器系统上运行整个应用。

或者更确切地说，虽然可以，但是这种做法并不划算。一个良好运行的单体应用或许不应变成一个连接到八个网关、四十个队列和数十个数据库实例的一系列“函数”。因此，无服务器适用于那些尚未开发的领域。几乎没有将现有应用（架构）移植过来的案例。因此虽然可迁移，但最好是从零开始。

这意味着在大多数情况下，无服务器平台将用作内部服务器的一个补充，去执行需大量计算资源的任务。这使得无服务器与容器、虚拟机这两种云原生技术存在很大差异，后两者都支持整体执行远程计算。这是从微服务过渡到无服务器的一个难点。

当然，这也不一定是个问题。在许多机构中，偶尔会使用大量计算资源，也无需采购在内部实现功能所需的硬件。无服务器的确能真正和持久地发挥优势。但是，管理部分运行在内部服务器上、部分运行在无服务器云架构上的应用运行，会给应用部署带来另一个层面上的复杂性。

“革命万岁”？

尽管存在上述问题，但我发誓我并不反对无服务器解决方案本身。开发人员应该意识到，尤其是对于首次探索无服务器模型的开发人员，这一技术并不是服务器的直接替代。欢迎访问我们提供的构建无服务器应用的技巧和资源，依此确定如何能最好地部署这类模型。

作者简介：

Bernard Brode是 Microscopic Machines 公司的产品研究员，始终保持着对人工智能、网络安全和纳米技术交融愿景的探索心态。

原文链接： Why the Serverless Revolution Has Stalled