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

作者 | Bernard Brode校对 | 盖磊、Tina策画 | 星毛无伺服器民主革命为何已无以为继？

尽管在很多人看来，无伺服器控制技术是一个捷伊基本概念，但其根本原因可以追溯到 2006 年 Zimki PaaS 和 Google App Engine 对无伺服器构架的探索。近一两年，很多人预测无伺服器排序将迎来新排序时代的飞速发展，让应用领域无须作业控制系统就能继续执行。尽管有人说这种构架将会解决在扩展性上存有的许多难题，但历史事实大相径庭。因为无伺服器数学模型仅在某一情景下发挥功用，但在被更广为选用的道路上仍然存有诸多难题。

伺服器已死，伺服器长存！为无伺服器民主革命Tiruchirappalli的声音正四起。如果快速往后一两年内的很多沙托萨兰县，很容易得出说现代伺服器数学模型已失灵，而且在未来一两年内无伺服器构架将统治一切。

但业内人士都知道，也正如我们在“无伺服器排序现况”中所指出的，历史事实大相径庭。尽管有很多文章对无伺服器民主革命的缺点感慨万千，但这些缺点仍然尚未破冰。历史事实上，最近有研究表明这一民主革命可能已经无以为继（https://www.infoq.com/news/2020/06/oreilly-cloud-report/），数量惊人的受调查者表示对无伺服器实例并不屑一顾。

须要承认，无伺服器数学模型的部分允诺已经实现，但也只是少部分而已。尽管在很多具有明确表述的某一情景少脉，无伺服器数学模型的确展现出了巨大的实用性，但这类控制系统看上去缺乏精准度和稳定性，妨碍了它们的广为选用。

对于首度接触无伺服器基本概念的人而言，简单的解释就是：无伺服器排序指应用领域或应用领域的某一部分在一般来说是远距代销的继续执行环境中按需运行的构架。也就是说，无伺服器控制系统也可内部代销。过去一两年中，构建有弹性的无伺服器控制系统一直是控制用户端和 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/

https://news.ycombinator.com/item?id=24758772

点击下方图片即可阅读

面试造核弹：细数那些有毒的开发岗位描述