無伺服器
2016 年 6 月 20 日
無伺服器架構是基於網路的系統,其應用程式開發不使用一般的伺服器程序。相反地,它們僅依賴第三方服務、用戶端邏輯和服務主機遠端程序呼叫 (FaaS) 的組合。

無伺服器應用程式通常會廣泛使用第三方服務來完成傳統上由伺服器處理的任務。這些服務可能是相互操作的豐富服務生態系統,例如 Amazon AWS 和 Azure,或者它們可能是嘗試提供一組交鑰匙功能的單一服務,例如 Parse 或 Firebase。這些服務提供的抽象可能是基礎架構(例如訊息佇列、資料庫、邊緣快取…)或較高層級(聯合身分、角色和功能管理、搜尋…)。
基於伺服器的通用網頁應用程式的首要責任之一是控制請求回應週期。伺服器端的控制器處理輸入、呼叫適當的應用程式行為並建構動態回應,通常使用範本引擎。在無伺服器應用程式中,應用程式行為由第三方服務交織在一起,用戶端控制流程和動態內容產生取代了伺服器端控制器。豐富的 JavaScript 應用程式、行動應用程式(以及越來越多的電視或嵌入式 IoT 應用程式)透過進行 API 呼叫並使用用戶端 UI 架構產生動態內容,來協調各種服務之間的互動。
基於伺服器的 Web 應用程式最實質的部分是控制器與基礎架構之間發生的工作,也就是業務邏輯。長駐伺服器會主機實作此邏輯的程式碼,並在應用程式存活期間執行所需的處理。在無伺服器應用程式中,自訂程式碼元件的生命週期較短,更接近單一 HTTP 要求/回應週期的時間軸。當要求抵達時,程式碼會啟動,處理要求,並在活動停止後立即進入休眠狀態。此程式碼通常存在於受控環境中,例如 Amazon Lambda、Azure Function 或 Google Cloud Functions,這些環境會負責程式碼的生命週期管理和縮放。(這種組織軟體的方式有時稱為 「Function as a Service」- FaaS。)每個要求的短生命週期也適用於每個要求的定價模式,這會為某些團隊帶來顯著的成本節省。[1]
一種新的風格,一套新的權衡
所有設計都是關於權衡。以這種風格建置的應用程式有一些顯著的優點,當然也有一些問題。
最常被斷言的好處是成本。在具有突發流量模式的系統中,為了容納突發流量而讓強大的伺服器大部分時間處於閒置狀態的成本既浪費又昂貴。基於雲端基礎架構服務的需求定價模式可以為必須處理這種類型流量的團隊提供顯著的成本降低。此外,在傳統的基於伺服器的應用程式中,應用程式的可擴充性和所有相關的基礎架構元件都是開發團隊的責任。這通常比使用在透過 URL 可用的 API 的簡單抽象背後透明縮放的服務更困難。因此,團隊通常會發現無伺服器應用程式可以更容易地擴充。
另一方面,也有一些新的成本。將單一應用程式概念性地分割成由服務結構編織而成的東西的開銷很大,而且會隨著所使用的服務數量和種類而增加。當應用程式有重要的部分在外部服務中實作和執行時,本機開發和單元測試也更困難。團隊通常會使用 廣泛堆疊測試 和 語義監控 在某種程度上抵銷這一點。
最後,無伺服器系統被認為有一個好處,那就是更容易操作和維護。第三方服務會在安全性、可用性、可擴充性和效能上投入大量資源。這些事情通常需要專業技能,而且可能不在小型開發團隊的職責範圍內。但這並不表示團隊可以忘記運作。開發團隊仍然有責任處理服務中斷、停機、停用和速度變慢所造成的問題,並防止這些問題對自己的應用程式產生連鎖影響。
進一步閱讀
Mike Roberts 正在撰寫一篇關於無伺服器架構的更詳細文章,其中包含範例、權衡利弊的進一步詳細資料,並與類似樣式進行對比。
Patrick Debois 在2016 年無伺服器大會的演講中,進一步探討無伺服器架構運作的現實面。
致謝
我要感謝 Martin Fowler 在插圖、編輯建議和本文指導上的協助。此外,非常感謝 Mike Roberts、Paul Hammant 和 Ken McCormack 的意見,以及 Chris Turner、Ian Carvell、Patrick Debois 和 Jay Sandhaus 抽空討論他們建構無伺服器應用程式的經驗。Jean-Noël Rouvignac 提醒我一些拼字錯誤。