​簡介：上文說到雲端計算的十餘年發展讓整個網際網路行業發生了翻天覆地的變化，Serverless 作為雲端計算的產物，或者說是雲端計算在某個時代的表現，被很多人認為是真正意義上的雲端計算，關於“Serverless 是什麼”這個問題，其實是可以通過不同角度來分析的。

作者 | 劉宇

前言

上文說到雲端計算的十餘年發展讓整個網際網路行業發生了翻天覆地的變化，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 = FaaS + BaaS 是一個被普遍認可的概念；從 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。

​

在這個架構下，服務端僅為雲伺服器，其承載了大量業務功能和業務邏輯，例如，系統中的大部分邏輯（身份驗證、頁面導航、搜尋、交易等）都在服務端實現。把它改造成 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 相關資源，如圖所示。

​

Azure Functions 也提供了 Visual Studio Code 外掛，如下圖所示。Visual Studio 中的 Azure Functions 專案模板可用於建立專案，建立的專案可釋出到 Azure 中的函式應用中。使用者可使用函式應用將函式分組為一個邏輯單元，以便於管理、部署和共享資源。​

阿里雲在開發者工具層面提供了 VSCode 外掛，如圖所示。

​

​

2、Serverless Workflow

Serverless Workflow（Serverless 工作流）是一個用來協調多個分散式任務執行的全託管雲服務。

如圖所示，在 Serverless 工作流中，使用者可以用順序、分支、並行等方式來編排分散式任務。Serverless 工作流會按照設定好的步驟可靠地協調任務，跟蹤每個任務的狀態轉換，並在必要時執行使用者定義的重試邏輯，以確保工作流順利完成。

Serverless 工作流通過提供日誌記錄和審計來監視任務的執行，方便使用者輕鬆地診斷和除錯應用。Serverless 工作流簡化了開發和執行業務流程所需要的任務協調、狀態管理以及錯誤處理等煩瑣的工作，讓使用者聚焦業務邏輯開發。

​

Serverless 工作流可以協調分散式元件編排不同基礎架構、不同網路、不同語言編寫的應用，抹平混合雲、專有云過渡到公共雲或者從單體架構演進到微服務架構的落差。Serverless 工作流提供了豐富的控制邏輯，例如順序、選擇、並行等，讓使用者以更少的程式碼實現 複雜的業務邏輯。Serverless 工作流為使用者管理流程狀態，提供內建檢查點和回放能力，以確保應用程式按照預期逐步執行。錯誤重試和捕獲可以讓使用者靈活地處理錯誤。Serverless 工作流根據實際執行步驟轉換個數收費，執行結束不再收費。Serverless 工作流自動擴充套件，讓使用者免於管理硬體預算和擴充套件。

Serverless 應用的可觀測性

Serverless 應用的可觀測性是被很多使用者所關注的。可觀測性是通過外部表現判斷系統內部狀態來衡量的。在應用開發中，可觀測性幫助使用者判斷系統內部的健康狀況，在系統出現問題時，幫助使用者定位問題、排查問題、分析問題；在系統平穩執行時，幫助使用者評估風險，預測可能出現的問題。在 Serverless 應用開發中，如果觀察到函式的併發度持續升高，很可能是業務推廣團隊努力工作使業務規模迅速擴張。為了避免達到併發度限制閾值，開發者就需要提前提升併發度。以阿里雲函式計算為例，阿里雲函式計算在可觀測性層面提供了多種維度，包括 Logging、Metric 以及 Tracing 等。

​

在控制檯監控中心，我們可以檢視整體的 Metric、服務級 Metric 以及每個函式的 Metric。除此之外，我們還可以看到當前函式的請求記錄。

​

根據不同的請求記錄，可以檢視到函式的詳細資訊，如圖所示。

​

除了在控制檯的監控中心處可以檢視到函式的日誌等資訊，我們在函式詳情頁面也可以看到函式的詳細日誌資訊。

​

Tracing 相關資訊如圖所示。

​

關於作者：

​

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​