系统与数据库2018arxiv.org
无服务器计算：进一步，退两步
Serverless Computing: One Step Forward, Two Steps Back
进阶 · 约 45 分钟读完前置知识：云计算/FaaS 基础、分布式系统基础、虚拟化与容器概念
导读
这篇论文审视无服务器计算（FaaS）的现状，指出它在简化运维的同时，在状态管理、函数间通信和分布式协作上存在根本性缺陷：函数短生命周期、不可寻址，且需通过慢速存储传递数据，难以高效支持大规模协调计算。论文区分了冷启动、运行时长、缺少 GPU 等临时瓶颈，以及隔离于数据、无法缓存状态、函数间只能经存储通信等根本瓶颈。
HN 关注点：serverless 是否被过度宣传：它相比 CGI 有何本质进步、是否造成供应商锁定，以及 Cloudflare 的 V8 isolate/WASM 路线能否绕开论文指出的限制。
后来怎么样
该文系统梳理了 FaaS 的根本性限制，成为无服务器计算研究的重要批判性参考文献，推动了后续围绕有状态 FaaS、函数间通信和数据局部性的研究。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
亲历总结论文指出的临时与根本瓶颈，并披露 GitLab 刚推出 serverless。
我很喜欢这篇文章。它提到两个临时瓶颈：1. 函数最多只能运行 15 分钟，而且有冷启动；2. 不能用 GPU 等专用硬件。它还提到两个根本瓶颈：1. serverless 函数运行在与数据分离的隔离 VM 上，而且函数短命、不可寻址，因此内部缓存状态以服务重复请求的能力有限，FaaS 经常是“把数据运到代码”而不是“把代码运到数据”。2. 由于 serverless 函数没有网络可寻址性，两个函数只能通过缓慢且昂贵的存储传递数据来协作，这阻碍了基本分布式计算；所有通信都经由存储，当前 FaaS 平台除了大规模无协调的（embarrassingly）并行外，没有真正办法让云中成千上万甚至数百万核高效协同工作。披露：我们 GitLab 刚发布了 serverless。
sytse查看英文原文
I loved the article https://arxiv.org/pdf/1812.03651.pdf It mentions two temporary bottlenecks: 1. Functions can run only for 15 minutes and experience cold-starts. 2. You can't use specialized hardware like GPUs. It also mentions two fundamental bottlenecks: 1. Serverless functions are run on isolated VMs, separate from data. In addition, serverless functions are short-lived and non-addressable, so their capacity to cache state internally to service repeated requests is limited. Hence FaaS routinely “ships data to code” rather than “shipping code to data.” 2. Because there is no network addressability of serverless functions, two functions can work together serverlessly only by passing data through slow and expensive storage. This stymies basic distributed computing. , With all communication transiting through storage, there is no real way for thousands (much less millions) of cores in the cloud to work together efficiently using current FaaS platforms other than via largely uncoordinated (embarrassing) parallelism. Disclosure: We just shipped serverless in GitLab https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/
质疑serverless 仍类似 CGI，不适合有状态的长连接交互，长时进程与隔离/扩展性是关键挑战。
正如这里其他人已经指出的，serverless 从根本上仍不比老式 CGI 更好，尽管虚拟化最近有进步，它仍遵循无状态请求-响应范式。对我来说，serverless 最大的缺点是不适合状态不断变化的现代交互式 Web 应用（以及一般应用）。HTTP/2、WebSocket 和 SSE 等技术显然指向长时间运行的客户端-服务器交互，但据我所知，当前 serverless 方案对此没有答案。我认为大挑战在于：如何以同时解决隔离性和可扩展性的方式，实现带长时进程的 serverless 计算。
ciconia查看英文原文
As others here have already noted, serverless is still not fundamentally any better than good old CGI, and despite recent advances in virtualisation it still follows the same stateless request-response paradigm. For me the biggest shortcoming in serverless is that it is actually a poor fit for modern interactive web apps (and apps in general) with a constantly changing state. Technologies such as HTTP/2, websocket and SSE are clearly pointing in the direction of long-running client-server interaction, yet current serverless solutions have (to the best of my knowledge) no answer for that. I think the big challenge is in how to do serverless computing with long-running processes, in a way that solves isolation and scalability at the same time.
补充Cloudflare 用 V8 隔离而非容器，WASM/JS 可能统一运行时与编排，是 serverless 的另一条路线。
同样值得一提的是，Cloudflare 的无服务器计算方案利用 V8 沙箱而非传统虚拟化，这很有意思：https://blog.cloudflare.com/cloud-computing-without-containers/。考虑到互联云计算和通用 IR（论文提到了后者）的挑战，会出现一个有趣的区分：相比容器，WASM 带来单一语言（JS），并通过它可能带来单一“编排器”（V8 Isolates）。当然，这多少等于说如果大家都开大众汽车，世界会更好。但这是一次重新迭代这个想法、也许能做点什么的第二次机会。这不正是迈向云计算未来的一步吗？
Jhsto查看英文原文
On the same note, CloudFlare’s approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: https://blog.cloudflare.com/cloud-computing-without-containers/ Considering challenges of interconnected cloud computing and common IR (of which the latter is mentioned in this paper) an interesting distinction arises: WASM, in comparison to containers, brings us a single language (JS), and through this, possibly a single “orchestrator” (V8 Isolates). Of course, this is more or less saying that the world would be a better place if everyone would be driving a Volkswagen. But this is like a second chance to iterate such idea and maybe do something about it. Isn't this a step towards the future of cloud computing?
质疑担忧 serverless 造成供应商锁定和技术债。
难道只有我觉得 serverless 就是在制造一堆被供应商锁定的技术债吗？
sheeshkebab查看英文原文
Am I the only one that thinks severless is about creating a bunch of vendor locked-in technical debt?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖465 分 · 222 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选