写点什么

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

  • 2020-10-24
  • 本文字数:3387 字

    阅读完需:约 11 分钟

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


2020-10-24 11:006626

评论 1 条评论

发布
用户头像
这类文章有话题性,但水平不高。:-)

1. Serverless 或者 FaaS != AWS Lambda。因为 AWS 的影响力太大,开发者会不自觉的把 AWS Lambda 等价于 FaaS。这篇文章举出的缺点,基本上都是 AWS Lambda 的缺点。但业界阿里云、Azure 等很多厂商的 FaaS 和 AWS Lambda 的产品能力各不相同。

2. 作者提到了 Serverless 的缺点,我们逐一来看。

2a. 编程语言受限。除了 AWS Lambda 外,所有主流的 Serverless 计算产品都支持容器镜像,所以多语言的门槛上,Serverless 不应该和容器有差异。

2b. 供应商锁定。这是个问题,但是作者举的原因有部分是不恰当的。文中举的一个理由是函数会关联使用很多其他的服务,比如对象存储,权限管理等等,导致应用迁移困难。这个不是 Serverless 的问题,任何 VM 或者容器的应用,使用了对象存储或者权限管理,都会有这个问题。Serverless vendor lockin 主要体现在三点:1)整个 Serverless 工具链是碎片化、非标的,在开发和运维层面,和用户习惯的工具体验完全割裂。这是过去几年 Serverless 做得最差,最阻碍用户采用的地方。和容器的工具生态融合是 Serverless 一定要做的事情,否则没有前途。2)没有统一的事件触发标准。因此事件驱动架构的应用迁移成本很高。我们也看到阿里云的 event bridge 已经支持了 cloud event 标准,跨云厂商的事件互联互通未来可期。

2c. 性能。文章给出的主要例子是冷启动,但阿里云函数计算和 AWS Lambda 都支持了预留实例,彻底解决了冷启动的问题。除了冷启动,Serverless 架构的性能方面的挑战还在于底层计算架构的不透明,提高了用户优化性能的难度。这需要大力加强可观测性。

2d. 无法运行整体应用。实际上,函数计算非常适合单体应用。今天迁移单体应用最麻烦的地方在于:a)当前 FaaS 产品限制太多,代码包有限制,机型有限制,磁盘可写权限有限制。现在很多函数计算的产品已经逐渐放开限制了,再加上工具链的完善,单体应用的迁移不是问题。微服务的迁移会比较麻烦,主要是和已有框架的兼容,这个需要时间。

另外,我觉得影响 Serverless 流行还有一个非常重要的因素,但这篇文章并未提到,那就是可观测性。当前 Serverless 产品最被诟病的是太黑盒。可观测性是 Serverless 要重点解决的问题。我们能看到各个 Serverless 产品在大力加强可观测性,比如 AWS Lambda Insight。


展开
2020-11-12 23:31
回复
没有更多了
发现更多内容

子网划分不会?瑞哥带你深入理解IP地址,手把手教你子网划分!

wljslmz

网络技术 6月月更 子网划分

在线文档协作工具,是提高工作效率的第一步

小炮

深度剖析「圈组」关系系统设计 | 「圈组」技术系列文章

网易云信

音视频 IM Discord

Linux测试端口的连通性

龙空白白

java培训自定义 ThreadPoolExecutor 线程池

@零度

jdk JAVA开发

Vim编辑器以及linux常用命令

龙空白白

Linux vim教程

怎样简洁明了地说清楚产品需求?

LigaAI

高效工作 产品经理 需求 产品设计与思考

百度工程师教你玩转设计模式(单例模式)

百度Geek说

设计模式

中台:数据中台、业务中台、技术中台、应用中台、AI中台……

WorkPlus

java中synchronized关键字

龙空白白

Java Concurrency

股票获取最大利润

龙空白白

数据结构与算法

Fortex方达发布电子交易生态体系 与客户共享共赢

股市老人

H.265编码原理入门

百度Geek说

视频编码

MySQL基础

龙空白白

MySQL 数据库

最大和的连续子数组

龙空白白

数据结构与算法

Django 基础教程

海拥(haiyong.site)

Python django 6月月更

硬核剧透!11个议题、14位大咖,龙蜥社区走进 Intel MeetUp 议程公布!

OpenAnolis小助手

技术分享 intel Meetup 龙蜥社区 线上直播

Meetup回顾|DevOps&MLOps如何在企业中解决机器学习困境?

星策开源社区

开源 DevOps 算法 OpenMLDB MLOps

NFT链游GameFi系统开发,元宇宙游戏搭建

薇電13242772558

NFT 元宇宙 链游

为你推荐一款高效的IO组件——okio

HarmonyOS开发者

HarmonyOS

【高并发】关于乐观锁和悲观锁,蚂蚁金服面试官问了我这几个问题!!

冰河

并发编程 多线程 高并发 异步编程 6月月更

Java中的static关键字

龙空白白

mixin-- 混入

CRMEB

MySQL的体系结构

龙空白白

MySQL 数据库

多线程实现的方式

龙空白白

多线程

二分查找有序数组中的特定值

龙空白白

数据结构与算法

数组目标值target两个整数,并返回它们的数组下标

龙空白白

数据结构与算法

开源字节设计思想

源字节1号

软件开发

数组判断任意出现的重复值

龙空白白

数据结构与算法

【LeetCode】替换数组中的元素Java题解

Albert

LeetCode 6月月更

对接上百个第三方 API 后的思考与沉淀

LA

经验总结 Java EE 经验分享、

Serverless“革命”为什么已停滞不前?_软件工程_Bernard Brode_InfoQ精选文章