原文連結
對雲端計算裡FaaS沒概念的同學可以看眼：FaaS
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 是否能減少對外部儲存的依賴。