Abstract
细粒度的无服务器函数为许多新应用提供了动力，这些应用受益于弹性扩展和按需付费计费模型，同时将基础设施管理开销降至最低。为了实现这些特性，函数即服务（FaaS）平台将计算和状态分离，PraaS 通过提供数据本地性、快速调用和高效通信改进了当前的 FaaS
1 Introduction
无服务器架构中数据与计算的分离从根本上讲是低效的，无法通过将 FaaS 与额外的远程云系统组合来解决。相反，我们引入了一个新的抽象概念：云进程。类似于使用线程进行并发计算的操作系统进程一样，云进程在单个机器上运行，并在共享环境中启动函数（在这里，一次函数调用相当于一次线程操作系统调用）。该进程提供了一个持久状态，函数可以使用它来缓存存储数据、保留用户会话、缓存结果以及保存调用工件，PraaS 遵循传统的操作系统设计，并透明地交换由用户定义的持久对象和文件组成的状态，将其存储在磁盘和云存储中。一旦相同进程的实例变得活跃，状态就会延迟加载到内存中。进程间通信定义了一个简单而强大的消息传递接口，仅基于两个操作：发送和接收
2 MOTIVATION
2.1 Serverless State
FaaS 的无状态特性使得云提供商更易于扩展和管理资源，但同时限制了对状态数据的访问效率。由于计算资源是临时的，无法跨调用保留数据，因此许多需要状态的应用必须将数据存储在远程云存储中，这会增加延迟并降低性能。已有方法通过自动管理的缓存保存数据，但这些方法仅支持远程存储且不适用于冷启动。此外，研究人员通过分组和数据流模型优化调用的局部性，但只能在热实例中保持数据，并不能解决缩容时数据丢失的问题
2.2 Serverless Communication
FaaS 中的通信一直受到限制，因为工业产品不提供直接的通信，迫使用户依赖存储或代理通信------这是一种具有高延迟且缺乏可移植 API 的昂贵解决方案
2.3 Serverless Control and Data Planes
现代无服务器平台采用集中式路由系统管理函数的动态放置，例如 AWS Lambda 和 OpenWhisk。调用请求需要经过多个步骤，包括授权、资源分配和路由。每次请求必须通过前端服务器、控制器和负载均衡等多个中介步骤，增加了延迟和复杂性，在当前的 FaaS 模型中，函数容器在处理请求时处于"独占"状态，直到处理完成为止，无法接收新请求。虽然这种模式适用于计算密集型任务，但对于 I/O 密集型任务来说并不高效
3 CLOUD PROCESSES
第一张图描述了 PraaS 云进程的结构，第二张图展示了云进程的生命周期，包括不同状态的转换
3.1 Locality with State
状态语义：进程的状态有一部分需要本地保留，以确保低访问延迟。当进程沙箱被移除时，持久数据不会消失。进程中的函数可以共享状态对象，提升数据本地性，实现缓存功能，从而减少请求处理时间和数据重新加载成本。
单租户设计：PraaS 进程设计为单租户，所有函数共享同一个状态数据。处理不同用户数据的函数需要逻辑隔离，以确保安全性和数据隔离。
交换机制：PraaS 引入了状态交换机制，当进程处于空闲或需要释放资源时，其状态会被交换到持久存储中，但仍保留激活的可能性。当进程重新激活时，状态可以被加载回来。这种机制允许进程在需要时恢复状态，而不会增加传统无服务器模型的限制。
3.2 Invocations with Control and DataPlanes
FaaS 的简单性依赖于自动扩展，对于没有自定义调度策略的应用程序，进程必须支持相同的模型。因此，可以通过控制平面调用函数，调用请求可以提供进程 ID 以提示系统将调用分配到哪个进程。编排器和负载均衡器可以通过数据平面（进程间通信）发送有效负载来更高效地调用函数，我们流程背后的基本假设是，它永远不会超出单个服务器的规模，因为这种设计从根本上简化了内存和状态的处理
3.3 Process Model with Communication
与 FaaS 相比，在云进程中执行的函数仅需使用六个新的原语就能受益于本地状态和快速通信（清单 1）。我们定义了两个消息传递例程，以实现进程处理的所有通信任务
4 PRAAS: PROCESS--AS--A--SERVICE
4.1 Process Managemen
在 PraaS 中，进程被分组以创建可扩展的应用程序，跨越多个服务器，与 FaaS 不同的是，用户可以通过在请求标头中提供进程标识符 pid 来控制调用路由到选定的进程实例。因此，进程可用于实现粘性会话，即单个用户的请求始终由同一个进程处理
4.2 Inter-Process Communication
PraaS 通过将邮箱和通道绑定到流程实例上，提供高效且分散的通信。在应用程序中，流程知道彼此的存在，并且可以直接通信。不是通过云代理在函数之间移动数据，而是在希望通信的承载函数的云流程之间传输数据，从而提高性能并减少网络通信量
4.3 Function Invocations over Data Plane
在 FaaS 中，每次调用通常都需要授权、资源分配和重定向等操作，导致重复的控制操作。当多个请求进入同一个热容器时，这些控制操作可能是多余的。PraaS 利用数据平面将调用直接传送到目标进程，从而跳过不必要的控制步骤。有效负载直接从用户传递到进程邮箱，减少了延迟，提高了调用的吞吐量，PraaS 支持复杂的无服务器工作流，如函数链接、条件调用和输入批处理等。传统 FaaS 需要外部编排器和服务触发器来处理这些复杂交互
5 PRAAS IN PRACTICE
主原型实现：PraaS 通过自定义控制平面实现，运行在 AWS Fargate 上。Fargate 提供了按需分配的无服务器容器，允许附加公共 IP 地址，这对直接通信至关重要。这个实现包含了约11,500行的 C++ 和 Python 代码，并使用 Python 运行时提供额外的进程支持。内部通信通过 TCP 传输二进制序列化消息，使用 C++ SDK 来简化数据平面和控制平面的通信。
Kubernetes 实现：为进一步展示兼容性，PraaS 被扩展至 Kubernetes 和 Knative。在此实现中，控制平面管理进程作为 pods，并在 Redis 实例中存储应用和进程信息。缩容策略则是基于数据平面活动的阈值，而非随机终止容器。此外，PraaS 的通信层基于 WebSockets 实现，并引入了函数存储机制，用户可以上传作为 Python wheels 的函数，并在进程中动态安装。
EVALUATION
延迟测试：评估函数调用的延迟，主要比较了 PraaS 和 AWS Lambda 在远程和本地调用中的延迟表现
进程状态的存取速度测试：测试 PraaS 的本地持久状态的访问速度，并将其与 Redis 和 S3 存储的访问速度进行比较。测试场景包括数据写入和读取操作
LaTeX 微服务案例测试：模拟一个类似 Overleaf 的 LaTeX 微服务环境，对比 PraaS 和 Lambda 的性能。测试重点在于 PraaS 的本地状态如何提升增量编译的速度，以及在文件获取时的效率
机器学习 K-Means 算法测试：将 PraaS 应用于分布式机器学习中的 K-Means 算法，测试其在大量数据交互下的表现。对比 PraaS 和 Knative 的数据传输和处理速度，尤其关注 PraaS 是否能减少对外部存储的依赖。