1. 论文基本信息 (Bibliographic Information)

• 标题 (Title): SPRIGHT: 从无服务器计算中提取服务器！基于 eBPF 的高性能事件驱动共享内存处理 (SPRIGHT: Extracting the Server from Serverless Computing! High-performance eBPF-based Event-driven, Shared-memory Processing)
• 作者 (Authors): Shixiong Qi, Leslie Monis, Ziteng Zeng, Ian-chin Wang, K. K. Ramakrishnan
• 隶属机构 (Affiliation): 加州大学河滨分校 (University of California, Riverside, CA)
• 发表期刊/会议 (Journal/Conference): ACM SIGCOMM 2022 Conference (SIGCOMM '22)。SIGCOMM 是计算机网络领域的顶级学术会议，被公认为网络研究的最高殿堂，这表明该论文具有极高的学术质量和影响力。
• 发表年份 (Publication Year): 2022
• 摘要 (Abstract): 论文指出，尽管无服务器计算承诺提供高效、低成本的云服务，但现有解决方案（如 Knative）包含了许多“重型”组件，这违背了其初衷。这些平台在构建高性能函数链时缺乏数据平面优化，导致性能严重下降，并且“冷启动”延迟问题突出。为此，论文提出了 SPRIGHT，一个轻量级、高性能、响应迅速的无服务器框架。SPRIGHT 利用共享内存处理，避免了不必要的协议处理和序列化/反序列化开销，从而显著提升了数据平面的可扩展性。它广泛利用基于 eBPF 的事件驱动处理机制，并创造性地使用 eBPF 的套接字消息机制来支持共享内存，使开销与负载严格成正比。实验表明，SPRIGHT 在实现与基于轮询的 DPDK 相同数据平面性能的同时，CPU 使用率降低了 10 倍。此外，eBPF 还帮助 SPRIGHT 替换了重型组件，使得函数能够以极小的代价保持“温暖”状态，从而消除了“冷启动”问题。与 Knative 相比，SPRIGHT 在吞吐量和延迟上实现了一个数量级的提升，并大幅降低了 CPU 占用。
• 原文链接 (Source Link): /files/papers/68e38aa933fab70a3d0ebd31/paper.pdf (已正式发表于 SIGCOMM '22 会议论文集)

2. 整体概括 (Executive Summary)

• 研究背景与动机 (Background & Motivation - Why):

  • 核心问题： 当前主流的无服务器计算平台（以 Knative 为代表）虽然提供了便捷的开发模式，但在底层实现上却引入了大量“服务器式”的开销。这些开销源于其松散耦合的架构，导致了严重的性能瓶颈。
  • 重要性与挑战 (Gap):
    1. 重型组件开销： 每个函数实例都伴随着一个持续运行的边车代理 (sidecar proxy)，如 Knative 的 Queue Proxy，这引入了大量的数据拷贝、上下文切换和中断，消耗了大量 CPU 资源。
    2. 函数链性能低下： 在微服务架构中，函数链是常见模式。但现有平台通过网络协议（如 HTTP）连接函数，每次调用都涉及完整的内核网络协议栈处理、序列化/反序列化，导致延迟高、吞吐量低。
    3. 冷启动延迟： 为了节省成本，无服务器平台会将不活跃的函数缩容至零。当新请求到达时，重新启动函数实例（即“冷启动”）会产生显著的延迟，影响用户体验。
  • 创新思路： 论文的切入点是“从无服务器计算中提取服务器”，即移除那些模拟传统服务器行为的、持续运行的重型组件和不必要的网络处理流程。其核心思想是，利用现代操作系统内核技术 eBPF 和共享内存，构建一个真正事件驱动、资源消耗与负载严格成正比的轻量级数据平面。

• 核心贡献/主要发现 (Main Contribution/Findings - What):

  • 提出了 SPRIGHT 框架： 一个基于 eBPF 和共享内存的轻量级、高性能无服务器框架。
  • 实现了高效的函数链通信机制： 通过共享内存实现函数间的零拷贝 (zero-copy) 数据传递，并利用 eBPF 的事件驱动特性来传递数据描述符，彻底避免了函数间通信的内核网络协议栈开销。
  • 设计了轻量级事件驱动代理 (EPROXY & SPROXY)： 使用 eBPF 程序替代了传统边车代理，实现了指标收集等功能，但只在有事件发生时才消耗 CPU，极大地降低了资源占用。
  • 解决了冷启动问题： 由于 SPRIGHT 的空闲资源消耗极低，它可以让函数实例保持“温暖”状态（即一直运行但不处理请求），而几乎不产生 CPU 开销。这使得平台可以避免“冷启动”带来的高延迟，同时又不会浪费大量资源。
  • 性能验证： 实验证明，与 Knative 相比，SPRIGHT 实现了数量级的性能提升（吞吐量提升 5 倍，延迟降低 53 倍），同时 CPU 使用率节省高达 27 倍。

3. 预备知识与相关工作 (Prerequisite Knowledge & Related Work)

• 基础概念 (Foundational Concepts):

  • 无服务器计算 (Serverless Computing): 一种云计算执行模型，云提供商动态管理计算资源的分配和调度。开发者只需编写和部署代码（函数），而无需管理底层服务器。其核心是函数即服务 (Function-as-a-Service, FaaS)，特点是事件驱动和按需付费。
  • 冷启动 (Cold Start): 在无服务器环境中，如果一个函数长时间没有被调用，平台会回收其资源（如容器实例）。当新的请求到达时，平台需要重新创建实例、加载代码和初始化环境，这个过程所花费的时间就是冷启动延迟。相对地，如果实例已经存在，则称为“热启动” (Warm Start)。
  • 函数链 (Function Chaining): 在微服务架构中，一个复杂的业务逻辑通常被拆分成一系列功能单一、松散耦合的函数。这些函数按照特定顺序依次调用，形成一个处理流水线，即函数链。
  • Knative: 一个构建在 Kubernetes 之上的开源无服务器平台。它提供了请求驱动的计算（自动扩缩容，包括缩容至零）和事件驱动的应用构建块。论文中反复提到的 Queue Proxy 是 Knative 为每个函数 Pod 注入的一个边车容器，用于处理请求、缓冲和收集指标。
  • eBPF (extended Berkeley Packet Filter): 一项革命性的内核技术，可以看作是内核中的一个轻量级、沙箱化的虚拟机。它允许开发者在不修改内核源码或加载内核模块的情况下，安全地执行自定义代码。eBPF 程序是事件驱动的，例如可以在网络数据包到达、系统调用发生时触发。它被广泛用于网络、可观测性和安全领域，因其高性能和灵活性而备受青睐。
  • 共享内存 (Shared Memory): 一种高效的进程间通信 (Inter-Process Communication, IPC) 机制。它允许多个独立的进程访问同一块物理内存区域。通过传递指向共享内存中数据的指针（或描述符），可以避免在进程间进行耗时的数据拷贝，实现“零拷贝”通信。
  • DPDK (Data Plane Development Kit): 一个用于快速数据包处理的库和驱动程序集合。它通过绕过内核网络协议栈、使用轮询 (polling) 模式等技术，在用户空间实现极高的数据包处理性能。但其主要缺点是轮询会持续占用 CPU 核心，即使在没有流量时也是如此，造成资源浪费。

• 前人工作 (Previous Works):

  • 论文分析了现有的无服务器平台，如 Knative、OpenFaaS 等，指出它们普遍采用松散耦合的组件（如独立的网关、消息代理、边车代理）来构建函数链，这种设计带来了巨大的网络和处理开销。
  • 论文也提到了利用 DPDK 等内核旁路 (kernel-bypass) 技术来加速网络处理的研究。这些工作虽然性能很高，但通常以持续消耗高额 CPU 资源为代价，与无服务器计算“按需使用”的理念相悖。

• 差异化分析 (Differentiation):

  • 与 Knative 等传统平台相比，SPRIGHT 的核心区别在于其数据平面的彻底重构。它用一个统一的、基于共享内存的通信机制取代了函数间繁琐的网络调用。
  • 与 DPDK 等高性能方案相比，SPRIGHT 的创新在于用 eBPF 的事件驱动模型取代了 DPDK 的轮询模型。这使得 SPRIGHT 在实现同等级别高性能的同时，资源消耗是负载驱动的，空闲时几乎不占用 CPU，完美契合了无服务器计算的经济高效模型。

4. 方法论 (Methodology - Core Technology & Implementation Details)

SPRIGHT 的系统设计旨在通过 eBPF 和共享内存，构建一个轻量级、高性能的无服务器数据平面。

该图像是系统架构示意图，展示了SPRIGHT框架在主节点和工作节点上的组成与数据流程。图中包括用户请求经过入口网关，数据通过SPRIGHT网关中的eBPF程序代理（EPROXY）进入共享内存，再通过路由表传递到多个函数容器（包含SPROXY的eBPF程序）。控制流由SPRIGHT控制器、kubelet、共享内存管理器等组件协同管理，自动伸缩器和指标服务器负责性能监控和调整。不同箭头分别表示指标流、数据包流、描述符流和控制流的传递路径。

上图（图像 3）展示了 SPRIGHT 的整体架构，主要组件包括：

• 控制平面 (Control Plane): 运行在主节点上的 SPRIGHT controller 负责与 Kubernetes API 交互，管理函数链的生命周期。它协调工作节点上的 kubelet 来创建和管理 SPRIGHT 的数据平面组件。
• 数据平面 (Data Plane):
  • SPRIGHT gateway: 每个函数链的入口点。它负责处理外部请求的协议栈（如 TCP/IP、HTTP），然后将请求的有效载荷 (payload) 提取出来并放入共享内存，从而启动函数链的处理流程。
  • 共享内存 (Shared Memory): 为每个函数链分配的私有内存池，用于函数间的零拷贝数据交换。
  • EPROXY & SPROXY: 附着在网关和函数上的 eBPF 程序，构成了轻量级的服务网格。

4.1 链内通信优化：事件驱动的共享内存处理

这是 SPRIGHT 最核心的创新。

• 方法原理： 函数链内的所有函数都部署在同一个物理节点上。它们之间不通过网络通信，而是通过一块共享内存来传递数据。实际传递的不是数据本身，而是一个指向共享内存中数据位置的轻量级数据描述符 (packet descriptor)。

• 方法步骤与流程 (S-SPRIGHT 模式):

  该图像为系统架构示意图，展示了SPRIGHT框架中用户态与内核态的交互流程。图中包含多个函数（Fn1、Fn2、Fn3）及对应的SPROXY代理，通过共享内存进行数据传递，利用eBPF的socket map实现高效事件驱动处理。数据从NIC经过TCP/IP协议栈传入SPRIGHT网关，依次通过各函数和代理，最终通过共享内存完成高性能函数链处理，突出其低延迟与高效能特点。

上图（图像 1）详细描绘了基于 SPROXY 的数据流：

1. 外部请求到达 (步骤 ①): SPRIGHT gateway 接收外部请求，完成协议处理，并将请求的有效载荷写入共享内存。
2. 启动函数链 (步骤 ②): gateway 创建一个数据描述符（包含数据位置和下一个函数 Fn 1 的 ID），并通过一个套接字 (socket) 发送出去。
3. SPROXY 拦截与重定向: 附着在该套接字上的 eBPF 程序 SPROXY 会被触发。它会拦截这个描述符，解析出目标函数 Fn 1 的 ID。然后，它查询一个名为 socket map 的 eBPF 映射表，找到 Fn 1 对应的套接字。最后，SPROXY 调用 eBPF 辅助函数 bpf_msg_redirect_map()，将描述符直接重定向到 Fn 1 的套接字，这个过程完全在内核中完成，绕过了整个网络协议栈。
4. 函数处理 (步骤 ③): Fn 1 从其套接字接收到描述符，根据描述符中的信息直接从共享内存中读取数据进行处理。
5. 链式调用 (步骤 ④-⑦): Fn 1 处理完毕后，如果要调用链中的下一个函数 Fn 2，它会重复上述过程：创建一个新的描述符，通过自己的套接字发送，其 SPROXY 拦截并重定向到 Fn 2。这个过程被称为直接函数路由 (Direct Function Routing, DFR)，因为它绕过了 SPRIGHT gateway。
6. 返回结果 (步骤 ⑧-⑨): 链中最后一个函数处理完成后，将结果描述符发回给 SPRIGHT gateway。gateway 从共享内存中读取最终结果，封装成网络响应（如 HTTP response）并发送给外部客户端。

4.2 轻量级事件驱动代理 (EPROXY & SPROXY)

SPRIGHT 使用 eBPF 程序彻底取代了 Knative 中持续运行的 Queue Proxy 边车。

该图像为系统架构图，展示了SPRIGHT框架中基于共享内存和eBPF的事件驱动处理流程。图中包含SPRIGHT网关Pod和多个函数Pod，通过共享内存进行读写操作，利用eBPF的socket机制实现描述符传递和socket映射访问。不同流（指标流、数据包流、描述符流、socket映射访问）用不同颜色箭头区分，体现出数据在用户态和内核态之间的交互与高效处理。

如上图（图像 4）所示：

• SPROXY: 附着在每个函数 Pod 的套接字上。主要职责是处理链内的数据描述符重定向，并收集应用层（L7）指标，如请求率。
• EPROXY: 附着在 SPRIGHT gateway 的网络接口上。主要职责是处理进出函数链的外部网络流量，并收集网络层（L3）指标，如包速率。
• 指标收集: 当事件（如描述符传递、数据包收发）发生时，eBPF 程序被触发，顺便将指标数据更新到一个 eBPF 的 metrics map 中。SPRIGHT gateway 内置的代理会定期读取这个 map 并上报给指标服务器。这种方式的开销极低，且完全是事件驱动的。

4.3 安全域 (Security Domains)

为了在多租户环境中使用共享内存时保证隔离性，SPRIGHT 设计了安全域。

该图像为系统架构示意图，展示了SPRIGHT框架中两个安全域（chain #1和chain #2）的工作流程。每个安全域内包含共享内存池和对应的SPRIGHT网关，支持函数（Fn 1、Fn 2、Fn 3）通过共享内存池进行数据交互。kubelet作为工作节点的控制中心，通过控制流管理安全域内共享内存管理器和SPRIGHT网关的协作，图中绿色箭头表示数据路径，蓝色虚线箭头表示控制流。

如上图（图像 5）所示，SPRIGHT 通过两种机制实现隔离：

1. 私有共享内存池: 每个函数链（chain #1 和 chain #2）都有一个独立的、由专用 Shared mem. manager 创建的共享内存池。不同链的函数无法访问彼此的内存池。
2. SPROXY 消息过滤: SPROXY 在重定向描述符之前，会查询一个过滤规则表（也是一个 eBPF map）。该表定义了哪些函数之间允许通信。如果一个函数试图向一个未经授权的目标函数发送消息，SPROXY 会直接丢弃该描述符，从而防止跨链的未授权访问。

5. 实验设置 (Experimental Setup)

• 数据集/工作负载 (Datasets): 论文设计了三个具有代表性的场景来全面评估 SPRIGHT。

  该图像为系统架构示意图，展示了SPRIGHT框架中两个安全域（chain #1和chain #2）的工作流程。每个安全域内包含共享内存池和对应的SPRIGHT网关，支持函数（Fn 1、Fn 2、Fn 3）通过共享内存池进行数据交互。kubelet作为工作节点的控制中心，通过控制流管理安全域内共享内存管理器和SPRIGHT网关的协作，图中绿色箭头表示数据路径，蓝色虚线箭头表示控制流。

上图（图像 6）展示了这三个场景的函数链结构：

1. 在线精品店 (Online Boutique): 一个包含 10 个微服务的复杂电商应用，具有多条复杂的函数调用链。用于评估系统在真实、复杂应用下的综合性能。
2. 物联网运动检测 (IoT - Motion detection): 一个简单的双函数链，流量具有间歇性、突发性的特点。用于评估系统对“冷启动”问题的处理能力。
3. 停车场图像识别计费 (Parking - image detection & charging): 一个包含计算密集型任务（图像识别）的函数链，流量模式是周期性的。用于评估系统在处理周期性负载和重计算任务时的效率。

• 评估指标 (Evaluation Metrics):

  • 吞吐量 (Throughput): 以每秒请求数 (Requests Per Second, RPS) 衡量。
  • 响应时间 (Response Time): 包括平均延迟、95% 和 99% 分位延迟，用于衡量性能和长尾延迟。
  • CPU 使用率 (CPU Usage): 衡量系统的资源效率。

• 对比基线 (Baselines):

  • Knative: 代表了当前主流的、基于边车代理和内核网络协议栈的开源无服务器平台。
  • gRPC 模式: 代表了传统的“有服务器”微服务部署方式。函数作为普通 Kubernetes 服务运行，彼此通过 gRPC 直接通信。这个基线用于剥离 Knative 平台本身（如边车）带来的开销。
  • D-SPRIGHT: SPRIGHT 的一个变种，它使用基于轮询的 DPDK 来传递共享内存描述符。这个基线用于凸显 S-SPRIGHT（论文提出的最终方案）中事件驱动 eBPF 方法相对于高性能轮询方法的 CPU 效率优势。

6. 实验结果与分析 (Results & Analysis)

• 核心结果分析 (在线精品店工作负载):

  该图像是包含九个子图的复合图表，展示了三种不同模型（Knative、gRPC、SPRIGHT）下多条链（Ch-1至Ch-6）的响应时间累计分布函数（CDF）、各时间点响应时间及对应CPU使用率。图中多条曲线对比了各链在不同时间段的性能差异，显示SPRIGHT在响应时间和CPU使用方面均优于Knative，且表现更稳定；gRPC性能介于两者之间。部分子图展示了随时间变化的请求响应延迟波动，以及CPU资源利用率，突显SPRIGHT在高性能和低CPU占用方面的优势。

上图（图像 8）展示了在线精品店场景的详细对比结果：

• 性能和可扩展性：

  • Knative 在 5000 并发用户时就已经过载，表现为吞吐量下降、响应时间急剧增加（子图 g, d），其 CPU 消耗巨大，其中网关和边车代理占了约 50%（子图 g）。
  • S-SPRIGHT 和 D-SPRIGHT 可以在 25000 并发用户下稳定运行，吞吐量是 Knative 稳定状态下的 5 倍以上。
  • 在延迟方面，S-SPRIGHT 的 95% 分位延迟（13ms @ 5K 并发）远低于 Knative（693ms）和 gRPC（141ms）（子图 a, b, c）。

• CPU 效率：

  • 这是 S-SPRIGHT 最亮眼的优势。在 5000 并发下，S-SPRIGHT 仅使用约 1 个 CPU 核心，而 D-SPRIGHT 使用 11 个，Knative 使用超过 13 个（子图 i, g）。这证明了基于 eBPF 的事件驱动方法相比 DPDK 的轮询方法在 CPU 效率上的巨大优越性。即使在 25000 并发的高负载下，S-SPRIGHT 的 CPU 使用率（约 3.5 核）也远低于 D-SPRIGHT（约 11 核）。

• 冷启动与零伸缩分析 (物联网与停车场工作负载):

  该图像为图表，包含两个子图。子图(a)展示了不同时间点（秒）下S-SPRI与Knative两种方案的响应时间（秒），显示S-SPRI响应时间显著低于Knative，后者存在较多较高延迟。子图(b)展示了相同时间范围内两方案及其组件对应的CPU使用率（%），S-SPRI整体CPU使用率明显低于Knative及其队列组件，体现了SPRIGHT在性能和资源利用上的优势。

上图（图像 9）展示了物联网场景的结果：

• Knative 启用了缩容至零 (zero scaling)，在每次请求突发到来时都遭遇了严重的“冷启动”，导致响应时间出现高达 9 秒的尖峰（子图 a）。

• SPRIGHT 则选择让函数实例保持“温暖”，由于其空闲时 CPU 消耗可忽略不计，因此它能以极低的资源成本提供持续的低延迟响应。从 CPU 使用率图（子图 b）可以看出，SPRIGHT 的函数 (S-SPRI.:fn) 在空闲时 CPU 占用几乎为零，而 Knative 的队列代理 (Kn: queue) 即使在处理少量请求时也会产生明显的 CPU 尖峰。

  该图像为两部分折线图。上图显示了S-SPRIGHT与Knative两种方案在不同时间戳下的响应时间对比，S-SPRIGHT响应时间明显更低且更稳定。下图展示了两者的CPU使用率随时间变化，其中Knative有明显的CPU使用峰值和“pre-warm”阶段，以及零扩缩（zero-scaling）过程，而S-SPRIGHT的CPU使用率保持极低且稳定。整体反映出SPRIGHT在响应速度和资源利用上显著优于Knative。

上图（图像 10）展示了停车场场景的结果：

• 即使 Knative 采用了“预热” (pre-warm) 策略来避免冷启动，其启动和销毁函数实例的过程本身也消耗了大量 CPU，甚至超过了实际处理请求的消耗。此外，Knative 的缩容过程非常缓慢，导致资源长时间被无效占用。
• 相比之下，S-SPRIGHT 始终保持低且稳定的 CPU 使用率，总 CPU 消耗比 Knative 节省了 41%，同时响应时间还略低。这证明了“保持温暖”策略在 SPRIGHT 框架下是经济可行的，从而可以从根本上消除冷启动问题。

7. 总结与思考 (Conclusion & Personal Thoughts)

• 结论总结 (Conclusion Summary):

  • 论文成功地论证了当前主流无服务器平台存在严重的“服务器”式开销，违背了无服务器计算的核心理念。
  • 通过巧妙地结合 eBPF 的事件驱动能力和共享内存的高性能通信，SPRIGHT 框架显著提升了无服务器数据平面的性能和资源效率，实现了数量级的吞吐量提升和延迟降低。
  • SPRIGHT 的设计使得“保持函数温暖”成为一种低成本、高收益的策略，从而优雅地规避了长期困扰无服务器计算的“冷启动”难题。这项工作为构建下一代高效、轻量级的无服务器平台指明了方向。

• 局限性与未来工作 (Limitations & Future Work):

  • 单节点约束: SPRIGHT 的核心优势依赖于将函数链内的所有函数部署在同一个物理节点上，以便使用共享内存。这限制了单个函数链的容错能力和可扩展性。当单个节点的资源无法满足一个大型函数链的需求时，该模型将面临挑战。
  • 应用移植成本: 将现有应用迁移到 SPRIGHT 需要修改代码，将标准的网络 I/O（如 HTTP/gRPC 调用）替换为 SPRIGHT 提供的基于共享内存的异步 API。
  • 语言支持: 目前的实现仅支持 C 语言，这限制了其在更广泛开发者社区中的应用。

• 个人启发与批判 (Personal Insights & Critique):

  • 启发:
    1. 技术的创造性融合: 这篇论文最精彩之处在于对 eBPF 技术的深刻理解和创造性应用。它没有将 eBPF 仅仅用作网络加速器，而是发掘了其作为通用内核事件处理引擎的潜力，并将其与共享内存这一经典的 IPC 机制结合，解决了现代云原生架构中的一个核心痛点。
    2. 回归问题本质: 论文“从无服务器计算中提取服务器”的立意非常深刻。它提醒我们，在追求架构的灵活性和抽象性的同时，不应忽视底层实现带来的性能开销。有时，回归到更底层的通信原语（如共享内存）反而能获得巨大的性能收益。
    3. 事件驱动的价值: SPRIGHT 再次证明了事件驱动模型在资源效率上的巨大优势，尤其是在处理间歇性或不可预测负载时。
  • 批判性思考:
    1. 可操作性与通用性: 单节点约束是其最大的软肋。虽然对于边缘计算等资源受限场景可能适用，但在大型数据中心环境中，跨节点的高可用和故障恢复是基本要求。未来的工作需要探索如何在保持高性能的同时，将此模型扩展到多节点环境，例如通过 RDMA (Remote Direct Memory Access) 等技术。
    2. 安全模型: 论文提出的安全模型假设链内函数相互信任。在复杂的微服务应用中，不同服务可能由不同团队开发，信任边界可能需要更细粒度的控制。仅靠 SPROXY 的消息过滤可能不足以应对所有内部威胁。
    3. 调试与可观测性: 基于共享内存和 eBPF 的通信方式相对传统网络通信更加底层和不透明，可能会给应用的调试和问题排查带来新的挑战。开发者熟悉的网络抓包、日志分析等工具可能不再直接适用。