无服务器计算：云计算的下一阶段

让我们来看一个来自大数据处理的说明性例子。考虑一个在电子商务环境中可能出现的简单查询：从100万个商品类别获得权重，并对超过100亿个记录计算均值。这种工作负载具有大量并行性的潜力，因此它可以从无服务器的无限资源错觉中获益。

我们提供了两个特定于应用程序的无服务器产品来迎合这个示例，并说明这个类别如何提供多种方法。可以使用AWS Athena大数据查询引擎，这是一个使用 SQL 编程的工具，可以对对象存储中的数据执行查询SQL。SQL特别适合分析，并且可以用单个语句表达这种计算。或者，可以使用诸如 Google Cloud Dataflow 提供的框架。这样做需要编写一个简单的 MapReduce风格的程序，例如使用Java或Python，这个程序具有两个函数——一个计算某些数据块的加权平均值，另一个将单独块的加权平均值合并起来。该框架负责处理这些函数的数据输入和输出，以及自动缩放、可靠性和其它分布式系统问题。与基于SQL的工具相比，这种抽象可以运行任意的代码，这可以使它适用于更广泛的分析问题。

目前还不存在能够为我们的大数据例子提供高性能解决方案的通用无服务器抽象。云函数似乎提供了一个解决方案，因为它们允许用户编写任意的代码，对于某些工作负载来说，它们确实如此，但由于限制，它们的性能有时比替代方案差很多。图4说明了如果我们使用云函数而不是使用特定于应用程序的框架（如 Cloud Dataflow）来实现示例，网络流量会高得多。使用云函数，提供商在不同VM实例之间分发工作，而不考虑应用程序的通信模式，这简化了自动伸缩，但增加了网络流量。

（图4. 聚合和广播模式的通信量增加。来源：ACM）

我们建议通过两条途径来增强云计算功能，使其在更广泛的应用中运行良好，从而有可能将其变成通用的无服务器抽象概念。首先，假设程序员提供的提示可能表明如何获得更好的性能。提示可能描述应用程序通信模式（例如广播或者 all-reduce），或者建议任务位置关联，这种方法在编译器中有先例（例如，分支预测、优化和Prefetching hints）。

第二，而且更有说服力的是，我们设想通过自动优化来消除低效率。在我们的例子中，云提供商可能承诺从可观察的通信模式中推断出位置优化。在某些情况下，这种推断也可能是基于程序分析而静态地得出。在只有一台机器的背景下，现代编译器和语言运行时已经提供了大量先例，人们可能会认为这种形式的无服务器计算是对分布式系统的扩展语言支持。

图5说明了特定于应用程序和通用无服务器抽象之间的区别。在通用情况下，云提供商公开了一些基本构建块，例如，云函数的增强版本和某种无服务器存储。各种特定的应用案例可以建立在这些基础之上。借助特定于应用程序的无服务器计算，云提供商提供了大量的 BaaS 来满足越来越多的应用程序的需求。

（图 5. 无服务器的潜在未来方向。来源：ACM）

今天，无服务器计算仍然完全是特定于应用程序的类型。即使是可以执行任意代码的云函数，也主要用于无状态API服务和事件驱动的数据处理。我们预计特定于应用程序的无服务器计算将会增长，但最为兴奋的是通用无服务器抽象的潜在出现，它可以托管满足各种需求的软件生态系统。在我们看来，只有通用方法才能最终取代服务器成为云编程的默认形式。然而，通用的无服务器技术目前还不存在，发展这种技术对研究提出了挑战。

研究挑战

无服务器计算正在快速发展，并提出了各种研究挑战，其中许多是特定应用和通用无服务器的共同挑战。

状态管理。分布式云计算应用往往需要在其组件任务之间交换短期或临时状态。这方面的例子包括应用范围内的缓存、索引和其它查询表，或大数据分析的中间结果。今天的云函数允许应用程序在每个函数中本地存储临时状态，这对于缓存和作为程序的工作内存很有用。无服务器的共享状态可以保存在对象存储或键值存储中，但它们不能像有服务器那样同时提供低延迟、低成本、高吞吐量和细粒度访问。应对这些挑战的方法包括用于分析的临时数据存储，以及整合了缓存和提供一致性保证的有状态的云函数。

网络。云函数将调度工作的责任从用户转移到云提供商，这会产生一些有趣的结果。由于用户放弃对函数何时运行的控制，因此在云函数之间传递状态需要通过共享存储；直接的网络通信毫无意义，云提供商会阻止它。访问共享存储会增加大量的延迟，有时甚至是几百毫秒的延迟。用户还放弃了对函数运行位置的控制，从而排除了服务器常见的优化，包括在任务之间共享共同的输入，以及在通过网络发送输出之前合并输出（参见图4和之前的讨论）。但克服这些挑战的尝试，会激发给予程序员更多控制权和允许云提供商自动进行优化之间的矛盾。

可预测的性能。FaaS和BaaS都可能表现出可变的性能，这妨碍了它们在必须满足严格保证性能的应用程序中的使用。部分原因是根本性的：无服务器提供商依靠统计复用来创造无限资源的“错觉”，同时拒绝用户对资源超额订阅的控制。然而总是有一些不幸的时间会导致排队延迟。将资源从一个客户重新分配给另一个客户也存在延迟成本，这在云函数的背景下被称为“冷启动”。冷启动延迟有几个组成部分，其中重要的是初始化函数的软件环境所需的时间。这方面已经取得了进展。Google gVisor 和 AWS Firecracker 等云函数环境现在可以在大约 100 毫秒内启动，而传统VM需要数十秒才能启动。另外也有可能加速应用层面的初始化，如加载库。在这些方面可能还有很大的改进空间，不过也有证据表明，性能优化和安全隔离从根本上是相悖的。AWS Lambda的客户还可以通过购买“预提供的并发”来避免冷启动延迟，这在无服务器模式中重新引入了一种颇具争议的资源预订的形式。我们还希望看到基于统计保证或服务水平目标（SLO）的定价，这在今天的无服务器计算中是不存在的。

安全。无服务器计算带来细粒度的资源共享，因此增加了侧信道攻击的风险，即攻击者利用真实硬件的微妙行为，这些行为与规范或程序员假设不同。威胁范围从Rowhammer对DRAM 的攻击到利用微架构漏洞的攻击。除了采用为有服务器计算开发的缓解措施之外，无服务器计算还可能采用随机调度，使攻击者更难瞄准特定的受害者。由于应用程序的细粒度分解和分解后各个部件的物理分布，通过网络通信的无服务器计算也会导致更大的信息泄露。攻击者观察网络流量的大小和时间，即使它是加密的，也可能对私有数据做出推断。通过Oblivious Computing可以解决这些风险。

编程语言。简化的分布式系统编程是无服务器计算的核心优势，虽然该领域之前的许多工作都是相关的，但无服务器环境需要一个新的视角并增加了紧迫性。传统挑战包括容错性、一致性、并发性以及来自局部性的性能和效率。新挑战包括对自动缩放、即用即付和细粒度多路复用的一流支持。

由于试图将无服务器计算扩展到无状态的云函数之外，容错问题也随之升温。Azure Durable Functions 使用C#语言功能提供透明的检查点，这使得编写有状态和可恢复的无服务器任务变得更加容易。Microsoft Orleans实现了一个actor模型服务计算 云计算，类似地隐藏了程序员的容错问题。Actor还提供了局部性的概念，并且可以作为有状态无服务器计算的云函数的对应物。Ray 体现了两者的元素。实现一致性的方法包括由Argus开创的语言集成事务。然而，事务充满了性能和可伸缩性的挑战，这在无服务器的自动伸缩环境中可能会加剧。另一种方法是使用像 Bloom 这样的语言，它允许自动分析来确定程序的哪些部分可以独立运行，无需协调，从而实现可伸缩性。即用即付应该鼓励语言开发人员重新考虑资源管理，例如，自动垃圾收集可能适用于对内存用量的定价。云编程的语言方法正面解决分布式系统编程的复杂性，可能代表了简化云编程的最直接和最具雄心的方法。

机器学习。我们相信，机器学习的自动优化将在上述所有领域发挥重要作用。它可以帮助决定在哪里运行代码，在哪里保持状态，何时启动一个新的执行环境，以及如何在满足性能目标的同时保持高利用率和低成本。它还可以帮助识别威胁安全的恶意活动，或自动将大型程序切割成可以在单独的云函数中执行的片段。机器学习也可以帮助优化服务器计算，但无服务器抽象给了云供应商更多控制权，以及跨多个客户的可见性——从而训练强大有效的模型。

硬件。当前的硬件趋势可能是对无服务器计算的补充。主导云计算的x86微处理器的性能几乎没有提高；2017年，程序延迟仅改善了3%，这一趋势意味着如果继续下去，性能在20年内不会翻倍。同样，摩尔定律的终结正在减缓每芯片DRAM容量的增长。业界的反应是引入了领域特定架构（DSA），它针对特定类型的问题量身定制，提供了显著的性能和效率提升，但在其它应用中表现不佳。GPU长期以来一直被用于加速图形，我们开始看到用于ML的DSA，如TPU。GPU和TPU在处理“狭窄”任务时的性能可以比CPU高30倍。这些例子是众多例子中的首批，因为用DSA增强的通用处理器将可能成为常态。

我们认为无服务器计算可能为整合不同的架构提供了一个有用的编程模型，比如说在不同的加速器上运行独立的云函数。它还有助于通过提高抽象水平为创新创造空间，例如允许云提供商在识别到可能受益的工作负载时用DSA代替CPU。

为什么无服务器计算可能仍然失败

虽然我们相信无服务器计算可以成长为云编程的默认模式，但也可以想象有几种情况下，有服务器计算仍然占据主导地位。首先，有服务器计算是一个不断移动的目标，它不断地改进，尽管缓慢。曾经按小时计费的云虚拟机现在的最低计费增量为1分钟，此后按秒计费。容器和VM编排工具（例如 Kubernetes、Terraform）有助于简化复杂的部署，并越来越多地自动化管理任务，例如进行备份等。在构建应用程序时，程序员可以依赖成熟的软件生态系统和强大的传统系统兼容性，而公司往往已经拥有熟练的有服务器云部署团队。服务器硬件也在不断变大变强，将CPU、内存和加速器的能力集中在一个紧密耦合的环境中，这对某些应用来说是一个好处。

其次，当今成功的无服务器产品属于特定于应用程序的类别，并且目标范围很窄，而通用的无服务器抽象更有可能取代有服务器计算（也是通用的）。然而，通用的无服务器计算面临着一些障碍：我们所设想的技术还不存在，而且对于云计算供应商来说，它可能是一个不太有利可图的业务。

最后，即使我们的愿景实现了，“无服务器计算”这个品牌也可能无法生存。“新瓶装旧酒”的诱惑很强，而且可能会对市场造成混淆。我们很高兴看到诸如Google App Engine 之类的产品获得了无服务器“绰号”，以及其中诸如缩放到零之类的功能。然而，如果这个术语的含义被混淆了，那么也许通用的无服务计算将以另一个名称出现。

结论和预测

云计算正在蓬勃发展并不断演变。正如我们预测的那样，它已经克服了2010年面临的挑战。由于提供了更低的成本和简化的系统管理，该业务每年增长高达50%，并证明了云计算供应商的高利润。云计算现在正进入第二阶段，其持续增长将由新的价值主张推动：简化的云编程。

类似于叫车比租车更简单的交通方式，无服务器计算使程序员无需考虑服务器以及随之而来的所有复杂问题。按照同样的命名惯例，你可以把出租车服务归类为“无车”运输，因为乘客不需要知道如何开车就可以乘车。无服务器提高了云的抽象级别，采用即用即付的定价，并且快速地自动缩放到零和实际上无限的资源。

无服务器计算仍在发展中，在定义其抽象概念和实现这些抽象概念方面，仍有许多开放性问题。我们（大胆地）总结了本文对未来十年无服务器计算的五个预测：

今天的FaaS和BaaS类别将让位于更广泛的抽象，我们将其归类为通用无服务器计算以及特定于应用程序的无服务器计算。虽然有服务器云计算不会消失，但随着无服务器计算克服其当前的局限性，有服务器在云中的相对使用将会下降。我们希望新的通用无服务器抽象能够支持几乎所有用例。它们将支持状态管理以及优化——无论是用户建议的还是自动推断的——以实现与有服务器计算相当甚至更好的效率。我们认为无服务器计算的成本没有理由超过有服务器计算的成本。我们预测，随着无服务器计算的发展和普及，几乎所有的应用，无论是小规模还是大规模的应用，在无服务器计算中的成本都不会增加，而且可能会降低很多。机器学习将在无服务器的实现中发挥关键作用，使云供应商能够优化大规模分布式系统的执行，同时提供一个简单的编程接口。用于无服务器计算的计算机硬件将比今天为其提供动力的传统X86服务器更加异质化。

如果这些预测成立，无服务器计算将成为云时代的默认计算范式，在很大程度上取代有服务器的计算，从而结束客户端-服务器时代，就像智能手机带来的PC时代的结束一样。

致谢。我们感谢审稿人的深思熟虑的评论，也感谢许多对初稿提出反馈意见的朋友。这项工作是在加州大学伯克利分校 RISELab 进行的，并得到了国家科学基金会探险项目、阿里巴巴集团、AWS、蚂蚁金服、爱立信、Facebook、Future-wei、Google、英特尔、微软、丰业银行、Splunk和VMware的支持。（文/云科技时代编译）

原文链接：

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!