【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

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

  • 2020-10-20
  • 本文字数:3708 字

    阅读完需:约 12 分钟

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

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


虽然许多人认为,无服务器技术是一个新的概念。但是,如果追根溯源,那就是 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/


2020-10-20 14:426837

评论 2 条评论

发布
用户头像
最近阿里云也是这么搞的,及其糟糕。
2020-10-27 15:55
回复
用户头像
看不懂 看不起 追不上 老家伙们的悲哀
2020-10-26 15:30
回复
没有更多了
发现更多内容

值得关注的五个先进代码补全服务

这我可不懂

人工智能 代码补全

一键登录教你如何解决APP通讯诈骗问题

MobTech袤博科技

App

你了解Vue3组合式API吗?

OpenTiny社区

Vue 前端框架 开源组件库

香港VPS大揭秘:轻松打造超高流量网站

一只扑棱蛾子

VPS 香港VPS

一文帮你全面认识方天视窗引擎

openEuler

Linux 开源 操作系统 openEuler 视窗引擎

我的 Obsidian 笔记跨设备同步方案

专注前端开发

工具 笔记 Obsidian

git撤销某一次commit提交

树上有只程序猿

git

【福利活动】深度体验OpenHarmony对接华为云IoT

OpenHarmony开发者

OpenHarmony

如果你在选型低代码平台,可以从这5个角度去分析抉择

互联网工科生

源码 低代码 系统集成 私有化部署

当流计算邂逅数据湖:Paimon 的前生今世

Apache Flink

大数据 flink 实时计算

给世界一个更好的选择,“龙蜥+超级探访”首期嘉宾预告片震撼来袭!

OpenAnolis小助手

开源 操作系统 龙蜥社区 统信软件 超级探访

灵动AI推出业内首个工业级“AI商品图”生成工具 并获小米联合创始人黎万强天使投资

TE智库

鸿煦科技刘敏:小程序云开发降本增效实践之路

TRaaS

小程序 支付宝 开发

Java构建树结构的公共方法

高端章鱼哥

java基础 树结构

WIFI7 QCN9274 -WIFI6E QCN9074 chip difference MU-MIMO+TWT technology

wifi6-yiyi

wifi6 WiFi7

九州八荒录H5游戏详细图文架设教程

echeverra

游戏开发

门槛一降再降,易用性大幅提升!Milvus 2.2.12 持续升级中

Zilliz

Milvus Zilliz 向量数据库

实时数仓:Iceberg

腾讯云大数据

数据仓库

设计原则 — KISS & YAGNI

Lemoon Can

设计原则 KISS YAGNI

程序员必读十大电子书

六月的雨在InfoQ

电子书 Java工程师成神之路

金山云与平凯星辰达成全面战略合作 技术创新模式助力企业数字化转型

PingCAP

金山云 数字化 TiDB pingCAP 平凯星辰

软件测试/测试开发丨Python 装饰器 学习笔记

测试人

Python 程序员 软件测试 装饰器 测试开发

腾讯云 Cloud Studio 实战训练营活动招募中

CODING DevOps

活动 cloudstudio 云端 IDE

【从零开始学爬虫】采集全国各行业经销商网点数据

前嗅大数据

大数据 爬虫 数据采集 爬虫教程 爬虫入门

2 种方式查找极狐GitLab 容器镜像 Tag,几分钟快速构建私有化部署实例

极狐GitLab

DevOps gitlab Helm 容器镜像 Omnibus package

Java基础!Java反射机制!!

java易二三

Java 编程 互联网 计算机

Cloud Kernel SIG 月度动态:支持龙芯和申威架构,合入两个内存新特性

OpenAnolis小助手

开源 架构 内存 内核 龙蜥sig

四步法建立企业内部人才市场

用友BIP

人力资源

@开源技术爱好者,龙蜥邀您一起玩转系统运维 MeetUp

OpenAnolis小助手

Linux 系统运维 ebpf Meetup 龙蜥社区

提高代码质量!详解在Gradle项目中使用PMD的正确姿势

树上有只程序猿

Gradle

QQ开展外挂专项整治,守护用户社交环境安全

Geek_2d6073

无服务器已死?这项技术为什么变得人人嫌弃_云原生_Bernard Brode_InfoQ精选文章