基於Pingora、Envoy和Spanner的無服務器服務器路由

Modal近日發佈了其新型Serverless Servers服務，旨在為超低延遲應用（如大型語言模型推理）提供支持。該服務允許用户在Modal上運行HTTP、WebSocket和gRPC服務器，並實現區域化自動縮放。

與Modal已有的Web Functions不同，Servers採用了更輕量級的架構。Web Functions內置了排隊和重試機制，類似於TCP協議；而Servers則更接近UDP，犧牲了這些可靠性特性以換取更低的延遲。如果所有副本都不可用，客户端將直接收到503錯誤，而不是等待隊列。這種設計對於LLM推理等對延遲極其敏感的應用場景尤為合適。

Modal團隊在構建Servers時遵循了兩條核心原則：最大化資源共享同時最小化干擾，以及確保請求路徑上沒有網絡調用。這意味着路由層不能訪問元數據存儲或鍵值存儲，配置信息必須本地緩存。團隊通過精細的微觀調整，將代理資源的使用與宏觀目標對齊，避免了因資源池化導致的干擾問題。

具體實現上，請求首先到達AWS NLB（四層負載均衡器），然後由Envoy代理終止TLS並統一轉換為HTTP/2流。接下來，Modal自研的fprs代理負責將域名映射到具體的Server應用，並在副本之間進行負載均衡。fprs基於CloudFlare的Pingora庫構建，利用Rust的Tokio運行時實現高效的流複用和資源隔離。團隊還解決了因域名頻繁更換導致的隱藏DNS解析問題，通過仔細緩存來保證尾延遲。

配置信息存儲在Google Spanner中，但fprs維護了一個內存緩存，並通過Spanner的變更流保持同步，從而避免了熱路徑上的數據庫查詢。該層還負責向Modal自動縮放器發送指標（每個容器的正在處理請求數），以及實現代理層身份驗證，防止大量無效請求觸發昂貴的GPU實例啓動。

Modal表示，雖然系統針對LLM推理進行了優化，但設計上並不侷限於這一場景。未來他們計劃在路由層添加可選的排隊和重試功能，讓用户能夠根據需求在低延遲和可靠性之間取得平衡。