无服务器革命为什么停滞不前？

虽然许多人认为，无服务器技术是一个新的概念。但是，如果追根溯源，那就是 2006 年 Zimki PaaS 和 Google App Engine 对无服务器框架的探索。

近几年，一些人预测无服务器计算将迎来蓬勃发展，让应用无需操作系统就能执行。虽然有人说这种框架将会解决在可扩展性上存在的许多问题，但事实并非如此。因为无服务器模型仅在特定场景下发挥效用，但在被更广泛采用的道路上依然存在诸多问题。

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

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

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

必须承认，无服务器模型的部分承诺已经实现，但也只是一小部分而已。尽管在一些具有明确定义的特定场景中，无服务器模型确实体现了巨大的实用性，但此类系统看上去缺乏敏捷性和灵活性，且阻碍了它们的广泛采用。

无服务器计算的承诺

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

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

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

无服务器是个新理念吗？

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

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

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

那么，为什么无服务器在现在受到热捧？

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

无服务器存在的问题

问题在于，无服务器模型本身就有问题。不要误会，我并不是说无服务器模型本身是不好的，或是在某些情况下无法为某些公司提供可观的价值。

但是，无服务器将迅速取代传统架构这一“革命”的核心主张是永远不会发生的。

编程语言受限

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

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

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

供应商锁定

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

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

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

性能

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

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

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

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

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

无法运行整体应用

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

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

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

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

无服务器的问题引来大量吐槽

原本无服务器是一种大家希望的新技术，但是很少有人去谈它的不利之处。

Bernard Brode 总结了上述无服务器所存在的问题之后，马上在 Hacker News 引来了好几百条互动，其中有很多人表示对当前的无服务技术“爱不起来”…

有人举例说自己刚接手了一个无服务器项目，但是”我们不能在本地运行它，因为十分之七的代码无法在模拟器中运行。内存限制错误对于我们来说是完全不透明的，我们无法单步执行并观察中断结果。只能通过日志来分析问题。而且费用太高、太疯狂了。所以现实就是：你如果使用了无服务器，就意味着你无法控制代码和所发生的事情。“

另一位程序员也说道自己对无服务技术并不买账：“我曾参加了一个 webdev 大会，这场会议最终成了炒作无服务器技术的现场。无服务器的行业专家出于利益原因上台演讲，但却告诉我们他们无法现场调试或运行代码。他们为我们展示了非常简单的用例，然后花了一个小时来解释如何进行非 ACID 事务处理。而且，你只能使用 3-5 种语言，并且使用的每个 import 语句都有与其对应的金额。”

他强调说，“更重要的是，你开发中所有的这些技能都与亚马逊或其他巨头相关。你编写的所有代码均受其约束。你遇到的任何问题都取决于他们的支持。那么我们应该赌上数百或数千个工时吗？“

还有不少人认为，虽然正如 Bernard Brode 所指出的，在某些情况下，无服务器架构可能是一个好的设计范例，但“这个技术还比较早期，还远不够成熟“，也不能成为服务器的直接替代。

原文链接：

https://www.infoq.com/articles/serverless-stalled/

创作场景

无服务器已死？这项技术为什么变得人人嫌弃