Provuse: Platform-Side Function Fusion for Performance and Efficiency in FaaS Environments

本文提出了 Provuse，一种在 FaaS 平台侧自动执行运行时函数融合以消除冗余实例的透明优化方案，无需开发者修改代码即可显著降低应用延迟和内存消耗。

要点

这篇论文介绍了一个名为 Provuse 的新技术，它旨在解决“无服务器计算”（FaaS）中一个既烧钱又费时的痛点。

为了让你轻松理解，我们可以把整个系统想象成一个繁忙的快递分拣中心。

1. 现在的痛点：为什么要“跑两趟”？

想象一下，你有一个快递任务（比如“处理传感器数据”），这个任务被拆成了几个小步骤：

1. 步骤 A：检查温度。
2. 步骤 B：检查空气质量。
3. 步骤 C：把结果存起来。

在传统的无服务器平台（FaaS）上，这些步骤是独立的。

• 当你需要执行步骤 A 时，平台会叫来快递员 A，给他一辆专属小车，让他去干活。
• 干完活后，快递员 A 把结果交给快递员 B。
• 但是，快递员 A 必须把车开回车库（关闭实例），然后平台再叫来快递员 B，给他一辆新的小车，让他去干活。

这就带来了两个大问题：

1. 双重收费（Double Billing）：你为快递员 A 的车费付了钱，又为快递员 B 的车费付了钱。明明是一件事，却付了两遍钱。
2. 效率低下（高延迟）：快递员 A 和 B 之间还要交接、等车、启动新车，这中间浪费了大量时间。就像你点外卖，厨师做完菜，得先打包，再等另一个骑手来取，再等另一个骑手送到你家门口，中间全是等待。

2. Provuse 的解决方案：把“快递员”合并成“全能特工”

Provuse 就像是一个超级聪明的调度员。它的核心思想是：“既然你们经常一起干活，不如直接合并成一个人吧！”

• 透明化（Transparent）：你（开发者）完全不需要改代码，也不需要告诉平台“我要合并”。你只管写你的步骤 A、B、C。
• 自动合并（Function Fusion）：
  • 调度员（Provuse）在后台观察，发现“检查温度”和“检查空气”这两个步骤总是紧挨着发生，而且必须等前一个做完才能做后一个（同步调用）。
  • 于是，调度员悄悄地把这两个步骤的代码打包进同一个集装箱里。
  • 现在，只需要一辆车（一个运行实例），一个全能快递员，就能一次性把温度检查和空气检查都做完，直接存结果。

这就像什么？
以前是：你叫了出租车去超市，到了超市下车，再叫另一辆出租车去银行。
现在 Provuse 的做法是：它直接派了一辆加长林肯，司机既懂开车又懂去超市和银行，你坐一次车，两个地方都到了，中间不用下车换乘。

3. 它是如何工作的？（技术原理的通俗版）

Provuse 在平台内部有两个主要角色：

1. 功能处理器（Function Handler）—— “哨兵”：

   • 它站在每个函数的门口。当它发现某个函数正在“打电话”给另一个函数，而且是在死等对方回复（同步阻塞）时，它就会立刻向合并器发信号：“嘿，这两个人关系太铁了，经常一起干活，快把他们合并吧！”

2. 合并器（Merger）—— “魔术师”：

   • 收到信号后，它会把两个函数的“工具箱”（代码文件、运行环境）拿出来。
   • 它把这两个工具箱融合成一个新的、更大的工具箱。
   • 然后，它用这个新工具箱重新造一辆新车（新的容器实例）。
   • 最后，它把旧的两辆车撤掉，把新的“全能车”派上去。从此以后，这两个步骤就在同一辆车上完成了。

4. 效果如何？（实测数据）

作者在不同的系统（tinyFaaS 和 Kubernetes）上做了测试，效果非常惊人：

• 速度更快（延迟降低）：平均来说，任务完成的时间缩短了 26%。
  • 比喻：以前送快递要 10 分钟，现在只要 7 分半。
• 更省钱（资源减少）：内存（RAM）的使用量平均减少了 53%。
  • 比喻：以前需要两辆车、两个司机，现在只需要一辆车、一个司机，省了一半的油费和人力成本。

5. 有什么限制吗？

虽然 Provuse 很厉害，但它也有几个前提：

• 信任问题：它只合并那些属于同一个信任域的代码（比如都是你写的，或者都是同一家公司的）。它不会把陌生人的代码强行塞进你的车里，因为那样不安全。
• 适用场景：它最适合那些步骤紧密相连的任务。如果你的任务本来就是各自独立、互不等待的（异步），那合并的效果就不明显。
• 语言限制：目前的原型主要支持 Python 代码，不过原理上可以扩展到其他语言。

总结

Provuse 就像是给无服务器计算平台装上了一个智能的“自动拼车”系统。

它不需要你（开发者）去操心怎么优化代码，平台自己会在后台发现那些“总是手拉手一起干活”的功能，把它们合并成一个超级功能。这样做既省了钱（少付一次车费），又省了时间（不用换乘），让云上的应用跑得更快、更便宜。

这就是平台侧优化的魅力：让基础设施变得更聪明，让开发者可以更专注于业务本身。

技术摘要

以下是关于论文《Provuse: Platform-Side Function Fusion for Performance and Efficiency in FaaS Environments》的详细技术总结：

1. 研究背景与问题 (Problem)

函数即服务 (FaaS) 虽然提供了可扩展且按量付费的优势，但在处理由多个函数组成的复杂应用时，存在显著的延迟和资源开销问题。主要痛点包括：

• 双重计费 (Double Billing)：当函数 A 同步调用函数 B 时，用户需要为两次独立的执行（包括调度、初始化、空闲等待时间）付费，导致成本增加。
• 远程调用开销：函数间的网络通信、上下文切换和调度机制引入了不必要的延迟。
• 资源浪费：每个函数实例通常运行在独立的容器中，导致内存（RAM）利用率低下，尤其是在并发调用链中。
• 现有方案的局限：以往的功能融合（Function Fusion）研究多侧重于应用侧（需要开发者修改代码或配置），缺乏一种对开发者透明、由平台自动执行的优化方案。

2. 方法论与系统设计 (Methodology)

论文提出了 Provuse，一种平台侧 (Platform-Side) 的透明优化机制。其核心思想是在运行时自动检测并合并独立部署的函数实例，无需开发者修改任何代码。

核心架构组件

Provuse 包含两个紧密耦合的组件：

1. Function Handler (函数处理器)：
   • 部署在每个函数实例中，负责协调请求和调用函数。
   • 关键机制：监控出站网络连接。当检测到函数发起阻塞式 (同步) 调用（即调用线程等待结果）且目标在 FaaS 平台内部时，Handler 会向 Merger 发送融合请求。
   • 它利用平台对入口点和部署工件的控制权，直接访问套接字以判断调用模式。
2. Merger (合并器)：
   • 接收融合请求，将两个独立运行的函数实例合并到一个新的容器实例中。
   • 工作流程：
     1. 导出两个源容器的文件系统。
     2. 将文件系统合并为统一视图（保留原始函数标识符以防命名冲突）。
     3. 构建包含两个函数代码的新容器镜像。
     4. 部署新容器，待健康检查通过后，将流量重定向至新实例。
     5. 终止并删除原始的两个容器以释放资源。

技术实现

• 语言无关性：虽然原型主要支持 Python 函数代码，但平台侧机制（如容器操作、网络监控）是语言无关的，易于扩展。
• 部署环境：在 tinyFaaS（轻量级边缘 FaaS 平台）和 Kubernetes（如 Knative 基础）上进行了实现，证明了与容器编排框架的兼容性。

3. 主要贡献 (Key Contributions)

1. 透明优化：首次提出并实现了完全由平台侧控制的函数融合方案，开发者无需感知，无需修改代码或部署配置。
2. 消除双重计费：通过内联 (Inlining) 函数调用，消除了同步调用链中的远程网络开销和重复的计费周期。
3. 双重实现验证：在轻量级边缘环境 (tinyFaaS) 和主流云原生环境 (Kubernetes) 中均成功部署，证明了该方案的通用性。
4. 动态运行时合并：不同于静态分析或离线优化，Provuse 在运行时根据实际调用模式动态触发合并，适应性强。

4. 实验结果 (Results)

作者在 TREE 和 IOT 两个典型 FaaS 应用上进行了基准测试，对比了“原生部署 (Vanilla)"与“启用函数融合 (Function Fusion)"的表现：

• 延迟降低：
  • 在所有实验配置（tinyFaaS 和 Kubernetes）中，端到端延迟平均降低了 26.33%。
  • 具体案例：IOT 应用在 tinyFaaS 上延迟从 807ms 降至 574ms (降低 28.9%)；TREE 应用从 452ms 降至 350ms (降低 22.6%)。
• 资源效率提升：
  • 平均 RAM 使用量减少了 53.57%。
  • 具体案例：IOT 应用 RAM 使用减少约 57%，TREE 应用减少约 50%。这是因为合并后减少了并发运行的容器实例数量。
• 稳定性：实验数据显示，融合后的应用在长期运行中表现出更稳定的延迟分布，且合并事件（Merge Events）完成后性能立即提升。

5. 意义与局限性 (Significance & Limitations)

意义

• 成本与性能双赢：为 FaaS 平台提供了一种无需开发者干预即可显著降低延迟和云成本的有效策略。
• 基础设施优化新范式：展示了通过基础设施层面的透明优化（如自动合并、预热等）来弥补 FaaS 固有开销的巨大潜力。
• 解决双重计费痛点：直接针对 FaaS 细粒度计费模型中的“双重计费”问题提供了解决方案。

局限性与未来工作

• 隔离性权衡：融合后的函数运行在共享环境中，降低了隔离性。因此，目前仅适用于同一信任域（同一用户/租户）内的函数。
• 适用场景：对于高度异步或非阻塞的工作负载，收益有限，因为优化效果依赖于同步调用链的存在。
• 代码模型限制：当前原型仅支持“自带函数代码 (Bring-Your-Own-Function-Code)"模型，尚不支持“自带容器 (Bring-Your-Own-Container)"模型，限制了第三方容器环境的优化。
• 语言支持：原型目前仅支持 Python，但架构设计允许扩展至其他语言。

总结：Provuse 证明了在 FaaS 平台侧自动执行函数融合是可行且高效的。它通过消除冗余的执行边界，在不增加开发者负担的前提下，显著提升了服务器端应用的性能和成本效益。