IT 论文精读 · PAPER 63
Jonas, Schleier-Smith 等 · UC Berkeley · 2019（配同年反方 Hellerstein 等 · CIDR 2019 对读）
你打开一个网站，背后总得有台机器一直开着等你。Serverless（无服务器）想省掉这件事：你只交一段代码，云平台在有请求时才把它跑起来，跑完就撤，没人访问时一分钱不收——「无服务器」不是真没有服务器，而是服务器不再归你管。2019 年，伯克利一群人写下这篇判断书：一边说「这就是云的未来」，一边老实列出它今天还干不了哪些事。
旧办法像包月租厂房：你得提前猜最忙那天要多大地方——租小了挤爆，租大了空着也照付，而它一年里绝大多数时间都空着。Serverless 像按趟叫车：来一单派一辆，没单时路上一辆都没有，你也不必付停车费。
旧世界里，工程师得先回答一堆和业务毫无关系的问题：租几台机器？什么型号？多少内存？半夜没人用要不要关？突然上热搜怎么加机器？——猜错任何一个，要么白烧钱，要么当场宕机。Serverless 把这些问题整个拿走：你说「这段代码该跑了」，剩下的归云。 论文自己给的类比是：像当年从汇编语言换到高级语言，程序员不必再亲手安排每一个寄存器。
秘密在于把「运行」切碎成一个个短命的小工：来一个请求就现开一个，干完立刻消失。正因为小工随生随灭，它们身上不能存东西（下次来的是全新的一个，什么都不记得），也不能互相打电话（你不知道对方在哪台机器上、这会儿还在不在）。于是所有要保存、要交换的东西，都得寄存进一个公共储物柜（云上的存储服务），谁要谁自己去取。
这既是它省钱的原因，也是它所有麻烦的根源：几个小工要来回倒腾大量数据时，本来当面一句话的事，现在得写进柜子、再从柜子取出来；人一多，柜子前排起长队。这篇论文的主体，就是把这类「今天干不了的事」列成清单：缺一个又快又便宜的临时储物柜、缺让小工互相打招呼的办法、也缺稳定可预期的速度。
同年一篇反方文章把话说得更狠：这等于把数据运到代码那儿去，而分布式系统四十年的经验恰恰相反——要把代码送到数据身边，因为数据重、代码轻；所以数据量大、要反复交换中间结果的活，搬上去就是又慢又贵。两篇合起来成了这个领域的公共词汇表，清单上的坑也在被一条条填。诚实说一句：六年过去，「serverless 将取代普通服务器、成为云的默认形态」这个预言并没有兑现——它成了工具箱里很好用的一把，而不是唯一那把。
Serverless = 你只交代码，云替你开关机器、闲着不收钱；代价是函数短命、彼此不能直连，一切共享都得绕道存储。伯克利这篇把这笔交换讲清楚了，并把「它还差什么」列成了一张后来所有人都在用的清单。
想看它给 serverless 下的正式定义、四大障碍与反方的完整论证？ → 切到精读版
这不是一篇提出新系统的论文，而是一份判断书 + 缺陷清单：它先给被市场用滥的「无服务器计算（serverless computing）」下了可操作的定义——云函数（FaaS）+ 后端服务（BaaS），判据是「计算与存储解耦、你不再申请资源只提交代码、按用量而非按分配量计费」；再拿五类真实应用去试探，指出今天的平台在临时共享存储、细粒度协调、通信模式、性能可预测性四处结构性地卡住；最后预言这条路终将成为云的主流形态。同年 Hellerstein 等的反方文章接住同一批事实，却得出了相反的结论。
Eric Jonas、Johann Schleier-Smith、Vikram Sreekanti 等十余人，来自 UC Berkeley RISELab，含 Joseph Gonzalez、Raluca Ada Popa、Ion Stoica 与 David Patterson；2019 年 2 月以伯克利技术报告（UCB/EECS-2019-3）发布。它明确接续 2009 年同校的《Above the Clouds: A Berkeley View of Cloud Computing》——那篇给「云计算」定了调，这篇想给「serverless」定调。同年 CIDR 上 Hellerstein 等的《Serverless Computing: One Step Forward, Two Steps Back》接上了结论相反的一半，两篇作者部分重合（Gonzalez、Schleier-Smith、Sreekanti 都在）。
在此之前，用云的标准姿势是论文所称的 serverful（有服务器）：你租一批虚拟机，自己定型号、数量、内存，自己装环境、打补丁、配伸缩、做容错。麻烦有三层。第一，你被迫回答一堆与业务无关的问题——该给多少 CPU？峰值是平时的几倍？答案既要经验又要预知未来，而猜错的代价不对称：猜大了天天白烧钱，猜小了直接宕机，于是所有人都往大了猜。第二，你为「分配量」而非「用量」付费：机器一开就计费，哪怕整夜零请求。第三，弹性是你自己的活，而虚拟机启动太慢，往往赶不上突发。
另一边，AWS Lambda 从 2014 年起已把「只交函数、按次计费」跑通了五年，但「serverless」这个词被市场用得面目全非：什么托管服务都自称 serverless，没人说得清它的边界，也就没人说得清它到底缺什么。这篇要干的正是这两件事：先定义它，再测量它的边界。
论文给的等式是 serverless = FaaS + BaaS：云函数跑你的代码，后端服务（对象存储、托管数据库、消息队列……）负责存数据和其他一切。真正把它和 serverful 分开的，是三条判据：
论文自己给的类比是从汇编语言到高级语言：高级语言把寄存器分配自动化了，serverless 则把机器资源的分配自动化了。还有一层常被忽略的漂亮之处：按用量计费把云厂商的激励也扭正了——闲置不再由你买单，填满机器第一次成了卖方自己的事。
为了能「随时开、随时杀、按毫秒计费」，平台必须给函数设下硬约束。以论文成文时的 Lambda 为例：单次执行最长 15 分钟、内存上限约 3 GB、不接受入站网络连接——你无法给一个正在运行的函数发消息，因为你既不知道它在哪台机器上，也不能保证它下一秒还在。
三条合起来逼出一个后果：函数之间任何形式的共享，都只能绕道外部存储。serverful 世界里两个进程要交换数据，直接连一条 TCP 或干脆共享同一块内存；serverless 世界里，同样的交换变成「A 写进对象存储 → B 从对象存储读出」，一趟变两跳，而对象存储一次往返是几十毫秒量级——对一个本该在内存里几微秒完成的动作来说，慢了上万倍。
把这条约束乘上规模，问题就露出獠牙。做一次洗牌时，N 个上游函数各要把数据分给 N 个下游函数：serverful 里这是 N 台机器之间的直连传输，serverless 里却变成往存储写 N×N 个小对象、再读回来。任务分得越细（而 serverless 的整个卖点就是分得细），这个「所有人对所有人」的代价涨得越凶。这不是某家云厂商实现得不好，而是「函数必须无状态、不可寻址」的直接推论——所以论文说它结构性地卡住。
论文拿五类真实应用（实时视频编码、MapReduce 式批处理、大规模线性代数、机器学习训练与推理、数据库）逐一往 serverless 上搬，把撞到的墙归纳成四条：
四条里第一条最要命，另外三条多少都由它派生：中间结果的需求很特别——只活几秒、要极低延迟、量还可能很大，而现有选项非此即彼：对象存储便宜但慢，内存型键值存储快但按常驻容量计费、贵且要自己运维，两边都不符合「按用量计费、闲时归零」的 serverless 精神。第四条则最劝退：GPU、TPU 这类加速器当时的 FaaS 平台根本不提供，等于把深度学习训练挡在门外。
论文还点了两笔：函数把多租户切得更细、共享物理机的邻居更多，侧信道风险上升；而你只能声明「我要多少内存」、无法声明「我这个函数和那份数据有关系」，平台因此没有信息把计算调度到数据附近——这恰好是反方最用力的一击。
同年 CIDR 上，Hellerstein 等（含三位本文合著者）把同一批事实读出了相反的结论。核心论断只有一句：FaaS 是一种「数据运输」架构（data-shipping architecture）——它把数据运到代码那儿去。而分布式数据系统四十年积累的第一原则恰恰相反：要把代码送到数据身边，因为数据重、代码轻，搬数据是最贵的操作。FaaS 强制逆转了它，所以「向前一步（弹性与免运维），向后两步（数据局部性与分布式计算能力）」。
他们的四条限制与伯克利的清单高度重叠但语气更硬：寿命有限、I/O 是瓶颈（函数拿到的网络带宽只是一台正常服务器的零头，而一切又都要走网络）、只能通过慢存储通信、没有专用硬件。他们把模型训练、低延迟预测、分布式事务、流式数据流四类负载搬上 Lambda 实测，结论是往往慢一个数量级、贵一个数量级；出路不是回头，而是把状态做成 serverless 的一等公民（该组后续的 Anna、Cloudburst 正是这条路）。两篇的事实认定几乎一致，分歧在于把这些限制看成「早期缺陷」还是「架构原罪」——伯克利这篇赌前者。
必须诚实地说：这是一篇立场论文（position paper），不提供新系统，也没有新基准测试。它的「结果」是两样东西。
一是五个案例研究。作者用自己组里已有的系统去撞墙，每一撞都指向清单上的某一条：实时视频编码卡在函数间需要频繁细粒度通信；MapReduce 式批处理与排序卡在洗牌只能过对象存储；大规模线性代数卡在缺快速共享内存；机器学习训练与推理卡在缺加速器与低延迟共享状态；数据库类负载卡在无法维持长连接。至于平台的硬约束——15 分钟、约 3 GB、100 毫秒计费粒度、不接受入站连接——都写在公开文档里，论文的贡献是论证它们不是随便设的，而是「按用量计费、随时可杀」这一商业模型的技术代价。
二是成本论证。按单位算力算，云函数比同规格虚拟机更贵；但因为闲时归零，对突发的、低占空比的负载，总账反而便宜。所以它的经济性不是「更便宜」，而是「把成本曲线从矩形改成了随需求起伏的形状」——负载越平稳越划不来。论文另有一节「谬见与陷阱」回应常见质疑（如「云函数天生做不了低延迟」在作者看来下得太早），并以一组预测收尾：serverless 会成为云计算的主导形态，价格会降，异构硬件会被纳入。
它给一个被市场用滥的词做了一次学术定标。「serverless = FaaS + BaaS，判据是解耦、不申请资源、按用量计费」此后成了论文、教材与厂商文档的公共起点；那张障碍清单更成了子领域的研究议程——之后好几年你几乎可以拿它当目录读新论文：临时共享存储那条催生了 Pocket（为 serverless 定制的弹性临时存储）、Locus（少量快存储混合对象存储做洗牌）；冷启动与隔离那条最漂亮的答卷是 Firecracker（2020）——为 Lambda 造的轻量 microVM，同时要虚拟机的隔离强度和容器的启动速度；平台配额这侧，Lambda 在 2020 年前后把内存上限提到 10 GB、计费粒度从 100 毫秒细到 1 毫秒，并支持挂载共享文件系统；有状态 serverless 则成了反方那派的主线（Anna、Cloudburst）。
更广的影响是词汇本身：今天「serverless 数据库」「serverless 数仓」之所以能被听懂，靠的正是这篇把判据从「有没有函数」挪到了「你还需不需要申请和保活资源、账单是否随用量归零」。
① 一句话：给「serverless」下一个可操作的定义，再用五类应用测出它的边界，列成一张四条的障碍清单。
② 定义：serverless = FaaS + BaaS，三条判据——计算与存储解耦、只提交代码而不申请资源、按用量而非按分配量计费（闲时成本为零）。
③ 旧世界的痛：你被迫猜规格与峰值，而猜错的代价不对称；机器一开就计费；弹性还得自己做。
④ 机制与代价：为了能随时开、随时杀、按毫秒计费，函数必须短命、无状态、不可寻址；于是函数之间没有直连这条路，一切共享都要绕道外部存储，一次交换从「内存里几微秒」变成「存储上几十毫秒」。一次洗牌更从「N 台机器直连」变成「往存储写 N×N 个小对象」——任务切得越细（正是 serverless 的卖点），代价涨得越凶。
⑤ 四个障碍：缺低延迟的临时共享存储（最要命）、缺细粒度协调、广播/聚合/洗牌的通信代价高、性能不可预测（冷启动 + 硬件随机 + 无加速器）。
⑥ 经济性的真相：按单位算力算它更贵，赢在闲时归零，所以只对突发的、低占空比的负载划算——越平稳越不划算。
⑦ 反方（Hellerstein 等，CIDR 2019）：FaaS 是「把数据运到代码」的数据运输架构，逆转了「把代码送到数据身边」的四十年经验，对数据密集型任务往往慢一个数量级、贵一个数量级。
⑧ 影响与局限：这份清单成了子领域的研究议程（Pocket、Locus、Firecracker、Cloudburst 都沿它推进）；但它是立场论文而非实验论文，「将取代 serverful」的预测至今未兑现，反方那记架构层面的质疑也没被真正回应。