1.1　Serverless的定義

1.1.1　廣義定義探索

云計算的十余年發展讓整個互聯網行業發生了翻天覆地的變化，而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之間的關系，如圖1-1所示。

云原生計算基金會（下文簡稱CNCF）則從Serverless的特征特性角度給出了Serverless的定義：Serverless是指構建和運行不需要服務器管理的應用程序。它描述了一種更細粒度的部署模型，即將應用程序打包為一個或多個功能，上傳到平臺，然后執行、擴展和計費，以響應當時確切的需求。

同時CNCF也強調了，Serverless所謂的“無服務器”并不是“沒有服務器”，而是說Serverless的用戶不再需要在服務器配置、維護、更新、擴展和容量規劃上花費時間和資源，可以將更多的精力放到業務邏輯本身，至于服務器，則“把更專業的事情交給更專業的人”去做，即由云廠商來提供統一的運維。

在信通院云原生產業聯盟所發布的《云原生發展白皮書（2020年）》中對Serverless也有相關的描述：Serverless是一種架構理念，其核心思想是將提供服務資源的基礎設施抽象成各種服務，以API接口的方式供用戶按需調用，真正做到按需伸縮、按使用收費。這種架構消除了對傳統的海量持續在線服務器組件的需求，降低了開發和運維的復雜性，降低了運營成本并縮短了業務系統的交付周期，使得用戶能夠專注在價值密度更高的業務邏輯的開發上。

如圖1-2所示，從Serverless的結構上來看，Serverless = FaaS + BaaS是一個被普遍認可的概念；從Serverless的特性上來看，Serverless運行在無狀態的計算容器中，由事件觸發，并且擁有彈性伸縮以及按量付費等能力，讓使用者不用花費更多的精力在服務器上，而是更加關注業務本身。

1.1.2　Serverless工作流程

在實際生產中，Serverless架構通常都是FaaS與BaaS的結合，并且具備彈性伸縮和按量付費的特性。如圖1-3所示，當開發者想要開發一個項目的時候，通常只需要根據FaaS提供商所提供的Runtime，選擇一個熟悉的編程語言，然后進行項目開發、測試（圖中步驟1）；完成之后將代碼上傳到FaaS平臺（圖中步驟2）；上傳完成之后，只需要通過API/SDK（圖中步驟3）或者一些云端的事件源（圖中步驟3）觸發上傳到FaaS平臺的函數，FaaS平臺就會根據觸發的并發度等彈性執行對應的函數（圖中步驟4），最后用戶可以根據實際資源使用量進行按量付費（圖中步驟5）。

我們來看一個Web應用的例子。如圖1-4所示，通常情況下一些Web應用都是傳統的三層C/S架構，例如一個常見的電子商務應用，假設它的服務端用Java，客戶端用HTML/JavaScript。

在這個架構下，服務端僅為云服務器，其承載了大量業務功能和業務邏輯，例如，系統中的大部分邏輯（身份驗證、頁面導航、搜索、交易等）都在服務端實現。把它改造成Serverless應用形態，簡圖如圖1-5所示。

在Serverless應用形態下，移除了最初應用中的身份驗證邏輯，換用一個第三方的BaaS服務（圖中步驟1）；允許客戶端直接訪問一部分數據庫內容，這部分數據完全由第三方托管，會用一些安全配置來管理客戶端訪問相應數據的權限（圖中步驟2）；前面兩點已經隱含了非常重要的第三點：先前服務端的部分邏輯已經轉移到了客戶端，如保持用戶Session、理解應用的UX結構、獲取數據并渲染出用戶界面等。客戶端實際上已經在逐步演變為單頁應用（圖中步驟3）；還有一些任務需要保留在服務器上，比如繁重的計算任務或者需要訪問大量數據的操作。這里以“搜索”為例，搜索功能可以從持續運行的服務端中拆分出來，以FaaS的方式實現，從API網關（后文做詳細解釋）接收請求并返回響應。這個服務端函數可以和客戶端一樣，從同一個數據庫讀取產品數據。原始的服務端是用Java寫的，而AWS Lambda（假定用的這家FaaS平臺）也支持Java，那么原先的搜索代碼略作修改就能實現這個搜索函數（圖中步驟4）；還可以把“購買”功能改寫為另一個FaaS函數，出于安全考慮，它需要在服務端而非客戶端實現。它同樣經由API網關暴露給外部使用（圖中步驟5）。

在整個項目中，Serverless用戶實際關心的也就只剩下函數中的業務邏輯，至于身份驗證邏輯、API網關以及數據庫等原先在服務端的一些產品/服務統統交給云廠商提供。在整個項目開發、上線以及維護的過程中，用戶并不需要關注服務器層面的維護，也無須為流量的波峰波谷進行運維資源的投入，這一切的安全性、彈性能力以及運維工作都交給云廠商來統一處理/調度，用戶所需要關注的就是自己的業務代碼是否符合自己的業務要求，同時在Serverless架構下，用戶也無需為資源閑置進行額外的支出，Serverless架構的按量付費模型以及彈性伸縮能力、服務端低運維/免運維能力，可以讓Serverless用戶的資源成本、人力成本、整體研發效能得到大幅度提升，讓項目的性能、安全性、穩定性得到極大的保障。