前言

上文說到云計算的十余年發展讓整個互聯網行業發生了翻天覆地的變化，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）

Serverless 工作流程

我們來看一個 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 相關信息