译者言：

作为了解一个技术最好的方式之一就是对相关论文进行阅读，比如spark论文，kafka论文，对自己的提升也是非常巨大的，由于一句话中经常涉及巨大的信息量，所以将论文彻底翻译为中文，仔细理解阅读是非常必要的，几年前我曾经读过spark论文的英文版，泛泛而看，再加上后续并没有长期应用，其实已经忘记的差不多了。毕竟自己英文也没那么好，如果总看英文版的长篇大论，其实并不是高效的学习方式，倒不如花几天时间进行论文翻译加深理解。最后也附了自己的批注希望帮助阅读者理解。
我在19年翻译了这篇文章，今天分享希望能够促进大家对serverless的理解

原文https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
Copyright © 2019, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission.

1.介绍

2009年，为了帮助解释云计算的好处，“伯克利对云计算的看法”，阐述了6个潜力优势：

1. 无限的计算资源按需使用的出现

2. 消除了云用户一线的承诺

3. 根据需要短期支付计算资源使用费用的能力。

4. 由于许多非常大的数据中心而显著降低成本的规模经济。

5. 通过资源虚拟化，简化运维，增加利用率

6. 通过复用来自不同组织的工作负载，获得更高的硬件利用率

在过去十年中这些优势被大范围的意识到，但是云用户继续承受 复杂操作和许多工作负载的负担仍然不能从有效的多路复用中受益。这些不足主要与未能实现最后两个潜在优势有关

云计算免除了用户的物理基础设施管理，但留给他们的是要管理的虚拟资源。

复用很适合应用在批量处理的工作负载场景[t1] ，比如map reduce，高性能计算，这种可以充分利用被分配的资源的实例的场景。但是在有状态服务中，工作的并不好，比如移植企业级软件，比如数据库到云上运行[t2] 。

2009年，在云计算虚拟化方法中有两个相互竞争的方法，如论文中所述：

亚马逊EC2是这一系列产品中的一个，ec2实例更像是物理硬件，用户可以几乎操作从内核向上的软件的全栈。而另一个极端的系列是特定领域应用的平台，比如GAE。强制在无状态计算层和有状态存储层间，进行干净的分离的应用结构。app engine的令人印象深刻的自动扩展和高可用性机制。。。依赖于这种限制

市场最终拥抱了亚马逊的低层级的虚拟机方法，去上云，于是google，微软等其他云厂商也提供了类似的接口。我们相信低层级的虚拟机的成功的主要原因是，早期云计算用户想要完全重建和他们本地计算一样的云环境来简化移植工作负载的工作量。那是实际的需求，足够的明智，比起单独为云写新程序优先级更高，尤其是在云有多成功还不明确的时候。

这个抉择的缺点是，开发者不得不自己管理虚拟机，基本上通过成为系统管理员或者和系统管理员一起配合，来完成环境安装。表1列举操作云环境必须管理的问题。这一长串低层级虚拟机管理的责任激发了一些有着简单应用的客户寻求新应用程序上云的更容易的路径。比如，假设

1. 为可用性做到冗余，这样一台机器的故障不会导致服务中断。

2. 在发生灾难时保留服务的冗余拷贝的地理分布

3. 通过负载均衡，请求路由高效利用资源

4. 根据负载变化自动伸缩系统

5. 监控服务确保他们一直健康地运作

6. 记录日志用于debug和性能调优

7. 系统升级，包括安全补丁

8. 在新实例可用时迁移到新实例。

表1：为云用户建立环境需要解决的八个问题。一些问题需要采取许多步骤。比如，自动伸缩需要决定伸缩所需；选择服务器的大小和类型，申请服务器，等待他们上线，在之上配置应用，确保没有错误发生，使用监控工具监控他们，然后发送请求测试他们。

一个应用想要从手机发送图片到云端，云端应该先创建图片缩略图，把他们放到网站，完成这些任务的代码可能有几百行java script代码，这些开发量比起准备好用来运行它的服务器的开发量，是可以忽略不计的。

意识到这些需求使得亚马逊推出了一种新的选择，叫AWS Lambda。Lambda提供云函数，为serverless计算吸引了很多的关注。尽管无服务器计算可以说是一种矛盾的说法–你仍然在使用服务器进行计算–因为它推崇云用户只需编写代码并将所有服务器配置和管理任务留给云提供商。云函数被包装为FaaS提供给用户，代表着serverless计算的核心，云平台也提供专门的serverless框架满足特比定的应用需求作为BaaS提供。简单来说Serverless计算=FaaS+BaaS

在我们的定义中，要认为服务是无服务器的，它必须自动地伸缩无需显式地进行配置，并根据使用情况计费。在剩下的时间里 本文主要研究云函数的产生、演变和未来。云函数在当今无服务器计算中是一种泛用的元素，并引领着走向简化和面向云的泛用编程模型。

接下来，我们定义无服务器计算，就像伯克利对云计算的看法这篇论文一样，接着，我们列出如果无服务器计算要兑现他的承诺，所要解决的挑战和研究机遇。我们不确定哪种解决方案会胜利，我们相信所有的问题最终都会被解决，使得无服务器成为云计算的的门面。

2.无服务器计算的诞生

在任何serverless平台，用户只需要用高级语言编写云函数。选择一个触发函数运行的触发器–比如加载图片到云存储或增加缩略图到数据库–让serverless平台处理其他的所有事：实例选择，伸缩，部署，容错，监控，日志，安全补丁等等。表2总结了无服务器和传统计算方法的不同。在论文中我们称传统的为serverful云计算。注意到上述两种方法代表了基于函数的／以服务器为中心的计算平台的终点，他们都使用容器编排框架，如Kubernetes作为中间层

角色	特征	Aws serverless	Aws serverful
开发者	程序运行	用户选择的事件	持续地运行，直到明确指出需要停止
编程语言	Js，python，java，go，c#等	任意
程序状态	持久化到存储中（无状态）	任意（无状态或有状态）
最大内存	0.125到3g	0.5-1952g
本地存储	0.5g	0-3600g
最大运行时间	900s	无
最小计费单元	0.1s	60s
每个计费单元的价格	0.0000002美元	0.0000867-0.408美元
操作系统和库	云厂商选择	用户选择
系统管理	服务实例	云提供商选择	用户选择
伸缩	云提供商选择	用户选择
部署	云提供商职责	用户职责
容错	云提供商职责	用户职责
监控	云提供商职责	用户职责
日志	云提供商职责	用户职责

表2：以开发者和系统管理员2个大类分别列举，serverless和虚拟机的特征。lambda和按需ec2的规格和价格

图1，展示serverless如何简化应用部署，使得云资源更容易被使用。在云的上下文中，serverful计算就像是编程语言中的汇编语言，serverless计算像是python这样的高级别语言。汇编程序员计算简单的公式，比如c=a+b，得选择1个或多个寄存器使用，加载值到寄存器中，然后计算公式，然后再存储结果。这就好比使用serverful计算的几个步骤，先配置资源，确定可使用的资源，然后在资源中加载代码和数据，然后开始计算，把结果返回或者存储起来，最终将资源释放。Serveless计算的目标和机会是让云编程者像使用高级语言那样受益。其他的一些高级语言特性也可以天然的对应到serverless计算中。自动化的内存管理解放了开发者，不需要在管理内存资源，serverless computing解放了开发者，不必再管理服务器资源。

准确地说，serverful和serverless计算有3个关键的区别：

1. 计算存储解耦。存储和计算分别伸缩，独立配置和计算。存储由独立的云服务提供，计算则是无状态的。

2. 执行代码而无需管理资源分配。不用请求资源，用户提供代码片段，云负责自动配置资源并执行代码。

3. 按使用的资源支付而不是按分配的资源支付。按照执行来计费，比如执行时间，而不是基础云平台，比如被分配的vm的规格。

通过这些区别，接下来我们解释为何serveless不同于一些相似的解决方案，包括以前的和现在的。

图1：serverless的架构，serverless层在应用层和基础云平台之间，简化云编程。云函数（比如FaaS）提供通用计算并且由专门的BaaS补足生态系统，比如对象存储，数据库，消息。具体地，一个在AWS上的serverless应用可能会使用lambda，同时使用S3（对象存储）和dynamoDB（kv数据库）。一个在google上运行的serverless应用则使用cloud function，同时使用cloud firestore（移动应用后台数据库），cloud Pub/Sub（消息）。Serverless还有大数据的服务，比如AWS Athena和google BigQuery（big data query），google cloud DataFlow和AWS Glue（big data transform）。下边的基础云平台包括VM，VPC，块存储，IAM，还有计费，监控

2.1 Serverless的语境场景

要使severless计算成为可能需要怎样的技术突破？有些人认为无服务器计算仅仅是对先前产品的重新命名，可能就是个泛用PaaS平台比如heroku，Firebase或者Parse。有些人指出90年代提供的共享web托管环境提供的和现在serverless计算提供的差不多。比如这些方案都有无状态的编程模型，用于多租，弹性响应请求，标准的函数调用API，通用的网关接口（CGI）等高层级，甚至允许高级别语言编写的源代码直接进行部署，比如PHP,Perl。Google原先的App Engine几年前在serverless流行之前就被市场拒绝了，它也允许开发者部署代码，将大部分其他操作丢给云提供商。我们相信serverless计算相对PaaS和其他模型有着显著的创新。

如今的云函数severless在以下几个重要方面区别于他的前身们：更好的伸缩，强隔离性，平台灵活性，服务生态系统支持。在这些因素中，AWS Lambda提供的自动伸缩与以前的方案完全背道而驰。不同于serverful的自动伸缩技术，它更准确的跟踪工作负载。当需要时能快速的响应伸缩，没有需求时甚至可以缩到0资源，0开销。它以更细粒度的方式产生成本。提供最小的计费，每增加100ms收一次费，而其他的自动甚多服务都是按照小时收费。最关键的不同，用户只需要为执行代码的时间支付开销。而不是所有它为程序预留的资源。这种区别确保了云提供商在自动缩放时获得利益同时承担风险[t3] ，也因此他们提供激励措施[t4] ，以确保高效的资源分配。

Severless计算依赖强大的性能和安全隔离使多租户，硬件共享成为可能。类VM的隔离是目前标准云函数的多租硬件共享方案，但由于VM的配置时间需要会长达数秒，serverless提供商使用复杂的技术来加速创建函数执行环境。一种方法反映在AWS Lambda, 它维护一个VM实例warm pool，需要时分配给租户，一个active pool用来运行函数并服务后续的调用。资源生命周期管理和多租装箱打包需要达到一个高利用率，这是severless计算成功的关键技术。我们认识到几个最近的proposal目标都是减少多租隔离引起的开销，他们通过容器，unikernal，library OSes或者language VMs。比如google宣布app engine，cloud functions，cloud ML engine采用gvisor。Amazon发布Firecracker VMs用于lambda和 fargate。CloudFlare workers serverless平台，在使用浏览器沙盒技术的javascript云函数之间提供多租隔离

几个其他的区别帮助serverless成功。通过允许用户带入自己的库，serverless计算相对PaaS服务能够帮助更广泛的应用，后者只能支持特定的使用场景。Serverless计算跑在现代化数据中心中，比起老的web托管环境有着更大的规模。

如第1节所述，cloud function（即FaaS）使serverless模式变得流行。必须认识到他们的成功部分归功于BaaS的产品，自公有云开始以来就一直存在服务，比如AWS S3。在我们看来，这些服务都是领域相关，高优化度的serverless计算的实现。云函数表示serverless计算的通用形式。通过对比几个服务的编程接口和成本模型，我们把这些看法总结在了表3

服务	编程接口	消费模型
Cloud Functions	任意代码	函数执行时间
BigQuery/Athena	类Sql查询	查询到的数据数量
DynamoDB	Puts() and gets()	每个get put操作以及存储
SQS	Enqueque/Dequeue 事件	API调用

表3： serverless计算服务与他们相应的编程接口和消费模型。注意上述的bigquery，athena，cloud functions，用户需要分别地为他们消耗的存储再付钱（比如google cloud storage，AWS S3或者Azure Blob Storage）。

一种用于部署微服务的容器编排技术。不像serverless计算，k8s是一种简化Serverful计算的技术。得益于google内部多年的使用和开发，它获得了大量系统快速的采用，k8s提供短生存周期的计算环境，就像serverless计算那样，且有着更少的限制，比如，在硬件资源，执行时间，网络通信方面。它还可以以极小的适配，部署原本部署在公有云的应用。而serverless计算引入了规范转变，它完全卸下了操作类的职责，并转嫁给了提供商，细粒度[t5] 的多租复用成为可能。K8s托管服务，比如GKE，EKS提供中间层：他们卸下了管理k8s的工作，并使开发者可以灵活的配置任意的容器。K8s和serverless计算的关键不同是计费模型。前者按保留资源收费，后者按功能执行持续时间收费。

K8s还完美匹配了混合应用，部分跑在本地硬件，部分跑在云上。我们的看法是这种混合应用在向云过渡中是有道理的。然而长期来看，我们相信云规模上升后的经济成本、更快的网络带宽、增长的云服务和通过serverless计算简化云管理将降低这种混合应用的重要性。

边缘计算在后PC时代是云计算的好伙伴，我们本篇专注在serverless计算如何在数据中心中转变编程习惯，有趣的潜在趋势是这也会影响到边缘。几个CDN提供商使用户能在最接近他们的设施里执行他们的函数，不论用户在哪，AWS IoT greengrass甚至在边缘设备集成了serverless执行

既然我们已经定义并决定了serverless计算的语境场景，让我们看看为什么它对云提供商，用户，研究者那么有吸引力

2.2 Serverless计算的吸引力

对于提供商来说，serverless通过开发简化吸引新的客户，帮助现有客户更多的使用云资源（译者： BaaS）提升了商业增长。例如最近的调查发现，24%的serverless用户都是云计算新用户，30%现有的Serverful客户也使用Serverless计算。另外短运行时间、小内存占用和无状态天然改进了复用，通过更容易的使提供商找到不在使用中的资源并执行这些任务。提供商也可以利用不太受欢迎的计算节点—实例类型完全由提供商决定—比如旧的服务器也许已经对serverful用户没什么吸引力了。这些都增加了现有资源的收入。

百分比	场景
32	Web和API
21	数据处理，比如ETL（抽取，转换，加载）
17	集成三方应用
16	内部工具
8	聊天机器人 比如Alex Skills（Alexa AI助手的SDK）
6	IoT

表4：serverless计算的使用场景受欢迎程度，2018年调查

客户的收益是编程生产力提升，同时在许多应用场景都可以节省成本，这是底层服务器利用率更高的结果。即便serverless使客户更高效了，然而杰文斯悖论[t6] 说的是高效的使用只会增加使用者和需求量，最终扩大使用量而不是缩减。

Serverless 提升了云部署层级从x86机器代码到高级编程语言—99%的云计算机使用x86指令集，使得架构改革。如果ARM和RISC-V提供更好的性价比，Serverless计算可以很容易的切换指令集。云提供商还能去研究面向语言的优化和领域相关的特定架构[t7] 来加速某种语言编写的程序的执行速度，比如python。

用户喜欢Severless，因为能够在不了解云基础设施的情况下进行函数部署，专家节省了部署的时间，集中精力在应用独有的问题上。既然函数只在执行时计费，且是细粒度的计费，那么Serverless用户可以节省金钱，这意味着他们只付他们使用的东西，而不是他们保留的东西，表格4展示了目前欢迎度高的serverless使用场景。

研究者都被吸引到了serverless计算，尤其是在云函数方面，因为它是一种新的通用计算抽象，很可能成为云计算的未来，因为还有很多加速性能，克服限制的可能性。

3.如今Serverless计算平台的限制

云函数已经成功应用到多种工作负载，包括API服务，事件流处理，特定ETL（表3）。

为了看看是什么阻碍了他应用于一般的工作负载，我们尝试创建我们感兴趣的应用的serverless版本，并研究其他人发布的样例。它们并不代表当前无服务器计算生态系统之外的其他信息技术；它们只是一些简单的例子，用来揭示可能会阻碍许多其他应用的serverless版本发展的共通弱点。

在本章中，我们展示5个研究项目的概览，并讨论阻碍serverless平台实现最先进的性能的障碍，比如,匹配serverful部署下的工作负载的性能。我们特别关注使用通用云函数的方法，而不是依赖于其他特定serverless应用（BaaS）。然而在我们最后的例子中，SQLLite，我们识别一个use case映射到FaaS后非常糟糕，我们得出结论，数据库和严重依赖状态的应用还是适合作为BaaS提供，一个附件在论文最后，有着每个应用更详细的信息。

有趣的是，即使是折衷[t8] 的应用程序组合也暴露了类似的弱点，我们在描述应用程序之后列出了这些弱点。表5总结了五个应用程序。

ExCamera：视频实时编码。提供实时的编码服务，比如youtube，取决于视频大小，如今的编码方案可以花费几十分钟甚至数小时。为了能够实时编码，ExCamera将慢速的编码部分并行化，串行执行快速的部分。ExCamera暴露内部的编解码状态，允许编解码任务以纯粹的函数语义执行。特别地，每个任务需要以有着视频帧的内部状态做为输入，并将修改后的内部状态作为输出。

MapReduce：分析框架如MapReduce，Hadoop，Spark，部署在传统的管理集群中。而有些分析的工作负载已经开始迁移到serverless，这些工作负载大多由Map作业组成，下一步自然是支持全面的MapReduce作业。这个努力背后的驱动力是利用serverless计算的灵活性高效的支持作业，这些作业在执行期间所需的消耗各有不同。

Numpywren：线性代数。大规模线性代数计算是一种传统的部署在超算或者由高速低时延的网络连接的高性能计算集群。在这样的历史背景下，serverless看上去不适合这个场景[t9] ，但是有两个理由说明为什么serverless可能在线性代数计算中是有道理的。第一，管理集群是一些没有CS背景的科学家的巨大障碍。第二，并行的量会在计算期间显著地变化。配置一个节点数量恒定的集群要不就是会拖慢作业速度，要不就是没法充分利用集群性能。

Cirrus：机器学习训练。机器学习的研究者使用VM集群来执行不同的ML工作流任务，比如预处理，模型训练，超参优化。这种方法的一个挑战是，流水线的不同阶段需要不同的资源，如同线性代数一样，一个固定大小的集群，会导致严重的利用不足或严重降速。Serverless计算可以通过为不同阶段分配合理资源来克服这个挑战，还可以解放开发者不再维护集群。

Serverless SQLLite：数据库。自动伸缩的数据库服务已经存在了，但是要更好的理解Serverless的局限性，那么理解是什么使得数据库工作负载这么的有挑战是十分重要的。在这个上下文中，我们考虑是否有第三方可以直接使用云函数来实现一个Serverless Database，一个解决方案是在云函数中运行通用事务型数据库，例如PostgresSQL，Oracle，mysql。然而这就会面临几个挑战，第一，Serverless计算没有内置的持久化存储，所以我们需要利用远程的，这会造成巨大的延迟。第二，数据库采用面向连接的协议，比如，数据库作为server运行接收客户端的连接。这种方案与运行在网络地址转换后面的云函数冲突，因此不能支持这些链接。最后，许多高性能数据库依赖于共享内存，云函数是隔离的，无法共享内存。一些不分享内存的数据库希望节点一直在线，可以直接定位到。全部这些问题对在无服务器上运行传统数据库软件或实现等效功能提出了重大挑战，所以我们希望数据库就放在BaaS。

这些应用希望使用Serverless的一个关键理由是细粒度的自动伸缩，这样资源利用率就可以匹配每个应用不同的需求，表格5总结了这5个应用的特征，挑战和workaround。我们利用他们来识别当前serverless计算的4个局限性

应用	描述	挑战	Workarounds	性价比
实时视频压缩	视频编码	对象存储太慢无法支持细粒度通信；函数对于任务来说太粗粒度	函数到函数通信，避免对象存储；函数执行替代任务	VM的60倍速度，6分之一价格
MapReduce	大数据处理（100TB）	Shuffle不会因为对象存错的延迟和IO的限制而伸缩	低延迟，高IOPS的小存储来加速shuffle	比VM排序100TB快1%，花费多15%
线性代数	大规模线性代数	需要很大的问题规模来克服存储延迟，很难实现高效的广播	使用低延迟高吞吐的存储处理小规模问题	比原本慢3倍，但是CPU消耗节省1.26到2.5倍
ML 流水线	规模化的ML训练	缺少告诉存储来实现参数服务器，很难实现高效广播，聚合	低延迟存储，高IOPS的参数服务	比VM快3-5倍，成本高7倍
数据库	有主状态的应用	缺少共享内存，对象存储延迟太高，缺少链接管理的支持	如果没有过多的写入操作，可以通过共享文件系统解决	每个事务的成本高3倍，读规模相当但是写不是

表5：Serverless新应用领域的需求总结

3.1 细粒度操作场景下存储的不足

Serverless平台天然的无状态使它很难支持应用进行细粒度状态分享。这主要是由于现在的云提供商提供的存储服务的限制引起的。表6总结了云存储服务的特点。

表6：理想的serverless存储和云提供商存储服务特性。绿色表示好，橙色中等，红色为糟糕。

持久性和可用性保证描述了系统对故障的容忍程度：

Local表示只能保证一个地区的可靠，distributed确保能够多个地区可靠，ephemeral表示数据存在内存中，应用崩溃，数据就会丢失。理想的Serverless存储提供与块存储相当的性价比，同时可以透明的让云函数配置并访问存储

对象存储比如S3，Azure Blob Storage，有着高可扩展性，提供便宜的长期对象存储。但是却有着高访问成本和延迟。根据最近的测试，所有这种服务花费至少10微秒读或写小对象。S3提供高吞吐，但是他变得更贵了。维持10万IOPS, 需要花费每分钟30美元，比运行ElastiCache多3到4个数量级。ElastiCache提供高性能，读写延迟小于毫秒，并且一个redis sever一个线程可提供超过10w IOPS的吞吐。

Key value数据库，例如DynamoDB，Google cloud Datastore提供高IOPS，但是非常贵，而且需要较长时间启动。最后，云厂商还提供内存存储实例，比如memcached，redis，但是他们不能容错，也不能像Severless平台那样自动伸缩。

如我们再表5看到的，构建在Serverless的应用需要透明化配置的存储服务，与计算的伸缩相匹配的存储量。不同的应用推动不同的持久化和可用性保证，还可能推动延迟或其他性能测量方法。我们相信这需要开发一种短暂的和持久的serverless存储，我们会进一步在第4部分讨论。

3.2 缺少细粒度协调器

为了扩展支持有状态应用，serverless框架需要提供一种方法，可以让任务协作。比如，如果任务A需要任务B的输出，必须有一种方法让A知道输入已经准备好了，甚至A和B在不同的节点中。许多协议[t10] 的目的都是确保数据的一致性，也需要类似的协调者。

现在的云存储服务都没有通知能力。但是云厂商提供独立的通知服务，比如SNS和SQS，这些服务显著地增加了延迟，有时达到几百毫秒。此外，当用于细粒度的协调时，它们可能代价高昂。已经有了一些相关的研究，比如Pocket，它没有很多的缺点，但是还没有云厂商去采用它。

如前所述，应用没有选择，只能选择基于VM管理的系统，这些系统内提供通知，如ElastiCache和SAND，或者实现自己的通知机制比如ExCamera，它让云函数之间通过一个长期运行的基于虚拟机的服务器相互通信。这种局限性还表明一种新的Serverless计算变种可能值得探索，比如给函数实例命名并允许直接寻址以访问其内部状态（Actor as a service）

3.3 糟糕的性能和标准通信模式

广播，聚合，和shuffle在分布式系统中是一些最通用的通信原语。这些操作被应用到机器学习和大数据分析。图2展示了这几种原语在基于VM的和函数解决方案的通信模式。

图2,：3种分布式系统通用通信模式：a表示VM实例，每个实例运行2个函数或是任务。B表示同样的模式但换成了云函数实例。注意VM方案有更少的远程通信。这是因为

VM实例在发送前或收到后提供了大量的机会点，可以跨任务在本地共享、聚合或组合数据

使用VM方案，所有运行在一个实例中的任务可以在发送结果到其他实例前，共享data的复制用于广播，本地聚合。所以广播和聚合的复杂度是O(N)，N是VM实例数。然而云函数的复杂度是O(NK),K是每个VM中的函数实例。而shuffle操作更具戏剧性。VM方案，本地任务可以组合数据所以2个VM实例间只有一条消息。假设同样数量的发送者和接受者就是N的平方条消息。对比看，云函数需要NK的平方条消息。函数比VM有更小的核心数，K一般从10到100。既然应用没法控制函数的位置，一个serverless应用可能比VM方案多发送2到4个数量级的数据

3.4 可预测的性能

即便云函数比起传统VM实例有着更低的启动延迟，但是对于某些应用程序，在启动新实例时发生的延迟可能很高。有三个影响冷启动延迟的因素：

1. 启动云函数的时间

2. 初始化软件环境的实践，比如，python库

3. 用户自己的代码

后两者可以使前者相形见绌。花费1秒的可以可以启动函数，但是可能需要10多秒来加载应用的库。[t11]

另一个阻碍预测性能的是硬件资源的可变性，这是云提供商可以灵活地来选择底层服务器的结果。在我们的实验中，我们有时占用的CPU是不同的时代的产品。这种不确定性暴露了云提供商在希望最大限度地利用其资源和可预测性之间进行了基本的取舍权衡。

4 Serverless计算会变得怎么样

既然我们已经解释了如今的serverless计算和他的局限性，让我们看看未来，了解如何将他的优势利用到更多的应用。研究者已经开始着手解决上述的问题，并且探索如何改进serverless平台和跑在其上的工作负载。伯克利同事和我们的一些人所做的额外工作重视以数据为中心，分布式系统，机器学习，编程模型在serverless计算的机遇和挑战。在这里，我们广泛的看看增加在serverless计算中运行良好的应用程序和硬件的类型，识别5个领域的研究挑战：抽象，系统，网络，安全和架构

4.1 抽象

资源需求： 现在serverless允许开发者指定函数的内存大小和执行时间限制，但没有其他的资源需求。这种抽象阻碍了那些想要更多地控制指定资源的人，比如CPU，GPU。一种可以让开发者明确指定这些资源需求的方法。然而这将使云提供商更难通过复用实现高利用率，因为他为函数调度增加了更多的限制。它还违背了无服务器的精神，增加了云应用程序开发者的管理开销

更好的选择是提高抽象级别，让云提供商推断资源需求，而不是让开发人员指定它们。为此，云提供商可以使用多种方法，从静态代码分析到分析以前的运行，再到动态（重新）编译，将代码重新定位到其他机器架构。自动提供适当的内存量特别有吸引力，但是当方案必须与自动垃圾回收合作时是非常有挑战的。有些研究提议这些语言运行时能被serverless平台集成。

数据依赖： 如今的云函数平台不会感知函数间的数据依赖，更不用说这些函数可能交换的数据量了。这种忽视会导致次优的系统布局，从而导致低效的通信模式，如我们前述的MapReduce和numpywren

一种解决这个挑战的方法是，云提供商暴露API让应用指定他的计算图，通过更好的位置决策，最小化通信并改进性能。我们注意到许多通用的分布式框架（例如MapReduce,Spark, Beam, Cloud Datafow）,并行数据库（BigQuery，Cosmos DB），还有编排框架（Airflow）可以在内部产生一个图。原则上这些系统内可以在修改后跑在蕴含出上并暴露图给云提供商[t12] 。注意AWS Step Functions代表着这个发展方向的进步，它提供有状态机器语言和API

4.2系统挑战

高性能，价格合理，透明配置的存储： 如表3和5所讨论的，我们2个不同的未解决的存储需求：serverless临时存储和持久存储

临时存储。在第三部分的前4个应用被存储的速度和延迟限制了，存储用于在云函数间传送状态。同时需要的容量也是不同的，他们都需要这样的一种存储来维护应用存活期间的状态。一旦应用结束，状态就可以被丢弃。这样的短暂存储也许可以使用其他应用的缓存来进行配置。[t13]

一种提供短暂存储的方法是构建一个网络栈优化的分布式内存服务，确保微秒级延迟。这种系统确保应用的函数在应用生存期间能够高效的存储交换状态。这种内存服务需要根据应用需求自动伸缩存储容量和IOPS。这种服务的一个独特点在于，它不只需要透明分配内存，还要透明的释放内存。特别地，当应用终止或者失败，存储需要被自动释放。这种管理类似于操作系统自动释放进程完成（或崩溃）时由进程分配的资源。进一步，这样的存储必须提供应用间的访问保护和性能隔离。

RAMCloud和FaRM展示了提供微秒级的实验并支持一个实例几百几千IOPS的内存存储服务也是可能的。他们通过优化整个软件栈并利用RDMA来最小化延迟来达到这个效果。然而他们需要应用指明配置存储。他们也不为多租提供强隔离。另外一个最近的，Pocket，目标是提供短暂存储的抽象，但是也缺少自动伸缩，要求应用预先分配存储。

通过利用多路复用，临时存储比如今Serverless计算更高效的利用内存。使用Serverless，如果应用需要的内存少于分配的VM实例内存，那么内存就会浪费，相反，使用共享内存服务，一个无服务器应用未使用的任何内存都可以分配给另一个应用。实际上，即便一个应用也可以通过多路复用获得收益：使用Serverless，VM不使用的内存不会被跑在其他VM上的程序使用，他们都属于同一个应用。而共享内存服务可以。当然，即使使用Serverless计算如果云函数不使用它全部的本地内存，也会造成内部的内存碎片。在某些情况下，在共享内存服务中存储云函数的应用状态可以减轻内存碎片化。

持久存储。就像个其他应用一样，serverless数据库应用的试验受限于存储系统内的延迟和IOPS，他也需要长期的数据存储和文件系统可变状态语义。而数据库的功能包括OLTP可能会越来越多的作为BaaS提供[t14] 。我们将此应用视为几个应用程序的代表，这些应用需要比serverless提供给的临时存储更长的保留期和更高的持久性。为了实现高性能serverless持久化存储。一种方法是利用基于SSD的分布式存储对，配合分布式内存缓存。一个最近的系统认识到需要这些目标，那就是Anna Key value数据库，他通过结合多个现有的云存储达成了成本效益和高性能。这个设计的一个关键挑战是在重尾访问分布[t15] 中达成low tail latency[t16] ，基于这个事实，内存缓存容量可能会被SSD容量低很多很多[t17] 。利用新的存储技术[t18] ，承诺微秒级访问时间，正在成为解决这一挑战的一个有前途的办法。

类似Serverless临时存储，服务必须是透明配置的，并且应该确保应用间隔离和租户安全并且性能可预测。然而，当应用程序终止时，serverless的临时存储将回收资源，持久存储必须只是释放资源（比如remove或者delete命令造成的终止），就像传统存储系统一样。另外，它必须确保持久性，这样写入的数据才能被保存下来。

协调器/ 信号服务： 在函数间分享状态经常使用生产者消费者模式，这需要消费者在数据可用时就知道这件事。同样地，当某个条件变化时，一个函数可能想要发信号给另一个函数或者多个函数共同协调，比如为了实现数据一致性机制。这样的信号系统可以从微秒延迟，可靠消息和广播，组通信中受益。我们也注意到，既然云函数实例不是独立可寻址的，那么他们就不能被用于实现标准的分布式系统算法，如共识或leader选举

最小化启动时间： 启动时间由3部分组成

1． 调度和启动资源用户用于运行函数

2． 下载应用环境（OS，库）用于运行函数代码

3． 应用启动，比如加载，初始化数据结构，库。

资源调度和初始化会引起明显的延迟和负担，因为他会创建隔离的执行环境，配置客户的VPC和IAM策略。云提供商最近已经专注于开发新的轻量化隔离机制来减少启动时间。

一种减少2的方法是利用unikernal。Unikerna用两种方法消除传统操作系统带来的开销。第一，不像传统OS动态探测硬件，应用用户配置，分配数据结构，unikernal通过为运行它们的硬件预先配置并静态分配数据结构，来压缩这些成本。第二，unikernal只包括应用需要的驱动和系统库，这比传统系统的占用低许多。值得注意的是，由于unikernels是为特定的应用程序定制的，当运行标准内核的许多实例时，可能无法实现高效。比如不同云函数在同VM共享内核页，或者通过预缓存减少启动时间。另一种减少2的方法是当应用调用时动态并增量的加载库，比如Azure Functions使用共享文件系统。

特定应用初始化（3）是程序员的职责，但是云提供商可以包含一个准备就绪信号在他们的API里来避免云函数在实例没启动前就收到工作。更宽泛的说，云提供商可以寻求提前执行启动任务的方法[t19] 。对于与客户无关的任务，比如用流行的操作系统和一系列库引导VM，这一功能尤其强大。如warm pool[t20] 可以在租户间共享。

4.3 网络挑战

如第三章图2所说，云函数可以引起及明显的通信负担，这些通信原语都是非常流行的如广播，聚合，shuffle。尤其是假设我们打包K个函数在同一个VM实例，云函数版相对单实例版会发K倍的消息，在shuffle则是K平方。

有几种方法可以解决这个挑战：

l 提供给函数大量的cores，类似VM实例，这样在网络上发送消息前和接受后，多个任务可以在他们之间组合和共享数据。

l 允许开发者明确的把函数部署到同一个VM，提供分布式通信原语，应用可以开箱即用，这样云提供商可以分配函数到同一个VM实例。

l 让应用提供计算图，云提供商对函数进行定位最小化通信负担（参考抽象挑战）

注意前两个proposal可能减少云提供商放置函数的灵活性，导致减少数据中心利用率。争议地是，他们也通过逼迫开发者思考系统管理，违背了Serverless精神

4.4.安全挑战

Serverless计算洗牌了安全职责，将他们从用户转嫁给了提供商，没有从根本上改变他们。然而serverless计算还必须处理应用和多租户资源共享中内在的风险。

随机调度和物理隔离： 物理共存是在云内部硬件级别侧信道或Rowhammer[t21] 攻击的中心。攻击的第一步，攻方租户需要确认与受害人在同一物理主机上，而不是随机攻击陌生人。云函数的短暂性可能会限制攻击者识别受害者（两方的函数同时运行）的能力。一种随机化的敌方感知调度算法可以减少攻击方和受害者定位在一起的风险，使攻击变得困难。然而，特意阻止物理上的共同放置，可能会与优化启动时间、资源利用或通信的安排相冲突

细粒度安全上下文：云函数需要细粒度配置，包括秘钥访问，存储对象，甚至本地临时资源。需要翻译已经存在的Serverful应用的安全策略，提供高表达能力的安全API给云函数动态使用。比如函数可能委托安全权限给其他函数或云服务。使用加密保护基于功能的访问控制机制的安全上下文天然适合这种分布式安全模型。最近的工作提议，使用信息流在多方配置中控制跨函数访问控制。其他的提供安全原语的分布式管理，例如non-equivocation和revocation会使情况恶化，如果函数动态创建秘钥和证书。

在系统级别，用户需要每个函数有更细粒度的安全隔离，至少是可选的。提供函数级沙箱的挑战是以一种方法在不缓存执行环境的情况下保持短启动时间，在重复的函数调用之间共享状态的，一种可能是对实例进行本地快照，以便每个函数都可以从干净状态开始。或者轻量级虚拟化技术开始被serverless提供商采用：library OSes 包括gVisor，在用户空间“shim layer”实现系统API，而unikernal和microVMs，包括AWS firecracker，优化guest内核并帮助最小化主机攻击面。这些隔离技术减少了启动时间到了几十微秒，相对的，VM启动时间是以秒度量。这些解决方案是否在安全性方面与传统vm实现了对等，还有待证明。我们期望，寻找具有低启动开销的强隔离机制成为研究和开发的一个活跃领域。从积极的一面来看，提供商管理和短期实例可以更快地修补漏洞。

用户系统避免共住攻击，一种解决方案是要求物理隔离。最近的硬件攻击也利用保留核心甚至整个机器来吸引用户。提供商可以提供高级选项给客户在物理宿主机启动函数，宿主机完全归属于他们使用[t22] 。

不留意的Serverless计算：函数可能通过通信泄漏访问模式和时间信息。对于serverful应用程序，数据通常是在批处理中检索的，并在本地缓存。相反，因为云函数是短暂的，分布广泛在云中，网络传输模式可以向云中的网络攻击者泄漏更敏感的信息（比如员工就是攻击者），即使payload是端到端加密的。将无服务器应用程序分解为许多小函数的趋势加剧了这种安全暴露。虽然主要的安全问题是来自外部攻击者，但是可以通过采用不经意的算法[t23] 来保护网络模式不受雇员的攻击。不幸的是，这些往往有很高的开销

4.5 计算架构挑战

异构硬件，价格，易于管理：x86微处理器作为在云计算中占主导地位的技术在性能上几乎没有提高。2017年一个程序的性能提升只有3%。如果这种趋势继续下去，20年内性能不会翻番。同样，每个芯片的DRAM容量也接近极限；现在在卖16gbit的DRAM，但是要制造一个32gbit的DRAM芯片似乎是不可行的。这种缓慢变化的一个好兆头是，供应商可以将磨损的旧电脑不受干扰[t24] 的投入到Serverless市场。

通用微处理器的性能问题并不能降低对更快计算的需求。有两条路，对于用高级脚本语言（如JavaScript或Python）编写的函数，软硬件协同设计可以使特定于语言的运行速度快一到三个数量级的定制处理器，另一个前进的路径是特定领域的体系结构[t25] 。DSA针对特定的问题领域进行了定制，并提供显著的性能和效率提高，但该域以外的应用程序的性能较差。GPU一直被用来加速图形，我们开始将DSAs用于机器学习，如TPU。TPU的性能可以超过CPU 30倍。这些示例是许多示例中的第一个，针对不同领域使用DSA增强的通用处理器将成为常态

如4.1提到的，我们看到serverless计算支持异构硬件2条路：

1. Serverless拥抱多种实例类型，根据使用的硬件提供不同的计费方式。

2. 提供商能够基于语言自动选择加速器和DSA。这种自动化可以隐式地基于在函数中使用的软件库或语言来实现，比如GPU硬件用于CUDA 代码，TPU用于TensorFlow代码。可选地，提供商监控函数的性能，下次运行时将他们迁移到个更适合的硬件。

Severless计算现在需要面对x86中的SIMD指令集的异构。AMD和Intel通过增加每个时钟周期执行的操作数和添加新的指令，迅速发展了x86指令集的这一部分。对于使用SIMD指令的程序，在最新的Intel Skylake微处理器上运行512位宽的SIMD指令比在旧的Intel Broadwell微处理器上运行128位宽的SIMD指令要快得多。如今AWS Lambda以同样的价格提供所有的微处理器，但是用户目前没办法指定他们想要更快的SIMD。在我们看来，编译器[t26] 应该建议使用哪种硬件会是最好的搭配。

当加速器变得更流行时，serverless提供商将不能够忽视异构的两难境地，尤其是因为存在合理的补偿措施。

5.谬论和陷阱

**谬论 ： **既然Lambda 云函数实例有着和t3.nano 相等的内存容量，而价格是7.5 倍每分钟，那么severless 的价格更贵。

Severless计算的美妙之处在于价格中包含的所有系统管理功能，包括可用性冗余、监视、日志记录和伸缩。云提供商报告说，当将应用迁移到Serverless时，客户看到成本节约了4-10倍。功能要比一个t3.nano实例多很多，除了单点故障外，信用系统还将其限制为每小时最多6分钟的CPU使用时间（两个vCPUs中的5%），所以它可能在负载高峰期间拒绝服务，而Serverless却可以轻松处理。Serverless在更细的边界进行资源占用，包括伸缩，因此使用的计算资源可能更高效。因为没有触发函数调用的事件时就不会收费，serverless可能便宜许多。

陷阱 计算可能会产生不可预测的成本。

对有些用户来说，一个用多少花多少的缺点是无法预测成本，这与许多组织管理预算的方式不一致。在批准预算（通常每年进行一次）时，组织希望知道下一年serverless服务的成本是多少，这种期望是合理的，云提供商可以通过提供基于bucket的定价来缓解，类似于电话公司为一定量的使用提供固定费率计划的方式。我们还相信，随着组织越来越多地使用serverless，他们将能够根据历史预测其serverless计算成本，类似于他们今天对电力等其他公用事业服务的方式。

谬论 既然serverless 计算编程是高级别语言就像python ，那就很容易在不同serverless 提供商间移植。

不只是函数的调用原语和打包方式不同，而且serverless应用还依赖于缺乏标准化的专有的BaaS产品生态系统。对象存储，key value数据库，认证，日志和监控这些是突出的例子。为了实现可移植性，用户必须采用某种标准API，比如POSIX试图为操作系统提供的API。来自Google的Knative项目是朝这个方向迈出的一步，旨在为应用开发人员跨部署环境使用统一的原语

陷阱 比起Serverful 计算，serverless 厂商锁定可能非常强

这个陷阱是先前谬论的结果；如果移植很困难，那么很可能会出现供应商锁定。一些框架承诺通过跨云支持来减轻这种锁定

谬论 云函数不能处理需要能预测性能的低延迟应用

serverful实例之所以能很好地处理这种低延迟的应用程序，是因为它们总是处于打开状态，因此它们可以在收到请求时快速响应请求。我们注意到，如果云功能的启动延迟对于给定的应用程序来说不够好，那么可以使用类似的策略：通过定期运行来预热云函数，以确保在给定时间内有充足的运行实例来处理请求。

陷阱 几乎没有所谓“弹性”的服务能比得上无服务器计算的真正的灵活性需求

如今弹性这个词是个流行术语，但这个名字被应用在那些不如serverless计算服务的服务上。

我们对能迅速改变容量的服务感兴趣，只需最少的用户干预，就可以在不使用时“伸缩到零”。例如，尽管它的名字是AWS ElastiCache，但它只允许你实例化固定的数量的Redis实例。其他“弹性”服务需要显式的容量配置，有些服务需要花费数分钟来响应需求的变化，或者只能在一个限制的范围伸缩。当用户构建的应用将高度弹性的云函数与只有有限弹性的数据库、搜索索引或服务器级应用程序结合起来时，他们将失去serverless计算的许多好处。

如果没有一个量化的、被广泛接受的技术定义或度量标准，用于帮助对比和构成系统，那么弹性就还是一种不明确的描述。

6总结和预测

通过提供一种简化的编程环境，serveless使云更容易使用，因此吸引更多人可以和愿意使用它。Serverless计算承诺FaaS和BaaS交付，是云编程的重要成熟标志。它消除了当今serverful计算对应用开发人员的手动资源管理和优化的需要。类似于过去40年汇编语言向高级语言的演变。

我们预测serverless的使用将激增，我们还预计，随着时间的推移，混合云中的本地应用程序将逐渐减少。尽管由于监管约束和数据治理规则，一些部署可能会持续保持现状。[t27]

虽然已经取得了成功，但我们发现了一些挑战，如果克服了这些挑战，服务器将在更广泛的应用中变得受欢迎。第一步是Serverless临时存储，他必须提供低延迟，高IOPS，且价格合理，但是不需要提供实惠的长期储存。第二类应用需要持久存储，可按需长期存储。新的非易失性内存技术可能有助于这样的一种存储系统。其他应用程序可以从低延迟信号服务和对流行通信原语的支持中获益。

无服务器计算未来面临的两个改进挑战是安全性和性价比优势（性价比可能来自于特殊用途的处理器）。在这两种情况下，serverless计算的特性有可能有助于解决这些挑战。物理共住是侧信道攻击的条件，但是在serverless计算中很难确定，而且可以很容易地随机放置云函数。 云函数高级语言编程如JavaScript, Python, TensorFlow提升了编程抽象层级，使创新变得容易，这样可以交付具有性价比的硬件。

伯克利对serverless计算的看法论文预测2009年云计算面临的挑战将得到解决，并将蓬勃发展，这已经成真了。云营业额年增长50%，已经被证明对提供商来说是高盈利的。

我们对serverless计算的下一个10年作了以下预测：

l 我们期望新的BaaS存储服务，以扩展在serverless计算上运行良好的应用类型。这样的存储将匹配本地块的性能，有短暂和持久两种。我们将看到用于serverless计算的异构硬件远远超过今天为其提供动力的传统x86微处理器。

l 我们期望serverless计算比serverful计算更容易安全地编程，这得益于高层级编程抽象和云函数的细粒度隔离。

l 我们看不出serverless计算的成本高于serverful计算的基础，所以我们预测计费模型将会变化，任何规模的应用消耗的成本都会更少。

l serverful计算的未来将是促进BaaS的发展。在severless计算上很难编写的应用程序，比如OLTP数据库和通过信原语如队列，可能会是这种服务的一部分。

l serverful计算不会消失，随着serverless计算克服了他的诸多局限性，他在云的重要性将下降

l serverless计算将成为云时代的默认计算模式，在很大程度上取代了serverful计算，从而结束了客户端-服务端时代

[t1]译者：只要运行便是在满速运转的，跑在同一个资源池里进行资源复用就行了

[t2]译者：独占资源池，平时闲置比较多，随时待用，资源难以复用

[t3]译者：高效利用资源，而对于用户来说，则是把资源管理等多种风险都给了云提供商

[t4]译者：新的收费形式

[t5]译者：相对的，粗粒度指虚机级别的资源分配，而serverless却使共享虚机成为可能

[t6]译者：这也是为啥早期云计算刚兴起时，oracle等传统服务器厂商抢着做云计算，VM的高效使得服务器可以大卖

[t7]译者：领域相关，比如安防领域

[t8]译者：不是无状态，但也不是像数据库那样的重依赖于状态的应用

[t9]译者：指的网络延迟和高性能不适合

[t10]译者：比如raft

[t11]译者：所以java需要一种方案，否则Serverless在国内很难打动市场，比如Graal和Quarkus

[t12]译者：这样的话标准谁制定还是云厂商主动适配？

[t13]译者：Redis？

[t14]One recent example is Amazon Aurora Serverless (https://aws.amazon.com/rds/aurora/serverless/). Services such as Google’s BigQuery and AWS Athena are basically serverless query engines rather than fully fledged databases.

[t15]每种云存储的延迟,速度是完全不同的，呈重尾分布

[t16]比如P99 1ms，但是p99.9高达2s，说的是这部分延迟需要被降低

可能 [t17]如重尾分布所说，呈现2/8分布

[t18]An Chen. A review of emerging non-volatile memory (NVM) technologies and applications. Solid-State Electronics, 125:25–38, 2016.

[t19]Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Harter, Andrea Arpaci-Dusseau, and Remzi Arpaci-Dusseau. SOCK: Rapid task provisioning with serverless-optimized containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 57–70, 2018.

[t20]Timothy A. Wagner. Acquisition and maintenance of compute capacity, September 4 2018. US Patent 10067801B1.

[t21]Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. Flipping bits in memory without accessing them: An experimental study of dram disturbance errors. In ACM SIGARCH Computer Architecture News, volume 42, pages 361–372. IEEE Press, 2014.

[t22]译者：非常不错的收费模式和安全策略，虽然违背Serverless精神

[t23] An algorithm whose behavior, by design, is independent of some property that influences a typical algorithm for the same problem…

Elaine Shi, T-H Hubert Chan, Emil Stefanov, and Mingfei Li. Oblivious RAM with O((log N) 3 ) worst-case cost. In International Conference on The Theory and Application of Cryptology and Information Security, pages 197–214. Springer, 2011.

[t24]译者：用户感知不到便是没有干扰？

[t26]译者：Serverless平台中的编译器

[t27]译者：这也阻碍一些业务向service mesh的转型