快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用 了解详情
写点什么

伯克利谈 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:393480

评论 1 条评论

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

week12学习总结

burner

基于Prometheus的微服务应用监控

易观大数据

1.Flink检查点算法-15

小知识点

scala 大数据 flink

Zeppelin SDK :Flink 平台建设的基石

Apache Flink

flink

迭代技术方案设计文档规范

程序员架构进阶

技术方案

第 0 期架构师训练营第 8 周作业2-总结

fujin

分布式QoS算法解析

焱融科技

分布式 算法 焱融科技 分布式文件存储 QoS

滴滴ElasticSearch千万级TPS写入性能翻倍技术剖析

滴滴技术

大数据 elasticsearch 滴滴技术

第 0 期架构师训练营第 8 周作业 1

fujin

滴滴Ceph分布式存储系统优化之锁优化

滴滴技术

云计算 分布式存储 Ceph 滴滴技术

浅析LR.Net工作流引擎

Learun

.net 敏捷开发 工作流

滴滴推理引擎IFX:千万规模设备下AI部署实践

滴滴技术

人工智能 学习 AI 滴滴技术 IFX

可编程网卡芯片在滴滴云网络的应用实践

滴滴技术

云计算 芯片 滴滴技术

滴滴数据通道服务演进之路

滴滴技术

大数据 滴滴技术 数据服务通道

c语言函数指针之回调函数

C语言与CPP编程

C语言 回调函数 函数 函数指针

自定义线程池来实现文档转码

架构师修行之路

区块链支付系统源码开发,USDT承兑支付平台

13530558032

隐私计算会成为“金融”向“数科”转型的一剂猛药?

hellompc

突破传统 区块链如何实现病历永存

CECBC

区块链 电子病历 信息共享

拥抱K8S系列-03-服务器部署应用和docker部署应用区别(MySQL篇)

张无忌

MySQL Docker 运维

GPU虚拟机创建时间深度优化

滴滴技术

云计算 虚拟化 滴滴技术

实时数仓在滴滴的实践和落地

滴滴技术

大数据 滴滴技术 数据通道服务

物联网的银河,华为的桨,少年的歌

脑极体

Redis做消息队列全攻略

架构师修行之路

redis MQ 消息队列

【Spring注解驱动开发】AOP核心类源码解析,这是最全的一篇了!!

冰河

spring aop ioc

数字货币钱包系统定制开发,区块链钱包源码

13530558032

区块链技术成为金融业务应用热点

CECBC

区块链 人工智能 金融

滴滴云平台事业群——就是稳!

滴滴技术

招聘 滴滴技术 滴滴云平台事业群分享月

合约跟单系统开发,数字货币合约跟单软件搭建

13530558032

滴滴数据仓库指标体系建设实践

滴滴技术

大数据 数据仓库 滴滴技术

滴滴七层接入平台实践和探索

滴滴技术

微服务 运维 滴滴技术 七层接入

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