MUYI · 后端工程师的生产级知识体系

Appearance

Serverless：形态、研究与未来十年 ​

合并自《权威指南：Serverless 未来十年发展解读》上下两篇（2026-10）。 整理自伯克利分校（UC Berkeley）实验室关于 Serverless 的分享，系统解读定义、研究进展与方向预测。

一、定义 Serverless ​

FaaS（函数即服务）：如腾讯云 SCF、Azure Functions、AWS Lambda。用户把（通常是无状态的）代码上传到云端，通过 API 调用或触发器执行。按需付费，按执行时长和调用次数计费。触发方式很丰富，例如 HTTP 请求、定时触发、消息队列事件、对象存储上传事件、API 网关路由。

BaaS（后端即服务）：与 FaaS 相对应的另一类"即服务"。指不以"服务器"方式提供的能力，如腾讯云 COS 对象存储、AWS DynamoDB。还有数据库、消息队列、身份认证、短信邮件这类能力，都可以归入 BaaS。

两者的关系：FaaS 无状态而 BaaS 有状态；FaaS 支持多种运行时的代码，BaaS 几乎不涉及编程模型的限制。共同点是弹性伸缩和按需付费。一次典型的 Serverless 调用往往是 FaaS 出计算逻辑、BaaS 出数据和状态，两者拼成一个完整应用。

Serverless 是用云的一种简化方式。从技术栈演进看：

硬件层（CPU/网络/存储/GPU等加速器）
   -> 虚拟化抽象层（虚拟机、虚拟私有网络）
      -> Serverless 层（FaaS + BaaS，调用基础设施更简单）

传统服务器托管需要自己操心的方面很多。例如可用性、多地域部署、扩缩容、监控告警与排障、系统升级和安全漏洞、迁移策略。Serverless 把这些复杂性都藏了起来。

经典案例：上传图片 → 压缩 → 提取并存储点赞数和文件路径这类信息到数据库。传统方式需要冗长的服务器搭建与部署流程；Serverless 架构的完整流程则是：

  1. 用户上传图片到对象存储（BaaS）；
  2. 存储桶的上传事件触发压缩函数（FaaS）；
  3. 函数完成压缩后把缩略图写回对象存储；
  4. 再把点赞数、文件路径这类元数据写入数据库（BaaS）。

全流程没有一台需要开发者管理的服务器，且只在函数执行的毫秒/秒级时间内计费。开发者只需写一段 FaaS 代码处理逻辑，再配合 BaaS 服务即可完成。

UC Berkeley 认为 Serverless 的三个关键特性：

  1. 隐藏了服务器的概念——服务器仍然存在，但开发者完全无感知。无需繁琐的开发和运维；
  2. 按需付费的计费模型，资源空闲时不收费；
  3. 极致弹性伸缩，资源供给完美适配业务需求。

一个直观类比：传统服务器 vs Serverless = 租车 vs 打车。租车（传统服务器）要自己负责加油、保养、停车；打车（Serverless）从 A 到 B 按里程计费，其余都不用管。

云计算的发展因此可以分两个阶段：

  • 第一阶段：极大简化了系统管理员的职责。通过 API 获取服务器，无需自建机房，云服务商保障资源稳定性；
  • 第二阶段（Serverless）：进一步简化开发者的职责。只需编写原生业务逻辑上传云端即可执行，无需担心扩缩容。这种编程模式的转变，如同十年前云计算对系统管理员职责的转变，拓展了开发者的能力边界。

二、当前 FaaS 平台的限制 ​

  1. 运行时间限制：各平台一般限制 10-15 分钟。影响长时间、强状态依赖的场景（如长时间保持数据库连接）；
  2. 仅支持短暂有状态性（Ephemeral State）：无磁盘存储，函数执行完状态即消失；
  3. 网络通信限制：出流量可以，入流量支持不友好，需要额外的适配开发方式；
  4. 硬件层面限制：例如机器学习需要的 GPU 硬件难以以 Serverless 方式提供。

学术热度：近几年 Serverless 相关论文数量每年翻倍，2020 年已发表 + 计划发表的数量接近 300 篇。研究分为三种方向：

  • 具体应用的抽象：针对特定场景（如大数据检索生成报表）做 Serverless 化，不做通用抽象；
  • 通用的抽象（最有意思的方向）：满足某些条件即可让任意业务适配 Serverless。本质是分布式系统开发模式的简化；
  • 实现层面：追求更低延迟、更好的状态共享、租户隔离、极致弹性扩展这类优化。

三、研究成果一：Serverless 机器学习（Cirrus） ​

现有云上机器学习服务（如 AWS Sagemaker）仅针对特定场景，不具普适性。无法满足模型定制化或训练步骤改动的需求。Berkeley 因此开发了 Cirrus 机器学习库，可在 AWS Lambda 上端到端完成机器学习训练，满足定制化需求。

开发过程中踩到的平台限制如下。内存过小、代码包大小限制、不支持 P2P 点对点传输、无快速存储介质。实例生命周期有限（会被回收重启）。

实验结论：执行时间越短，Cirrus 的性能表现越好，甚至优于其他几种机器学习技术。可以按训练模型和需求选择是否采用。

参考：github.com/ucbrise/cirrus；people.eecs.berkeley.edu/~joao/p13-Carreira.pdf

四、研究成果二：内核即服务（KaaS）——GPU 与 Serverless 结合 ​

背景：FaaS 主要运行在 CPU 上，而 GPU 对机器学习算法和工作流有重要的加速作用。商业化云函数因 GPU 服务器价格高昂、需优化机器利用率，暂不提供 GPU 函数。

KaaS 概念：类似 FaaS 支持 Node.js/Python 等运行时，KaaS 的"运行时"支持面向 GPU 的语言，如 CUDA 或 OpenCL。

挑战：能否完全用纯 GPU 语言编写 KaaS 服务、彻底摆脱对 CPU 代码的依赖？一种方案是每个函数底层同时包含 CPU、内存和 GPU 加速器。更激进的方案是提供 GPU-only 的纯 GPU 底层运行函数，彻底区分 CPU/内存型函数与 GPU 型函数。但由于通信模式上难以从硬件层面彻底分开 CPU 和 GPU，这是难度大的研究挑战。

参考：people.eecs.berkeley.edu/~kubitron/courses/cs262a-F19/projects/reports/project9_report_ver5.pdf

五、课题三：Serverless 文件系统（CFFS）——状态性优化 ​

现状问题：当前 Serverless 的状态共享/存储分为两层：

  • 计算层：FaaS 提供服务，实例相互隔离，仅有短暂状态性——函数运行完毕即销毁，状态随之消失；
  • 存储层：需要持续写入 BaaS（对象存储、KV 存储等）实现长期存储与共享。

由此带来两大困难：

  1. 延迟问题——这也是许多 BaaS 服务的通病；
  2. 以 API 方式提供的对象/KV 存储，无法感知底层存储情况。开发和迁移时难以信任这些资源，改变了以往的开发使用方式。

目标：提供"类似本地磁盘一样的存储能力，区别只是在云端"的文件系统。

CFFS（Cloud Function File System）特点：

  • 基于标准 POSIX API，提供持久化存储能力——像使用本地文件一样使用云端存储；
  • 透明传输机制：函数启动时随之启动一个传输（transaction）。函数销毁时传输被提交（commit），从而获取函数执行过程中的状态信息；
  • 积极利用本地状态和缓存，相比传统文件存储系统性能更优。

架构：CFFS 运行于云服务商的 FaaS 环境中。前端通过标准 POSIX API 调用，后端对接专为 FaaS 设计的存储系统（利用缓存这类机制）。

参考：hpts.ws 上 Schleier-Smith 2019 年论文

六、课题四：Cloudburst——状态敏感、延时敏感场景 ​

  • 面向社交网络、游戏、机器学习预测这类对状态和延迟都敏感的场景；
  • 基于 Python 环境，可低延迟地获取共享可变状态；
  • 与 CFFS 类似，在函数执行器（executor）中使用数据缓存，但额外保证因果一致性（causal consistency），以获得更好的性能；
  • 实验对比：相同条件下，使用 DynamoDB 的 Lambda 函数延迟约 239 ms，而 Cloudburst 的延迟低于 10 ms，两个数量级的差距；
  • 定位：让"状态敏感型"应用也能享受 Serverless 的弹性，而不必迁回传统集群。

参考：github.com/hydro-project/cloudburst 及 arXiv:2001.04592

七、课题五：Serverless 数据中心（Warehouse-scale Computer） ​

  • 传统思路：CPU、内存、GPU、硬盘先组成服务器，再组网形成数据中心；
  • 新概念"分布式集群（distributed datacenter）/ Warehouse-scale computer"：将同类型的硬件元素（如 CPU、内存）集中组合。应用需要某种资源（GPU 加速、硬盘、自定义加速器）时才分配。即把一个数据中心看做一台计算机，提升整体资源利用率；
  • 此类硬件开发已在进行中，Serverless 应考虑适配这种集群模式。这也将改变当前面向单机的应用开发模式。

参考：USENIX FAST'14 keynote（Asanović）

对开发者的启示：当"数据中心即计算机"成为现实，应用开发的视角要转变。从"我拿到了哪几台机器"转变为"我需要多少 CPU、多少内存、多少 GPU"。资源以池化方式按需供给——这正是 Serverless 编程模型得以成立的基础。

八、未来十年方向预测 ​

背景：2009 年 Berkeley 曾预测云计算的发展，部分正确（例如无限资源池、无前期付费）。但没有预见到云计算的第二阶段——Serverless 阶段。本次对下一个十年的预测如下：

1. 特定应用场景与通用场景都将成为 Serverless 主流 ​

  • 特定场景：在弹性伸缩平台中实现特定操作，例如写数据库、实时数据队列、机器学习。用户代码需遵守平台限制（例如运行环境、时长、暂无 GPU 加速）。这些限制会随技术成熟逐步放宽；
  • 通用 Serverless：FaaS 函数被 BaaS 拓展（如 Starburst、缓存服务），配合对象/文件存储保存长期状态。用户可自定义软件服务（如 SQL 能力）。支持流数据处理、机器学习——凡能运行在服务器上的场景都可归入此类。

2. 成本具备竞争力 ​

Serverless 自带高可靠与弹性扩缩容，计费更精确、资源利用率逐步提升。真正做到按需使用付费，将比预留资源更便宜。对比：预留实例在低峰期为峰值买单，利用率常低于两成。Serverless 按毫秒计费，空闲时成本为零，对流量潮汐明显的业务（营销活动、定时批处理）尤其划算。

3. 机器学习场景持续优化 ​

云服务商将提供工作流调度、环境配置（如预置内存）这类能力。同时这些优化也会反哺通用场景的平台性能。

4. 硬件多样化 ​

摆脱对 X86 架构的强依赖，引入新硬件架构（ARM、RISC-V、各类加速器），由用户/云厂商选择最合适的硬件。实现更高的利用率与性能。对机器学习这类专用负载，硬件选型的自由度将直接转化为性价比优势。

补充观察：这两个阶段的预测有一个共同的逻辑。计算与存储持续解耦、资源持续池化、抽象层级持续上移。开发者每上移一层，就不必再关心一整类运维问题（机器、集群，再到容量）。

总结 ​

  • Serverless 是云计算的下一个阶段，三大核心特征：隐藏服务器复杂概念、按需付费、弹性伸缩；
  • 实现上由 FaaS 与 BaaS 共同组成；最直观的转变类比：从租车到打车；
  • 学术研究方向包括：效率提升（性能、可用性）、具体应用抽象（机器学习、数据处理）、通用层面抽象；
  • Serverless 可能改变我们对"计算机"的看法——摆脱本机硬件限制，从云端获取无限资源、随取随用。

内容来源：上篇原文 · 下篇原文 · 2026-10 整理回填，2026-10-18 合并成篇。