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

作者:

发布于: 2021-1-4

归档于:

标签:Serverlessmeetup

受腾讯云 Serverless 团队之邀,Johann Schleier-Smith 在 Techo 开发者大会 Serverless 分论坛发表了主题演讲,演讲中 Johann 从加州大学伯克利分校的视角,对 Serverless 的本质进行了解读,并带来了计算机学术界对于 Serverless 研究的最新前沿成果。 Johann Schleier-Smith 是来自加州大学伯克利分校计算机博士,云计算领域重要论文 《Cloud Programming Simplified: A Berkeley View on Serverless Computing》的主要作者。

本文内容整理自 Johann Schleier-Smith 的演讲实录,由腾讯云 Serverless 团队进行翻译、校对和整理。下面就让我们一起再次回顾一下Johann的精彩演讲内容。

原作者:Johann Schleier-Smith
翻译&校对:王俊杰、刘传

大家好,我是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 应用于每一个应用场景,仍然面临着各种各样的挑战,同时研究人员正在积极地向前迈进,解决所有这些挑战。

感谢大家的聆听,非常感谢腾讯云邀请我在这里演讲。祝你度过愉快的一天,并享受接下来的 Techo 会议环节。


欢迎访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!