序
在过去的 2 年里，我在伯克利RISELab领导的Hydro团队一直在serverless计算领域快速发展。我们设计并构建了一个名为Cloudburst的函数即服务（ Functions-as-a-Service）平台。我喜欢说“Cloudburst 将状态置于最先进的serverless计算中（待定）”。
除了软件原型，关于Cloudburst和serverless计算的论文也在短时间内喷涌而出：
Cloudburst system architecture in VLDB 2020. (overview below)
Transactional causally-consistent caching in SIGMOD 2020. (overview below)
Atomic Fault Tolerance (AFT) in Eurosys 2020. (overview below)
Optimized Serverless ML Prediction Serving using CloudFlow over Cloudburst at arXiv. (overview below)
A critique of the (prior) state of the art serverless systems in CIDR 2019. (overview below)
All this on top of the two award-winning papers on the Anna serverless KVS at ICDE18 and VLDB19. (overview below)
在这篇文章中，我将介绍serverless计算领域的背景，以及我们是如何达到今天的水平的。无论如何，这都是一个很长的帖子。如果您想跳过背景，您可以直接跳转到新成果的描述。
替有史以来最大的计算机编程（云编程）
由于我对云编程(Programming the Cloud, Berkeley)技术的持续痴迷，我对serverless计算产生了兴趣。你可能会问，为什么要执着于此？
准确地说，公有云(下文简称云)是人类组装的有史以来最强大的通用计算机。忘记哪些藏在政府实验室中的“最大超级计算机（简称超算）”竞赛吧。云的数量级更大，并且每天都在增长。而且更好的是，它没有被锁在实验室里——任何人都可按需以任何规模出租它的算力。计算机科学领域的每位同僚都应该对此感到兴奋，因为它可以说是自 70 年代初 PDP-11和 UNIX 兴起以来计算访问领域最大的游戏规则改变者。
不幸的是，原始算力并不能直接转化为有用的计算。云不仅庞大，而且还是一个包含海量数据的分布式系统，它引发了众所周知的计算机科学难题，包括：并行编程、参与节点的中途故障以及（分布式节点间的）数据不一致问题。对于通用云编程，今天的开发人员被迫 (a) 编写顺序程序以在他们想要使用的每台机器上运行，(b)面对上述核心 CS 问题时，确保代码协同工作以实现预期结果，以及 (c) 弄清楚上述所有复杂方案如何进行部署和管理。因此，如今开发人员很难大规模利用云的力量。继续类比，云就像 PDP-11没有UNIX 和 C — 我们使用与汇编代码等效的分布式系统对其进行编程（尽管说实话，云比这要难得多得多）。
背景：十年去哪儿了？
我们最近在 Hydro 团队中进展如此之快的原因之一是因为我和我的学生在伯克利已经在这个领域徘徊了十多年。十年前的这个秋天，在ACM PODS 2010 上，我在一个主题演讲中发出了呼吁：
现在，在世界上最大的计算中心租用大量资源已在个人开发者的预算之内。但是……除非这些开发人员能够驾驭高并发编程，同时懂得管理大规模的分布式计算机集群所特有的异构性和组件故障，否则这种计算潜力将无法发挥。
鉴于这种必要性，我在 2010 年组建了 BOOM 项目团队，以探索和展示编写程序的新方法。我们开始设计像Dedalus和Bloom这样的编程语言，它们使用云上数据（上层应用）来驱动计算（底层算力），而不是担心哪台计算机在什么时候应该做什么。我们早期的信息并没有在科技媒体上丢失，科技媒体报道了这些想法，并在很大程度上标记了我们的工作承诺。
但是，在接下来的十年里，无论是在实践还是在研究中通用云编程的议程出人意料地很少被采纳。
回想起来，分心的原因是大概是为了赚快钱吧。AWS(Amazon Web Services)在成长期的大部分时间都在证明资本充足的公司可以在没有第三方开发商或全新软件的情况下扰乱企业软件市场。忘记为开发者社区培养 iPhone 风格的“app for that”吧！追随甲骨文和 IBM 等老牌巨头更容易，依旧为传统用例提供传统软件，仅利用全新的平台来降低管理开销。
十年过去了，我们写了一堆论文，建立了一些原型，一些该领域的博士也毕业了。我们对这项工作感到非常兴奋，我们得到了很多学术界的认可。但正如老笑话所说，“你既然这么聪明，那为什么没发财”？我不得不承认，杰夫贝索斯在过去十年中在 AWS 上赚的钱比我在伯克利做研究的钱还多。所以要明确一点，我并不是说数千亿美元的“无聊”云收入对企业来说是一种糟糕的表现（玩笑）。
尽管如此，云编程中更深层次的技术革命仍在等待。既然云市场存在真正的竞争，并且内部部署软件市场又回来了，我们正在进入一个新时代，在这个时代，启用新东西将变得很重要。
商业serverless：FaaS
因为那个新时代大势所趋，云供应商终于采取了一些措施，在他们的高墙外武装/强化开发人员的能力。他们选择的名称serverless计算 其实不是我最喜欢的术语，但是也就这样吧。
在它的第一个典型例子中，serverless计算的思想体现在一个称为函数即服务( FaaS )的 API 中。正如预期的那样，亚马逊首先推出了他们的 AWS Lambda 产品，但 Microsoft Azure Functions 和 Google Cloud Functions 紧随其后。这个思想的设计思路很简单：开发人员用他们最喜欢的传统编程语言编写一个函数。然后，他们将函数上传到云端，接着根据云服务给定的API ，他们可以随意远程调用该函数。每当数据到达函数输入侧时，计算就会在云中加速，并将结果传递到输出侧。开发人员不用花费任何时间配置服务器。云资源根据使用情况动态自动伸缩，开发人员根据使用情况按需付费。
需要明确的是，FaaS 只是云编程的第一步。它的目标是在传统语言中启动单线程顺序代码，即我上面提到的“分布式编程的汇编语言”。尽管如此，虽然编程可能很初级，但至少我不需要成为云 DevOps 向导！我只为我使用的东西付费。毫无疑问，这就是进步。
2018年底，伯克利RISELab的一群人开始研究serverless计算。实验室中的系统人员开始以委员会的形式努力在他们的一篇“伯克利观点”评估论文中描述这一潮流的运动。已经花了十年时间思考云编程的未来，我有更强烈的意见。作为与委员会努力的对比，我的团队在一篇题为“serverless计算：前进一步，后退两步”的论文中坦率地评估了第一代 FaaS 的基本优缺点。简而言之：
- 前进：自动缩放。第三方软件会根据使用模式以即用即付的方式自动扩大和缩小规模。
- 后退：慢速数据访问。serverless函数看到了高到令人尴尬的时延以及昂贵的存储数据访问。
- 后退：无分布式计算。除非通过高延迟存储，否则不允许函数相互通信，这使得大多数分布式计算技术无法实现。
有些人，尤其是在某网站上，认为这篇文章是无知的学者的热门工作。但晨报，它一直遵循我们的工作，得到了它的精髓：
[这是]发自内心的呼吁，不要仅停留在我们今天的位置，而是继续追求真正为云平台设计的基础设施和编程模型
我也倾向于认为我们并不是完全无知（亦不是完全学术）。在撰写该论文时，我们已经在向前推进，克服了第一代serverless产品所回避的挑战。从那时起我们发布的论文和原型中，我们正在展示了什么是可能性。
有状态serverless基础设施 1：存储
在 RISElab 的早期，我们想证明 BOOM 项目的经验教训——特别是避免CALM定理风格的协调——可以在高性能系统中实现。因此，吴承刚着手构建一个名为Anna的键值存储 (KVS) 数据库，以吸收并扩展这些经验教训。
Anna 的第一个目标——以及原论文的名称——是在任何规模上都表现良好。我们的意思是什么？好吧，传统观点认为，每次系统超出计划扩展 10 倍时，都必须重新构建系统。Anna 旨在证明无协调性的教训可以产生一个系统，它可以在单个多核机器上小规模提供世界一流的性能，并在分布在全球的机器上大规模提供。
Anna 的故事比任何规模的故事都要丰富。Anna 是我之前两篇博文（此处和此处）和两篇获奖研究论文（ICDE18和VLDB19）的主题，鉴于这篇文章的篇幅，我将在此处简短介绍，重点关注技术标题：
- Anna 快“疯了”。在简单的工作负载中，Anna 的速度与任何规模的任何东西一样快。在争论中，Anna比目前最快的 KVS 快几个数量级，包括 Redis、Masstree 和英特尔的 TBB 哈希表。这是因为 Anna 从不协调（没有锁、没有原子、没有共识协议！），而这些系统花费 90% 以上的时间在争用情况下进行协调。
- Anna 提供灵活的自动缩放。这是良好的serverless基础架构的标志：在您努力使用时向上扩展，在您不使用时缩小以节省资金和电力。同样，无协调性是关键：无需维护分布式成员信息，因此添加或删除节点的成本在每个规模上都保持较低。
- Anna 提供丰富的数据一致性。即使在并行和分布式执行下，Anna 也可以提供各种一致性保证，以允许程序员跨机器推理数据，包括强大的经典概念，包括因果一致性或可重复读取级别的事务隔离。
- Anna 提供统一的缓存/分层。今天的许多 KVS 系统都是为一种存储级别而设计的：磁盘或 RAM。相比之下，您可以将 Anna 部署为内存中的缓存层、磁盘上的数据库或在较大数据库之上具有较小缓存的多层系统。Anna 在层级上下移动数据，并在两者之间提供统一的一致性保证。
今天没有任何云厂商提供的存储产品可以与成钢的Anna相比。我相信 Anna 能够识别并填补当前云架构中的一个重要漏洞。
有状态serverless基础设施 2：有状态计算
随着 Anna 的成熟，我们已经准备好向上移动堆栈并考虑编程。作为我们的第一阶段，我们决定尝试构建一个 FaaS 系统，以解决困扰商业 FaaS 服务的“倒退两步”。这意味着两件事：
允许云函数通过网络相互通信。商业 FaaS 系统阻止 2 个函数直接通信；他们必须通过一些缓慢的分布式存储系统共享任何信息。即使对于简单的事情也是如此，例如将g(x)的结果传递给另一个函数f以便您可以计算f(g(x))。*除了基础知识之外，如果您希望进行批处理作业以外的任何非平凡分布式计算，那么快速的点对点通信绝对是必不可少的。这里的潜在问题是serverless函数经常来来去去，因此它们的 IP 地址不是可靠的端点。这是通过经典的间接级别解决的：查找服务，实现为某种轻量级分布式数据库。对于这种设置，DNS 可以说是太重了，无法部署，这也许是云供应商拒绝支持 FaaS 网络的原因。幸运的是，我们有 Anna——一个轻量级的自动缩放数据库。因此，函数可以通过 Anna 中的“名称”相互查找，并获取该名称的当前 IP 地址。从直接意义上讲，Anna 既可以作为数据库，也可以作为分布式哈希表覆盖网络，一个我们多年前探索过的二元性。
提供具有低延迟数据访问 (LDPC) 的云函数。分布式计算中所有有趣的挑战都始于数据，或者如某些人喜欢说的，程序的状态。商业 FaaS 供应商的目标是无状态程序，这些程序只需将输入映射到输出，而没有数据更新等“副作用”。但是现在大多数值得注意的应用程序通常以复杂的方式管理数据（状态）。从计算中分离存储的趋势增加了这里的复杂性。在大型云环境中，您不知道何时以及如何扩展或升级您的存储层或计算层，因此最好将它们分开。挑战在于像 DynamoDB 或 ElastiCache 这样的存储服务在延迟方面变得非常“遥远”。为了获得良好的延迟，我们仍然希望在我们的函数附近有一些物理存储托管，即使这两层是分开管理和扩展的。这就是我们所说的物理托管逻辑分解 (LDPC)。在这方面，我们需要创新，并将数据缓存与云函数托管在同一台机器上，同时仍然与 Anna 保持一致。
这是我们去年花费大量精力的地方。一路上我学到了很多东西——虽然编程问题仍然存在，但系统基础设施空间本身就很有趣，我认为我们很好地处理了这个大问题。以下是最近结果的概述：
Cloudburst 系统架构：在我们关于 Cloudburst 的 VLDB 20 论文中详细说明了主要思想、总体架构和一些细节。我们支持 LDPC 原理并描述由此产生的架构。然后，论文详细介绍了我们如何自动将开发人员的可变 Python 状态封装在避免协调的可组合格结构中因此可以将任意 Python 对象集成到 Anna 的无协调一致性模型中。我们还描述了如何通过这些缓存实现简单版本的因果一致性。微基准测试表明，我们可以在 1 到 2 个数量级上超越商业serverless平台，并与 Dask 等手动管理的服务器分布式框架竞争。我们还展示了两个应用程序的端到端数字：ML 预测服务和 Retwis 推特克隆。虽然我们没有为 ML 预测服务做任何特别的调整，但我们的表现优于专门为该任务设计的系统 AWS Sagemaker。（我们的性能也比 AWS Lambda 好很多。）
Hydrocache 和 TCC：SIGMOD 2020 中的Hydrocache 论文深入探讨了我们保持缓存和数据库一致的方式，同时仍然提供低延迟。我们在本文中设置了更高的一致性标准，目标是提供事务因果一致性 (TCC)。您无法从典型的分布式缓存或 KVS 系统中获得这种级别的一致性（看着您，Redis 集群！）但我们表明它可以以非常低的延迟完成。不过，毫无疑问，这篇论文非常具有技术性。享受 ：-）
· 原子容错（AFT）：在阅读任何分布式系统时，容错问题应该是你的想法。FaaS 供应商现在对此非常天真——他们告诉开发人员任何函数都可能失败并且必须重试，因此开发人员需要确保他们的代码是幂等的，这意味着无论运行一次还是多次都具有相同的效果不止一次。这不是很好，也不太可能得到保证。（好吧，流行测验时间。停止你正在做的事情。这周你写了任何代码吗？酷。它是幂等的吗？你怎么知道？期望你担心这一点是否合理？我认为没有！）但它变差。如果您的函数修改了存储状态（比如通过调用数据库），并且在执行过程中失败了一小部分，那么它显然会运行一小部分。也就是说，你的函数的部分执行现在暴露在存储中，并且可以被其他代码读取。本文指出FaaS容错需要的是原子性，即ACID保证中的“A”。您函数的所有外部影响都应该发生，或者都不应该发生。幂等性就变得简单了——只需为请求包含一个唯一的 ID，无论它有多混乱，我们都可以运行 0 次或最多 1 次。这就是幂等性应该被暴露的方式。这篇论文依赖于我们之前在读取原子隔离方面的工作，并提供了一个令人惊讶的简单实现，作为可在任何 FaaS 架构中工作的“垫片”层。我们让它在 Cloudburst/Anna 堆栈中运行，但本文展示了如何在 AWS Lambda/S3 堆栈中部署它。
· 模范服务。我们在 VLDB 20 Cloudburst 架构论文中首次涉足模型服务，这激发了我们做得更好的愿望。几年前，当我的同谋Joey Gonzalez领导Clipper模型服务项目时，我对他说：“嘿，我认为你正在探索的所有这些优化——级联和集成等等——都可以写成简单的Bloom程式”。我继续在白板上将它们绘制为数据流。好吧，有了 Cloudburst 基础设施，Vikram Sreekanti 接受了这个想法并将其变为现实。他实现了一种称为 Cloudflow 的简单数据流语言，并将其部署在 Cloudburst 上。然后，他继续探索显式数据流和有状态serverless计算的组合所带来的优化机会，包括 (a) 将代码放置在正确的硬件资源（即 GPU）上或与正确的数据共存（即在 Hydrocache 中），（ b) 以不同方式自动缩放 ML 管道的不同阶段，(c) 融合运算符，使它们彼此协同运行，以及 (d) 并行运行竞争版本的运算符以让最快的执行获胜。真正好的一点是 ML 代码仍然是一个黑匣子，Tensorflow、PyTorch、MXNet、Scikit-Learn等）Joey 和我觉得 Vikram 确实证明这是构建模型服务系统的正确方法。
结语
很明显，所有这些工作都是由一个团队完成的。最大的贡献主要是由博士生维克拉姆·斯里坎蒂和吴成刚完成的，他们是一个真正充满活力的二人组。乔伊·冈萨雷斯是我作为教职员工顾问的同僚。其他贡献者包括索拉夫·查特拉帕蒂、查尔斯·林、伊汉·林和哈里·苏巴拉吉，何塞·法莱罗、约翰·施莱尔-史密斯和阿列克谢·图马诺夫的明智投入。
近年来，我们在这个领域杀死一些龙的能力也要归功于BOOM和P2天的更大合作者的一长串研究。我们这边还有更多的东西要做，我希望从整个社区看到更多的好东西。对云编程是计算机科学中最大的挑战和机遇之一，我们将继续向前推进。
除了NSF CISE远征奖CCF-1730628外，这项研究还得到了阿里巴巴、亚马逊网络服务、蚂蚁金融、CapitalOne、爱立信、Facebook、Futurewei、谷歌、英特尔、微软、英伟达、苏格兰银行、Splunk和VMware。
专业词汇：
- serverless计算：无服务器运算（英语：Serverless computing），又被称为功能即服务（Function-as-a-Service，缩写为 FaaS），是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供(维基百科)。
- Faas(Functions-as-a-Service):函数即服务（FaaS）是一种在边缘执行模块化代码的无服务器方式。FaaS允许开发人员即时编写和更新一段代码，然后可以响应事件执行该代码，例如用户单击Web应用程序中的元素。这使得扩展代码变得容易，是实施微服务的经济高效方法（CloudFare官网）。
- 软件原型：软件原型常常参考成软件版本周期，这个意思是指软件运行的第一个版本，通常只有几个功能被实作，软件版本周期主要的焦点是具有功能化基础的程式码且这些特征是可以被增加。第一次的软件版本周期等级软件最常需要将功能集合在一起，就变成试用版本软件（维基百科）。
- PDP-11: 最受欢迎的大型机
- UNIX: 事实意义上的标准操作系统
- 并行编程：在计算机科学中，并行编程模型是并行计算机架构的抽象化，通过它可方便的表达算法和它们在程序中的合成。判别编程模型的价值可以通过它的通用性：在各种不同架构上能表达多大范围的不同问题，和它的性能：编译的程序在执行时有多高的效率。并行编程模型的实现形式可以是从“顺序编程”语言中调用的函数库，作为现存语言的扩展，或作为全新的语言。
- 参与节点的中途故障：TODO
- 分布式节点间数据不一致： TODO
- 云编程(Programming the Cloud, Berkeley):TODO