在上一篇文章中，我們探討了 Serverless 的底層運作機制。簡單來說，Serverless 利用分層調度與快速的冷啟動，讓它在沒有事件處理時可以縮減至零。這就像一個聲控燈，有人時亮起，房間空無一人時自動關閉。
了解了基本概念後，你可能會好奇這項令人驚豔的技術的實際應用。今天，我們將深入探討 Serverless 的使用案例。然而，理解其應用的前提是了解它的程序模型，這是一個與冷啟動同樣重要的概念。
Serverless 程序模型
讓我們回顧上一期的 Serverless 冷啟動過程。請記住，雲端供應商管理容器和執行環境準備階段，我們只需專注於函數執行。在 Serverless 領域中，函數執行由「函數服務」處理。當函數觸發器通知「事件」到來時，函數服務會按需建立函數實例並執行對應的函數。一旦函數執行完畢，其關聯的實例便退出，使 Serverless 應用程式能縮減至零，進入省電模式。
現在，你可能會想，是否可以在函數執行後保持實例存活，而不是終止它，讓它等待下一次函數調用？這樣可以避免每次的冷啟動開銷，從而實現更快的回應時間。
確實，Serverless 預見了這樣的情境。因此，從運行函數實例的程序角度來看，有兩種模式：
- 執行即結束 (Run-to-Completion)：在此模式下，函數實例準備好後，執行函數並立即終止。這是 Serverless 最純粹的使用方式。
- 持久化程序 (Persistent Process)：在此模式下，函數實例準備好後，不會在函數執行完畢後停止。它會返回並耐心等待下一次函數調用。請注意，即使在此模式下，如果一段時間內沒有事件觸發，雲端供應商最終仍會銷毀該函數實例。
資料編排
大部分工程師都熟悉 MVC（Model-View-Controller）模式，這是一種非常成功的設計範式。然而，前端 MVVM 框架的崛起推動了 View 層的發展，催生了 SPA（單頁應用）。與此同時，後端的 Control 層和 Model 層向下沉，形成了面向服務的後端應用程式。
這種轉變導致了前端與後端更徹底的解耦。前端開發可以依賴模擬資料介面獨立進行，而後端團隊則可以專注於資料介面的開發。然而，這種分離引入了一個具有高網路 I/O 的數據網關層。
Node.js 憑藉其非同步非阻塞的特性以及 JavaScript 對前端工程師的親和力，自然而然地承擔起了數據網關層的職責。這導致了 Node.js BFF（Backend For Frontend）層的出現，它編排後端資料與介面，將其調整為適合前端消費的資料結構。
BFF 層作為中間層，橋接了前端與後端。未處理的數據（通常稱為原始數據或元數據）對最終用戶來說幾乎不可讀。因此，我們需要組合和處理相關數據，增加價值並使其有意義。這個組合與處理的過程稱為資料編排。
傳統上，為 BFF 層管理 Node.js 應用程式需要大量資源，需要虛擬機或 PaaS 平台。然而，由於 BFF 層主要執行無狀態的資料編排，我們可以使用「執行即結束」模式的 Serverless 無縫取代 Node.js 應用程式。這就是越來越流行的術語 SFF（Serverless For Frontend）的本質。
了解了從 BFF 到 SFF 的演進後，讓我們追蹤新的請求流程。當前發起數據請求時，函數觸發器會啟動我們的函數服務。我們的函數啟動，調用後端的元數據介面，處理返回的元數據，將其轉換為前端所需的格式，最後我們的 Serverless 函數便可以好好休息了。
服務編排
服務編排與資料編排相似，主要區別在於它專注於組合和處理雲端供應商提供的各種服務。雖然這個概念在 Serverless 出現之前就已存在，但其實現傳統上受到服務支援的 SDK 語言版本的限制。通常我們會使用 YAML 檔案或命令列介面來編排服務。使用這些服務或 API 需要找到我們偏好的程式語言中的對應 SDK，將其載入到程式碼中，並使用秘密金鑰來呼叫 SDK 方法進行編排。與資料編排類似，後端操作和部署成本高昂，而且如果沒有 SDK，就需要根據平台的介面或協定手動實作。
Serverless 擴展了 SDK 的使用邊界。例如，想像一個需要透過電子郵件發送驗證碼的 Web 服務。我們可以使用一個「執行即結束」的 Serverless 函數，利用雲端供應商的 SDK 來發送郵件。同時，一個持久化的 Serverless 函數可以產生隨機字串驗證碼，儲存起來，並觸發發送郵件的 Serverless 函數將驗證碼送到用戶信箱。在驗證時，我們可以再次調用持久化的 Serverless 函數來驗證驗證碼。
Serverless 的一個顯著優勢是其語言無關性。這使得開發團隊不再受限於單一語言，可以利用 Java、PHP、Python、Node.js 等語言的優勢，協作構建複雜的應用程式。
Serverless 服務編排的開放性引起了雲端供應商的極大關注。它可以創建各種複雜的服務編排場景，同時保持語言無關，顯著擴展了各種雲端服務的使用案例。然而，這也要求開發者熟悉所選雲端供應商提供的各種服務。
結論
- Serverless 有兩種程序模型：常駐程序型與用完即棄型。常駐程序型是為了適應傳統 MVC 架構而設計的，看起來不太自然；如果你現在才開始使用 Serverless，我絕對推薦使用用完即棄模型，這樣可以最大化 Serverless 的優勢。
- 追溯歷史，我梳理了透過前後端分離發展出的 BFF，然後可以用 SFF 取代。無論是內部介面編排還是外部資料編排，Serverless 都能發揮巨大優勢。
- 從資料編排更進一步，我們可以借助 Serverless 和雲端服務提供者的能力來實現服務編排，創造更強大的複合服務場景，提升我們的研發效率。
Novita AI 是一個一站式雲端平台，助力您的 AI 抱負。整合 API、無伺服器、GPU 執行個體——您所需的經濟高效工具。告別基礎設施，免費開始，讓您的 AI 願景成真。
推薦閱讀
