摘要：Serveless 计算的目标和机会是让云编程者像使用高级语言那样受益。

本文分享自华为云社区《简化云编程，伯克利对serverless的看法（翻译）》，作者： 二手雄狮。

译者言：

作为了解一个技术最好的方式之一就是对相关论文进行阅读，比如 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 作为中间层

表 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

​表 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 用户没什么吸引力了。这些都增加了现有资源的收入。

​表 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 个局限性

​表 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 平方。

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

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

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

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

注意前两个 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 年作了以下预测：

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

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

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

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

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

• 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 的转型

点击关注，第一时间了解华为云新鲜技术~