作者 | 劉宇
前言
上文說到雲計算的十餘年發展讓整個網際網路行業發生了翻天覆地的變化，Serverless 作為雲計算的産物，或者說是雲計算在某個時代的表現，被很多人認為是真正意義上的雲計算，關于“Serverless 是什麼”這個問題，其實是可以通過不同角度來分析的。
Martin Fowler 在 “Serverless Architectures” 一文中從 Serverless 組成角度給出了 Serverless 的定義，他認為 Serverless 實際上是 BaaS 與 FaaS 的組合，并針對 BaaS 和 FaaS 進行了詳細的描述。
Serverless 最早用于描述那些大部分或者完全依賴于第三方（雲端）應用或服務來管理伺服器端邏輯和狀态的應用，這些應用通常是富用戶端應用（單頁應用或者移動端App），建立在雲服務生态之上，包括資料庫（Parse、Firebase）、賬号系統（Auth0、AWS Cognito）等。這些服務最早被稱為 Baas（Backend as a Service，後端即服務）。
Serverless 還可以指這種情況：應用的一部分服務端邏輯依然由開發者完成，但是和傳統架構不同，它運作在一個無狀态的計算容器中，由事件驅動，生命周期很短（甚至隻有一次調用），完全由第三方管理。這種情況被稱為 FaaS（Functions as a service，函數即服務）。AWS Lambda 是目前的熱門 FaaS 實作之一。
通過 Martin Fowler 的描述可以總結出 FaaS、BaaS 以及 Serverless 之間的關系為下圖所示。
Serverless 架構的組成
從 Serverless 的結構上來看，Serverless = FaaS + BaaS 是一個被普遍認可的概念；從 Serverless 的特性上來看，Serverless 運作在無狀态的計算容器中，由事件觸發，并且擁有彈性伸縮以及按量付費等能力，讓使用者不用花費更多的精力在伺服器上，而是更加關注業務本身。
不同角度上的 Serverless 的定義
Serverless 工作流程
在實際生産中，Serverless 架構通常都是 FaaS 與 BaaS 的結合，并且具備彈性伸縮和按量付費的特性。
當開發者想要開發一個項目的時候：
- 通常隻需要根據 FaaS 提供商所提供的 Runtime，選擇一個熟悉的程式設計語言，然後進行項目開發、測試（圖中步驟 1）
- 完成之後将代碼上傳到FaaS平台（圖中步驟 2）
- 上傳完成之後，隻需要通過 API/SDK；或者一些雲端的事件源（圖中步驟 3）
- 觸發上傳到 FaaS 平台的函數，FaaS 平台就會根據觸發的并發度等彈性執行對應的函數（圖中步驟 4）
- 最後使用者可以根據實際資源使用量進行按量付費（圖中步驟 5）
我們來看一個 Web 應用的例子。通常情況下一些 Web 應用都是傳統的三層 C/S 架構，例如一個常見的電子商務應用，假設它的服務端用 Java，用戶端用 HTML/JavaScript。
傳統 Web 應用三層 C/S 架構
在這個架構下，服務端僅為雲伺服器，其承載了大量業務功能和業務邏輯，例如，系統中的大部分邏輯（身份驗證、頁面導航、搜尋、交易等）都在服務端實作。把它改造成 Serverless 應用形态。
Serverless 應用形态簡圖
在 Serverless 應用形态下，移除了最初應用中的身份驗證邏輯，換用一個第三方的 BaaS 服務（上圖中步驟 1）；允許用戶端直接通路一部分資料庫内容，這部分資料完全由第三方托管，會用一些安全配置來管理用戶端通路相應資料的權限（上圖中步驟 2）；前面兩點已經隐含了非常重要的第三點：先前服務端的部分邏輯已經轉移到了用戶端，如保持使用者 Session、了解應用的 UX 結構、擷取資料并渲染出使用者界面等。
用戶端實際上已經在逐漸演變為單頁應用（上圖中步驟 3）；還有一些任務需要保留在伺服器上，比如繁重的計算任務或者需要通路大量資料的操作。這裡以“搜尋”為例，搜尋功能可以從持續運作的服務端中拆分出來，以 FaaS 的方式實作，從 API 網關（後文做詳細解釋）接收請求并傳回響應。這個服務端函數可以和用戶端一樣，從同一個資料庫讀取産品資料。原始的服務端是用 Java 寫的，而 AWS Lambda（假定用的這家 FaaS 平台）也支援 Java，那麼原先的搜尋代碼略作修改就能實作這個搜尋函數（上圖中步驟 4）；還可以把“購買”功能改寫為另一個 FaaS函數，出于安全考慮，它需要在服務端而非用戶端實作。它同樣經由API網關暴露給外部使用（上圖中步驟 5）。
在整個項目中，Serverless 使用者實際關心的也就隻剩下函數中的業務邏輯，至于身份驗證邏輯、API 網關以及資料庫等原先在服務端的一些産品/服務統統交給雲廠商提供。在整個項目開發、上線以及維護的過程中，使用者并不需要關注伺服器層面的維護，也無須為流量的波峰波谷進行運維資源的投入，這一切的安全性、彈性能力以及運維工作都交給雲廠商來統一處理/排程，使用者所需要關注的就是自己的業務代碼是否符合自己的業務要求，同時在 Serverless 架構下，使用者也無需為資源閑置進行額外的支出，Serverless 架構的按量付費模型以及彈性伸縮能力、服務端低運維/免運維能力，可以讓 Serverless 使用者的資源成本、人力成本、整體研發效能得到大幅度提升，讓項目的性能、安全性、穩定性得到極大的保障。
Serverless 的配套服務
1、開發者工具
Serverless 開發者工具包括指令行工具、編輯器插件以及其他工具。
一般情況下，指令行工具有廠商一方工具和開源建設的三方工具兩種，例如 AWS Lambda 的 SAM CLI、阿裡雲函數計算的 Funcraft 等就是典型的一方工具。這類工具的特點是和廠商、産品的比對度非常高，一些特性的支援比較迅速，缺點是比較保守。Serverless Devs、Serverless Framework 就是典型的三方工具，這兩個工具都支援 AWS Lambda、阿裡雲函數計算、騰訊雲雲函數等雲廠商的 FaaS 産品。
從用戶端表現上來看，其都是 Serverless 開發者工具，都是元件化的指令行工具，也都支援多雲；從形态上來看，Serverless Framework 更注重部署與運維方向， Serverless Devs 更注重 Serverless 應用的全生命周期。同時，Serverless Devs 相對 Serverless Framework 而言，增加了可視化界面。
Serverless Devs GUI 首頁
如圖所示，通過該界面，使用者可以快速地部署應用。
Serverless Devs GUI 可視化 Yaml 編輯頁
使用者可以快速地管理雲上 Serverless 相關資源，如圖所示。
Serverless Devs GUI 項目管理頁
Azure Functions 也提供了 Visual Studio Code 插件，如下圖所示。Visual Studio 中的 Azure Functions 項目模闆可用于建立項目，建立的項目可釋出到 Azure 中的函數應用中。使用者可使用函數應用将函數分組為一個邏輯單元，以便于管理、部署和共享資源。
Azure Functions 提供的 VSCode 插件
阿裡雲在開發者工具層面提供了 VSCode 插件，如圖所示。
同時，阿裡雲函數計算還提供了 Cloud Toolkit 工具，實作了在本地 Jet Brains IDE 中運作、下載下傳雲端函數，建立、上傳本地函數。以 IntelliJ IDEA 為例，其函數管理界面如下圖所示。
阿裡雲函數計算 VSCode 插件函數管理界面
2、Serverless Workflow
Serverless Workflow（Serverless 工作流）是一個用來協調多個分布式任務執行的全托管雲服務。
如圖所示，在 Serverless 工作流中，使用者可以用順序、分支、并行等方式來編排分布式任務。Serverless 工作流會按照設定好的步驟可靠地協調任務，跟蹤每個任務的狀态轉換，并在必要時執行使用者定義的重試邏輯，以確定工作流順利完成。
Serverless 工作流通過提供日志記錄和審計來監視任務的執行，友善使用者輕松地診斷和調試應用。Serverless 工作流簡化了開發和運作業務流程所需要的任務協調、狀态管理以及錯誤處理等煩瑣的工作，讓使用者聚焦業務邏輯開發。
Serverless 工作流示例
Serverless 工作流可以協調分布式元件編排不同基礎架構、不同網絡、不同語言編寫的應用，抹平混合雲、專有雲過渡到公共雲或者從單體架構演進到微服務架構的落差。Serverless 工作流提供了豐富的控制邏輯，例如順序、選擇、并行等，讓使用者以更少的代碼實作 複雜的業務邏輯。Serverless 工作流為使用者管理流程狀态，提供内置檢查點和回放能力，以確定應用程式按照預期逐漸執行。錯誤重試和捕獲可以讓使用者靈活地處理錯誤。Serverless 工作流根據實際執行步驟轉換個數收費，執行結束不再收費。Serverless 工作流自動擴充，讓使用者免于管理硬體預算和擴充。
Serverless 應用的可觀測性
Serverless 應用的可觀測性是被很多使用者所關注的。可觀測性是通過外部表現判斷系統内部狀态來衡量的。在應用開發中，可觀測性幫助使用者判斷系統内部的健康狀況，在系統出現問題時，幫助使用者定位問題、排查問題、分析問題；在系統平穩運作時，幫助使用者評估風險，預測可能出現的問題。在 Serverless 應用開發中，如果觀察到函數的并發度持續升高，很可能是業務推廣團隊努力工作使業務規模迅速擴張。為了避免達到并發度限制門檻值，開發者就需要提前提升并發度。以阿裡雲函數計算為例，阿裡雲函數計算在可觀測性層面提供了多種次元，包括 Logging、Metric 以及 Tracing 等。
函數計算可觀測性整體圖表
在控制台監控中心，我們可以檢視整體的 Metric、服務級 Metric 以及每個函數的 Metric。除此之外，我們還可以看到目前函數的請求記錄。
函數計算可觀測性函數請求記錄
根據不同的請求記錄，可以檢視到函數的詳細資訊，如圖所示。
函數計算可觀測性請求級記錄詳細資訊
除了在控制台的監控中心處可以檢視到函數的日志等資訊，我們在函數詳情頁面也可以看到函數的詳細日志資訊。
函數計算日志檢視
Tracing 相關資訊如圖所示。
函數計算可觀測性 Tracing 相關資訊
關于作者：
劉宇（江昱）國防科技大學電子資訊專業在讀博士，阿裡雲 Serverless 産品經理，阿裡雲 Serverless 雲布道師，CIO 學院特聘講師。
新書推薦
本書會通過多個開源項目、多個雲廠商的多款雲産品，以及多種途徑向讀者介紹什麼是 Serverless 架構、如何上手 Serverless 架構、不同領域中 Serverless 架構的應用以及如何從零開發一個 Serverless 應用等。本書可以幫助讀者将 Serverless 架構融入到自己所在的領域，把 Serverless 項目真實落地，獲得 Serverless 架構帶來的技術紅利。
立刻點選購買：
http://product.m.dangdang.com/29250860.html?unionid=P-113341856m-:-dd_1