“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

伯克利谈 Serverless:服务器的存在,是云计算的大问题

  • 2021-04-07
  • 本文字数:7241 字

    阅读完需:约 24 分钟

伯克利谈Serverless:服务器的存在,是云计算的大问题


大家好,我是 Johann Schleier-Smith,今天我非常期待向你们分享 Serverless 计算以及我关于 Serverless 对云计算未来影响的看法 —— 它的影响将非常深远。



首先,我将从一个简短的自我介绍开始,包括我的背景、我的经验以及 Serverless 计算相关的工作。然后,我将深入讲解,Serverless 计算从何而来,其中体现了哪些核心概念和理念?我将会从有点学术的角度来讲,但我真的希望你能从中学到一些东西。随后,我将讨论当前的一些研究趋势,最后是总结。



首先,简单介绍一下我自己。在相当长的时间里我都是一名企业家,我曾在硅谷的社交网络行业工作。我从 2003 年开始,就在想办法解决注册用户的使用产品的各种问题,以及在非常竞争激烈的环境中,保持高可用性,保持快速创新步伐。我曾经是 Tagged 的创始人兼 CTO。后来,我们收购了一家名为 hi5 的公司,合并成了一家公司。最后,公司被一家上市公司 Meet 集团收购。在我多年从业经历中面临如此多的挑战,让我真的很想从更根本的层面深入探究。


于是,我转向了学术领域,目前我在加州大学伯克利分校从事机器学习博士项目的研究。


在 riselib 从事研究,是一个非常棒的机会,可以和很多非常棒的人一起工作,向他们学习。



所以,我今天要讲述的内容,很大程度上受到了很多的合作伙伴的影响。我们已经发表了一些论文,我推荐大家去看看这里展示的作品,你可以读到更多的信息。有很多人对此领域做出贡献,例如 Ion Stoica、Joseph Hellerstein、Joseph Gonzalez、Rocha Popa (音译)等优秀的教员。


我想说,今天我将代表我自己的立场来分享。也就是说,我可能会说一些有争议的话题,我将会为自己的观点负责。我也要感谢 riselib 的赞助商,riselib 的研究是通过政府和企业资助实现的。



Now Serverless .

Serverless 广受关注,这张图表展示了人们对它的兴趣有多大,增长的速度有多快 —— 这是人们在 Google 上搜索 Serverless 次数的变化趋势。你可以看到,自从 AWS lambda 在 2015 年面世以来,出现了飞快的增长。当你看到这些图表时,可能你会说,这里一定发生了一些非常有趣的事情,让我更多地了解一下为什么会这样。



在 Serverless 产品方面,我想你可能有了一些了解。比如腾讯云已经提供的 FaaS 产品服务,Serverless 云函数(SCF)。这些产品允许你在云中运行代码和计算任务,而不需要考虑基础架构,也不需要考虑运维,这确实是促使人们对 Serverless 感兴趣的原因。稍后我会详细介绍这一点,但我想强调一下, Serverless 不仅仅与计算有关,还有 Serverless 存储,例如腾讯的云对象存储(COS),还有 Serverless 数据库服务,比如 TcaplusDB。



Serverless 的共性,是你使用它的方式 —— 这正是我喜欢它的地方。


你编写代码时,你可以选择任何你喜欢的编程语言。然后你将代码上传到云,接下来你会说:“云服务商,请去运行这个代码”。在这之后,一切都正常运行了。


运维方面的事情也为你安排好了。如果需要更多的底层基础设施容量,那么它将自动为你扩容,反之也会自动缩容。假如发生任何故障,也会很快得到解决。


你唯一需要关心的问题,是实际使用了多少资源,云服务商为你分配了多少计算和存储,以满足您的服务和产品 —— 而这就是你的付费方式,超级简单、实用的按用量计费方式。



这简直不要太美好 —— 所以我们认为,Serverless Land 是个神奇的地方,到处都是你能吃到的糖果,到处都是彩虹和独角兽,可真棒啊!



但是我想你一定要问的是:这么美好的东西可能是真的吗?



事实上,会存在一些捣蛋的“怪兽”,Serverless 也会遇到各种各样的挑战。这些是对 Serverless 计算的一些常见反对观点:


有一些人说,你所运行云函数它们实际上是无状态的,所以当你的程序运行结束时,数据就会被清除;还有一些人抱怨它有点贵;还有反对的观点说这可能造成效率降低,因为你正在将计算和状态分开;另一个挑战的点是,有时会被认为缺乏对 GPU 等硬件加速器的支持;还有人会说,我搞的这些应用程序,他们都无法使用 Serverless 的方式运行;还有人说,也许 Serverless 听起来很简单,但实际落地起来却很困难。


如果从学术界的角度,我可以给你们一些成果的展示,几乎所有这些反对观点描述的问题,都取得了重大进展。但仍有一个还在坚持 ... Serverless 这个名字不好。



对于这个名字有一些普遍的反对意见。

“服务器还在那里,你怎么能称它为无服务器呢?”

“另一个问题是,如果没有服务器,那有什么呢?”

这听起来不像是用词不当吗?既然如此,人们为什么还要这么命名它呢。但我要告诉你,这实际上非常重要。



还有人可能会说,为什么不给它起个别的名字?


比如就叫它云函数吧?我想说,它不仅仅是云函数;或者称之为托管服务?这概念已经有很长一段时间了;云原生?是另外一个很好的新名词,也许我们应该称之为超级自动伸缩。


随便叫什么,你可以给 serverless 想出各种各样的其他名字来。



现在我的观点是,Serverless 其实是一个很有意义的名字,最关键的点是你没有服务器。


它描述了云计算目前正在发生的最关键的事情,这一巨大的变迁即将到来。如果我们理解为什么这是一个好名字,我们就会理解趋势,也会理解云计算的发展方向。



我们开始下一节,Why Serverless?



我要带你们回到大概 2,400 年前,这是伟大的哲学家亚里士多德所在的希腊时代,哲学家们倾向于深入思考事物,一些观念在归纳总结后仍与当今社会十分相关。



让我来问你这是什么?


你可以说它是一把椅子,或一把红色椅子。如果请你稍微描述一下?你会说它是圆的,你会看到一个圆圈有四条腿,也许是用木头做的。好的,你已经告诉了我很多关于那个东西的属性。现在我可以问:关于你的描述的物体,它的本质属性是什么呢?


所以在这个问题下,我们可以说:它们的表面是平坦的,适合坐着。这就是它真正成为凳子的原因。当然它还有很多偶然属性——它是红色的、它有座椅、椅腿、它的材质等等,这些都不是本质属性。



一把凳子可能有不同的属性。我们可以看到我这里有很多例子,很多不同类型的凳子,有些有三条腿,有些只有一条腿。但它们都是凳子,它们有相同的用途和功能,但它们的工作机制各不相同。所以你可以看到每个凳子,本质属性都被保留了下来,而那些偶然属性则有所不同。



现在,请允许我再讲解得深入些 —— 我保证这些都跟计算机领域相关。


请看这是什么,这是一座桥梁。它是一座横跨溪流的桥梁,它有相当多的属性。这是架在水上的干燥路面,它连接着两岸上面铺装了原木,它有四根支撑,两端都有斜坡,中间的部分很平整。这些是用来创造桥梁的技术,你明白它的作用是什么,连接河岸两端的能力也有很多属性。



我们再看一座桥的不同案例,可能是一套不同的造桥技术,我们会发现有一套不同的属性来实现这座桥。



继续下一个案例,这个是悬挂绳子的桥梁。它不是平坦的,它有点下沉,它由岸上的四根柱子支撑着。



再看看这座桥。这个桥在中间稍高了一些,有这十根柱子连接上下导轨。这个可能是金属做的,所以它采用了不同的技术,但归根结底都是一样的,它们都提供的了桥的功能。



如果我们仔细研究每个问题,就需要研究哪些属性是本质的,哪些属性是偶然的,我们可以继续探究一下。



我们把它们都列出来,可以看到在屏幕上所有属性放在一起:哇,这是多么难懂的一团乱七八糟的东西!接下来,我们把所有偶然属性都拿走,把重点放在提供一座桥梁的本质属性上。就像你现在看到的,一切都变得简单得多。记住,这是理解 Serverless 计算的关键,这要求我们要排除大量的偶然复杂度。



云计算工作方式的实质,让我们专注于应用程序中最本质的部分——核心业务逻辑,这是每个应用中必不可少的、差异化的部分。所以你看着那台服务器,你可能会问:服务器是云计算的本质属性,还是偶然属性?



为了让大家更好的理解,我将再次倒转时光,不是回到几千年前,而是回到 1967 年。这是 IBM System 360 大型计算机,它是一台非常令人印象深刻的机器。当时为这些机器写的代码,如今仍在很多公司运行。



它是一个大型计算机,意味着是一个支持许多用户的集中式资源。在 1960 年代,这是一项巨大的进步,能够真正有效地将公司一台大型计算机的资源和时间进行共享,分配给各个团队使用。现在你看到这个大型计算机,实际上会意识到,在 20 世纪 60 年代,在这些大型计算机上正在实现的许多东西,与我们今天在云计算和 Serverless 计算中追求的价值非常相似。



Fred Brooks 是 System 360 的主要领导者之一,他领导了操作系统和许多硬件团队,后来他成为一位非常杰出的教授和图灵奖获得者。1980 年代后期,他撰写了开创性的文章,在其中他区分了计算机程序的复杂度,并且提出了与你的应用业务有关的是本质复杂度。也许业务本质复杂度是很有限的,但是计算机带来了复杂度,这就是业务功能的技术实现细节。就像那座桥,取决于我们用的是绳子、钢材还是木头,我们会有很多不同的技术实现细节。这些技术细节实际上非常重要,正是因为这些技术让事情变得可行,但它们与你应用程序的业务逻辑并没有关系,与解决方案的最终结果也无关。


在我所目睹的技术里,使用汇编语言编写程序的过程中,就有太多的偶然复杂度。而现在的高级编程语言已经变得如此之好,以至于可以使用它们做任何的事情。这样对于我们可以用计算机做什么来说,这是一次巨大的变革。


本质复杂度和偶然复杂度的理论,真的是一种伟大的见解,是我们从几千年前哲学家得到的启发,最近几十年里确实是具有非凡的意义。



为了更深入地了解这一点,再了解几种通常与 System 360 一起使用的编程语言。Fortran 用于数值计算,Cobol 用于商业应用程序,PL/1 作为一种通用的编程语言。而对于那些真正需要高性能的应用程序,需要通过 System 360 汇编语言实现。



我想,任何一个曾经使用过各种不同语言和系统的人都会很熟悉这种权衡,一方面是编程的体验,另一方面是性能和开销。



在此我想展开讲一下,给你们一个具体的例子,以便对 System 360 有更清晰的认识。这是校验信用卡号码的 Luhn 算法,一个简单但古老的算法。如果想要查看该信用卡号码是否有效,可以采用一个简单的方法 —— 实际就是一种校验和。从卡号的末尾开始偶数位都乘以 2,如果结果是大于 10 的数字,则将个位和十位相加即得到一位数字,把所有数字相加得到总和。如果可以被 10 整除,就是一张有效的信用卡。超级简单的算法,对吧?



事实上,如果我们使用像 PL/1 这样的编程语言。这代码看起来可能你们大多数人都不认识,当你看到它,可能你会说这可能是 2020 年最新最伟大的新语言,就这么简单。右读一些输入,得到该数字,颠倒它,然后对奇数位和求和,然后对一些偶数和求和,并根据需要执行判断逻辑,看看它是否被 10 整除,如果是则通过测试,否则就不通过。这个很十分简单。



现在让我们来看一下汇编语言实现。代码去掉了注释 —— 即使注释在其中,也真的很难分析。我花了一些时间来分析,了解这段程序在做什么。我会省去大部分的细节,会给你们一个高度概括的介绍。



此处从寄存器的操作开始。什么是寄存器呢?我们知道在 CPU 内部有固定数量的存储单元,这些存储单元用于基本操作、算术运算、访问内存单元、加载和存储等。如果你准备编程,必须弄清楚你要如何使用这些寄存器。这只是复杂度的一部分,你还必须在编程时考虑,如何确保你空间足够使用。这些操作与计算信用卡号码的校验和无关,这只是当你用汇编语言编程时,必须要发生的一些工作。



这是字符串长度。你会注意到,上面没有名字,没有卡号,以及诸如此类的东西。它只是一堆寄存器,你必须跟踪你的程序中交叉引用,你还必须做出决定将使用哪个寄存器来计算字符串的内存地址,并将字符串所有内容存储在那个内存地址。



反转字符串也是类似操作。



我不会再深入讨论了,这是一堆详细的指令、逻辑和判断,和你要做的事情没有任何关系。



通过这个高度概述的介绍,不难发现用汇编语言的代码要比 PL/ 1 长得多,寄存器名称也不含什么信息,直接暴露了这台机器的很多工作原理。



这是那台机器的示意图,有浮点寄存器、定点寄存器、16 位通用寄存器,需要对特定内存单元、特定存储地址进行读写操作。我并不是对汇编持完全否定的态度,汇编语言编程的好处是,你可以用很少的资源获得非常好的性能。



这是 Margaret Hamilton 的照片,还有一堆阿波罗制导计算机的汇编语言代码的打印件,我认为这真的是个很酷的东西。她是该项目的首席软件开发人员,在 1969 年编写了火箭载着宇航员导航到月球的程序,使用的技术比我们今天要原始得多。



这是一张阿波罗制导计算机的照片,它的运行频率是 2MHz,可能比你今天拥有的最慢的计算机或手机慢一千倍。不仅如此,这里还有一件非常有意思的事——资源是如此的有限!真的,这导致用汇编语言编程的人们需要详细地思考,如何去使用这 2,048 个字节的内存,这就是你能使用的全部内存,需要以非常谨慎地使用内存的每一个字节。记住,我们要去月球的时候,火箭上有一百五十种不同的装置需要去控制,而我们只需要使用这么一点点内存就可以做到。



汇编语言编程需要考虑的事情,包括如何使用每个寄存器?如何安排内存中的数据?如果我要切换程序,我该怎么做?等等。



现在我们来到 2020 年,当你想到云计算的时候,您会遇到很多类似的问题!


那么,我应该如何使用每一个服务器呢? 我需要多大的一个服务器实例?如何知道何时需要分配更多服务器?其中一个服务器是否出现故障时,我该如何应对这种情况?即便我知道需要备份我的数据,但是我应该备份多少次?如何保证数据的一致性?


所以这些都是挑战,真正的挑战,艰难的挑战,它们与你正在交付的应用程序没有任何关系。



那么汇编语言的复杂度,是如何解决的呢?解决办法其实很简单,编译器会做生成机器代码的工作。编译器是如此出色,以至基本没人再需要使用汇编语言进行编程,除非是非常特殊应用程序。我认为依赖服务器的编程,就是当今的汇编语言编程。



为了说的更加具体,我就像这样对比一下。用汇编语言编程,要处理寄存器的名称,要处理特定的内存单元和地址。当你使用高级编程语言时,这些东西就消失了对吗?你永远也看不到寄存器,编译器会完全处理它,将其隐藏起来,包括内存地址。在一些不那么高级的语言 (如 C 语言) 中你还会看到这些。但可以肯定的是,一旦你使用了像 Java 这样的语言,内存地址就完全消失了。如果谈及云服务,也会有服务器地址,我的观点是这不属于云,它将消失!



所以我的观点是,Serverless 是一个精确的命名,它表明了当今基于云编程的问题所在,暴露在编程模型中的服务器,就像暴露寄存器或特定内存单元一样有问题。


现在最关键的是将过去对我们有效控制编程复杂度的方法,应用到云服务中,将它们应用于消除服务器、固定地点、固定资源、固定地址,改变我们基于云编程的方式。




接下来,我想对目前的一些研究做一个简要的概述。我会偏向伯克利分校的视角,目前整个学术界都在进行 Serverless 研究,并且一直在加速发展。



让我们来逐一过一下已经完成的一些工作吧, 来针对性的解决这些对 Serverless 的反对观点。至于名字不好这件事,我们已经聊过了,不再多说。



第一个是无状态计算的限制。在伯克利我们开发了一个名为 cloudburst 的系统,它将高性能 K-V 存储与 FaaS 运行时集成在一起,允许数据缓存与主机放在一起,在 Serverless 的环境中实现了高性能计算。



还有其他的反对意见认为, Serverless 太贵,或效率低下。



如你所见,CloudBurst 解决了延迟,这里我们对比了一个函数调用另一个函数的场景,只是进行一系列简单的操作。我们看到与目前公共云的相比,这里的延迟大大减少了。



我们还在努力将 GPU 等硬件加速集成到 Serverless 计算中,这实际上非常有意思,因为可以想出不同的方法来做到这一点。



例如,一种选择是让每个云函数都附带一个 GPU。所以如果你有很多云函数在运行,你会得到很多的 GPU 和 CPU。



另一种选择是将计算单元进行拆分,这样你就可以有一个 GPU-only 的函数(或许也用到一点 CPU),这样在扩展该资源方面会获得更大的灵活性。你可以独立于 CPU 资源和内存资源,来扩展 GPU 资源,这也是我们一直在研究的。另外,在传输数据等方面也存在一些挑战,但这是一个非常令人兴奋的研究领域。



对 Serverless 的另一个反对意见是:人们会说,它不支持我现有的一些应用程序,比如一些遗留应用程序。



例如,直到最近还没有共享文件系统的支持,没有 FaaSFS 这样的文件系统可以与云函数一起使用。AWS 已在几个月前发布了一款产品,但与传统本地文件系统相比,在性能方面还存在一些瓶颈。



为了解决这个问题,我们构建了一个共享文件系统,称之为 FaaSFS 。提供了集成事务机制的缓存,能够确保数据非常靠近算力,可以非常快地访问,并且保持了数据的全局一致性。



最后,人们有时会有的另一种抱怨:Serverless 听起来很简单,但实践起来却很难。



我只想回到我之前提出的论点,也就是说,在过去的五六十年里,我们有大量的复杂度计算。可以看到在语言领域已经发生了很多事情,产生了巨大的变化,例如一些编译工具。对于云计算来讲,现在还为时尚早,伯克利的人们已经在此领域开展了很多基础性的工作,我非常兴奋能在我们前进的过程中与他们一起工作。




虽然对 Serverless 计算仍有不少反对声音。我不会说我今天在这里已经解决了所有这些问题,但我要说的是,这些问题正在一个接一个的被解决。学术界和人力资源行业的研究人员,都在非常积极地攻克几乎所有的障碍。所以我们对 Serverless 计算很有信心,这个梦想真的可以应用于广泛的应用程序中。我们所有人很快就能真正享受到这一点。



Serverless 计算的本质是:云计算的 Serverless 阶段,驯服了基于云编程的偶然复杂度,让您专注于本质复杂度(业务本身)—— 那些你的业务应用中真正有价值的部分。



就像一开始在那个桥的例子中,把所有其他让你分心的东西拿走,摆脱它们,然后专注于最最重要的事情。



总结一下,服务器是造成云应用程序偶然复杂度的根本原因,不接受反驳。


思考一下,只需想想一下今天我们编程模型所不存在的那些东西,寄存器名称、内存单元、以及服务器地址,这些也很快就会消失不见。要使 Serverless 应用于每一个应用场景,仍然面临着各种各样的挑战,同时研究人员正在积极地向前迈进,解决所有这些挑战。



2021-04-07 09:393350

评论 1 条评论

发布
用户头像
本质复杂度 偶然复杂度 特别有启发
2021-04-13 09:22
回复
没有更多了
发现更多内容

过早优化是万恶之源

非著名程序员

程序员 程序人生 提升认知

食堂就餐卡系统设计

John

极客大学架构师训练营

MySQL InnoDB 存储引擎 - 锁

Arthur

基于业务表 Binlog 的事件驱动设计

理帆

MySQL 事件驱动 Binlog

设计模式之单例模式和组合模式

dapaul

极客大学架构师训练营

线性表(数组、链表、队列、栈)详细总结

淡蓝色

Java 数据结构 算法 链表 线性表

架构师训练营 - 第三周学习总结

清风徐徐

面试官:我们来聊下锁吧

java金融

Java 乐观锁 悲观锁

二叉树深度优先遍历

封不羁

Java 算法 二叉树

游戏夜读 | 《老残游记》很有趣

game1night

ARTS Week5

丽子

第四周 学习总结

冯凯

辟谣:程序员不配谈恋爱?你错的可以!真相来了

码农神说

程序员 漫画 相亲

【极客大学】【架构师训练营】【第二周】依赖倒置原则和接口隔离原则

NieXY

极客大学架构师训练营

每日一题-翻转字符串里的单词

程序员老王

LeetCode

从0开始设计Flutter独立APP | 第一篇: 数据库与状态管理

渔子长

flutter 大前端 跨平台

十五年后苹果再次变心

池建强

apple 苹果 芯片 wwdc

好奇心, 优秀软件工程师的内核品质

亚伦碎语

读书感悟 随笔杂谈

【在云端 002】云时代,何以安放我的个人数据

Bora.Don

云计算 云存储

【极客大学】【架构师训练营】【第二周】总结:设计原则

NieXY

极客大学架构师训练营

就餐卡系统架构设计文档

牛珈羽

极客大学架构师训练营

为什么哈希表可以管理亿级数据?

八两

php redis hash rehash

RabbitMQ跨机房迁移数据零丢失

心平气和

RabbitMQ 消息队列

循序渐进的中台研发

理帆

中台 业务中台

区块链目前实际的应用场景汇总

CECBC

区块链技术 去中心化 应用场景

Redis系列(三):缓存过期该如何剔除?RDB和AOF又是什么?

z小赵

Java redis 高并发 高并发系统设计

ARTS week3

姜海天

centos7 操作

InfoQ_1c4a1f813eb1

工作那么久,才知道的 SOLID 设计原则

闻人

架构师 极客大学架构师训练营

设计原则与设计模式

dapaul

极客大学架构师训练营

查找算法系列文(一)一文入门二叉树

淡蓝色

Java 数据结构 算法 二叉树

伯克利谈Serverless:服务器的存在,是云计算的大问题_语言 & 开发_TencentServerless_InfoQ精选文章