2026 年 Serverless 2.0 架構：冷啟動優化與有狀態（Stateful）函數應用
第一，重放不等於重試。持久化執行在恢復時會重放已完成的步驟，但如果某個步驟有副作用（例如發送 Email、呼叫外部 API），你必須確保這個副作用只發生一次。標準做法是把副作用包在冪等鍵後面，或把副作用本身也註冊成一個獨立的 step。
第二，狀態遷移的斷點。當執行個體被回收、Actor 被遷移時，記憶體中尚未同步的狀態可能遺失。平台通常提供「同步寫入」與「非同步寫入」兩種模式，前者保證不丟但延遲高，後者反過來。你必須根據業務需求明確選擇，而不是採用預設值。
第三，時鐘與版本。狀態可能跨越很長的時間，而程式碼會被部署新版本。當一個舊狀態被新版本程式碼恢復時，schema 相容性就變成問題。成熟的做法是為狀態加上版本號與遷移函式，並在部署流程中把狀態遷移當成一個獨立階段來處理。
四、實戰參考架構：把冷啟動與有狀態串成一條線
講完理論，我們來看一個具體的參考架構。假設你要打造一個「AI 協作筆記應用」，功能包含：多人即時編輯、AI 摘要與問答、版本歷史、以及跨裝置同步。這個場景同時踩中冷啟動與有狀態兩個痛點，很適合用來示範。
第一層：連線與會話層。每個筆記房間對應一個 Actor 執行個體，負責維護 WebSocket 連線、游標位置、線上使用者清單。這一層用會話親和路由，狀態存在 Actor 記憶體中，背景同步到持久層。因為連線是長命的，執行個體不會頻繁重啟，冷啟動問題在這層幾乎不存在。
第二層：編輯操作層。使用者的每一次編輯透過 WebSocket 送到 Actor，Actor 負責套用 Operational Transform 或 CRDT 邏輯，並把變更廣播給同房間的其他使用者。這層的重點是低延遲與順序保證，因此計算與狀態必須共置。
第三層：AI 處理層。AI 摘要與問答是 CPU/GPU 密集且突發性強的任務，適合用無狀態函數處理。這裡就是冷啟動優化的主戰場：把模型載入放進快照、用預測性預熱應對使用者活躍時段、把推論邏輯與模型權重分離以縮小部署包。
第四層：工作流層。版本歷史的快照、週期性的全文索引重建、以及跨裝置的同步通知，這些是多步驟且需要可靠性的流程，用持久化執行來表達最自然。
這個架構的關鍵在於：不是所有東西都要有狀態，也不是所有東西都要優化冷啟動。把對的負載放到對的模型上，才是 Serverless 2.0 的正確用法。連線密集、狀態高頻讀寫的放 Actor；突發、無共享的放無狀態函數；長流程、需要可靠性的放持久化執行。
五、成本、維運與可觀測性的新課題
Serverless 2.0 讓架構更優雅，但成本模型與維運複雜度並沒有消失，只是換了形狀。
成本結構的改變。1.0 時代的帳單主要看「請求次數 × 執行時間 × 記憶體」。2.0 時代多了三項新變數：預熱執行個體的常駐成本、狀態儲存的容量與讀寫成本、以及快照的儲存與傳輸成本。有狀態函數意味著執行個體活得更久、記憶體佔用更多，單位成本不一定比無狀態低。實務上，你應該用「每千次業務操作的總成本」來評估，而不是只看單次呼叫的價格。
可觀測性的難度提升。無狀態函數的追蹤相對簡單：一次請求一條 trace。有狀態函數則會跨越多次請求、多次執行個體恢復、甚至多個版本部署。你需要的觀測能力包括：狀態檢查點的時間軸視圖、執行個體生命週期事件（建立、快照、恢復、遷移、終止）、以及狀態版本與程式碼版本的對應關係。OpenTelemetry 在 2026 年已經有針對持久化執行的語意約定，建議在架構初期就把追蹤埋點設計好，否則事後補救會非常痛苦。
除錯範式的轉變。傳統除錯是「重現問題、設定斷點、觀察變數」。有狀態函數的除錯更像是「從事件日誌重建狀態、找出哪一步的輸入與預期不符」。這意味著團隊需要建立新的除錯流程與工具鏈，包括狀態快照的下載與本地重放能力。這也是 2026 年各家平台正在競爭的差異化功能之一。
安全邊界的重新劃分。當執行個體持有使用者狀態、甚至持有資料庫連線時，多租戶隔離的壓力就變大。你需要確認平台在快照儲存、狀態傳輸、以及執行個體復用時都提供了足夠的隔離保證。對於處理敏感資料的場景，建議把狀態加密與金鑰管理納入架構設計，而不是依賴平台預設。
六、2026 年的產業落地場景
最後，讓我們看看哪些場景在 2026 年已經真正落地，哪些還在觀望。
已經成熟的場景：即時協作工具（筆記、白板、設計稿）、多人線上遊戲的房間伺服器、IoT 裝置影子與規則引擎、電商的購物車與庫存預留、以及金融業的對帳與清算工作流。這些場景的共同點是：狀態讀寫頻繁、延遲敏感、且業務流程本身就有明確的狀態機結構。
快速成長的場景：AI Agent 的任務執行框架。一個 Agent 可能要歷經規劃、工具呼叫、結果評估、修正等多輪迴圈，中間還可能等待人類審批。這正是持久化執行的完美舞台——每一步都是可恢復的檢查點，Agent 不會因為執行個體被回收而丧失進度。2026 年已經有大量 Agent 框架原生支援這種執行模型。
仍在評估的場景：大型關聯式資料庫的交易型核心系統。這類系統對一致性、延遲與除錯能力的要求極高，目前多數團隊仍選擇保留在容器或虛擬機上，只在邊緣業務使用 Serverless。不過隨著狀態語意與可觀測性的成熟，這個邊界正在逐年鬆動。
七、結語：Serverless 不是消失的伺服器，而是重新定義的伺服器
回頭看這十年的演進，Serverless 這個名字其實有點誤導。它從來不是「沒有伺服器」，而是「把伺服器的管理責任重新分配」。1.0 時代，平台接管了資源調度，開發者則被迫接管所有狀態管理；2.0 時代，這個分工被重新談判——平台開始承擔狀態的持久化、恢復與路由，開發者則專注在業務語意與生命週期策略上。
冷啟動優化與有狀態函數，是這場重分配裡的兩個關鍵支柱。前者讓執行環境變得可預測，後者讓執行模型變得可表達。當這兩件事同時成立，Serverless 才真正從「適合做小事的技術」變成「可以承載核心業務的架構」。
如果你正在規劃 2026 年的系統架構，我會建議你從三個問題開始思考：第一，我的業務流程裡，哪些狀態是真正需要與計算共置的？第二，哪些延遲是我可以接受的，哪些是必須壓到毫秒級的？第三，我願不願意為了狀態語意而接受更高的單位成本與更複雜的觀測需求？把這三個問題回答清楚，你自然會知道什麼該上 Serverless、什麼該留在原地。
技術的選擇從來不是非黑即白。Serverless 2.0 提供的，是一組更細緻的工具，讓你可以在同一個系統裡，為不同的負載選擇最合適的執行模型。能不能用好，取決於你對自己業務狀態的理解深度，而不是你選了哪一家雲廠商。