**作者 | Hongqi 阿里雲高階技術專家**

# 究竟什麼是 Serverless 架構？

什麼是 Serverless 架構？按照 CNCF 對 Serverless 計算的定義，Serverless 架構應該是採用 FaaS（函式即服務）和 BaaS（後端服務）服務來解決問題的一種設計。這個定義讓我們對 Serverless 的理解稍顯清晰，同時可能也造成了一些困擾和爭論。

-   隨著需求和技術的發展，業界出現了一些 FaaS 以外的其它形態的 Serverless 計算服務，比如 Google Cloud Run，阿里雲推出的面向應用的 Serverless 應用引擎服務以及 Serverless K8s，這些服務也提供了彈性伸縮能力和按使用計費的收費模式，具備 Serverless 服務的形態，可以說進一步擴大了 Serverless 計算的陣營；  
    
-   為了消除冷啟動影響，FaaS 類服務如阿里雲的函式計算和 AWS 的 Lambda 相繼推出了預留功能，變得不那麼“按使用付費”了；  
    
-   一些基於伺服器（Serverful）的後端服務也推出了 Serverless 形態產品，比如 AWS Serverless Aurora，阿里雲 Serverless HBase 服務。

這樣看來，Serverless 的界線是有些模糊的，諸多雲服務都向著 Serverless 方向演進。一個模糊的東西如何指導我們解決業務問題呢？Serverless 有一個根本的理念是一直沒有改變的，即讓使用者最大化地專注業務邏輯，其它的特徵如不關心伺服器、自動彈性、按使用計費等，都是為了實現這個理念而服務。

著名的 Serverless 實踐者 Ben Kehoe 這樣描述 Serverless 原生心智，當我們在業務中考慮做什麼時可以體會一下這種心智：

-   我的業務是什麼？  
    
-   做這件事情能不能讓我的業務出類拔萃？  
    
-   如果不能，我為什麼要做這件事情而不是讓別人來解決這個問題？  
    
-   在解決業務問題之前沒有必要解決技術問題。

在實踐 Serverless 架構時，最重要的心智不是選擇哪些流行服務和技術，攻克哪些技術難題，而是時刻將專注業務邏輯銘記在心，這樣更容易讓我們選擇合適的技術和服務，明確如何設計應用架構。人的精力是有限的，組織的資源是有限的，Serverless 的理念可以讓我們更好地用有限的資源解決真正需要解決的問題，正是因為我們少做了一些事情，轉而讓別人做這些事情，我們才可以在業務上做的更多。

接下來我們介紹一些常見的場景，並探討如何使用 Serverless 架構支援這些場景。我們主要會採用計算、儲存和訊息通訊等技術來設計架構，從可運維性、安全性、可靠性、可擴充套件性、成本幾個角度來衡量架構的優劣。為了讓這種討論不過於抽象，我們會用一些具體的服務作為參考，但是這些架構的思想是通用的，可以用其它類似產品實現。

# 場景1: 靜態 Web 站點

![圖片描述](//img.mukewang.com/5fd9dff30001c11410600591.png)

假如我們要做一個資訊展示的網站，需求很簡單，就像早年的中國黃頁那樣，資訊更新很少，大概有以下幾種主要選擇：

-   買臺伺服器放在 IDC 機房裡託管，執行站點；  
    
-   去雲廠商上買臺雲伺服器執行站點，為了解決高可用的問題又買了負載均衡服務和多個伺服器；  
    
-   採用靜態站點方式，直接由物件儲存服務（如 OSS）支援，並使用 CDN 回源 OSS。

![2.JPG](https://intranetproxy.alipay.com/skylark/lark/0/2020/jpeg/285843/1593416235718-23d1b724-844c-4af7-9e8f-199cc254532c.jpeg?x-oss-process=image%2Fresize%2Cw_1500 "2.JPG")

這三種方式由雲下到雲上，由管理伺服器到無需管理伺服器，即 Serverless。這一系列的轉變給使用者帶來了什麼變化呢？前兩種方案需要預算，需要擴充套件，需要實現高可用，需要自行監控等，這些都不是馬老師當年想要的，他只想去展示資訊，讓世界瞭解中國，這是他的業務邏輯。Serverless 正是這樣一種理念，最大化地讓人去專注業務邏輯。第三種方式就是採用了 Serverless 架構去構建一個靜態站點，它有其它方案無法比擬的優勢，比如：

-   可運維性：無需管理伺服器，比如作業系統的安全補丁升級、故障升級、高可用性，這些雲服務（OSS，CDN）都幫著做了；  
    
-   可擴充套件性：無需對資源做預估和考慮未來的擴充套件，因為 OSS 本身是彈性的，使用 CDN 使得系統延遲更小、費用更低、可用性更高；  
    
-   成本：按實際使用的資源付費，包括儲存費用和請求費用，沒有請求時不收取請求費用；  
    
-   安全性：這樣一個系統甚至看不到伺服器，不需要透過 SSH 登入，DDoS 攻擊也交給雲服務來解決。

# 場景2: 單體和微服務應用

![圖片描述](//img.mukewang.com/5fd9e0020001f50810550595.png)

靜態頁面和站點適合用於內容少、更新頻率低的場景，反之，就需要動態站點了。比如淘寶的商品頁面，採用靜態頁面方式管理商品資訊是不現實的。如何根據使用者請求動態地返回結果呢？我們來看兩種常見的解決方案：

-   Web 單體應用：所有的應用邏輯都在一個應用中完成，結合資料庫，這種分層架構可以快速實現一些複雜度較低的應用；  
    
-   微服務應用：隨著業務發展，功能多了，訪問量高了，團隊大了，這時候一般就需要將單體應用中的邏輯拆分成多個執行單元，比如商品頁面上的評論資訊、售賣資訊、配送資訊等，都可以對應一個單獨的微服務。這種架構的好處是每個單元是高度自治的，易於開發（比如使用不同技術）、部署和擴充套件。但是這種架構也引入了分散式系統的一些問題，如服務間通訊的負載均衡、失敗處理等。

處在不同階段不同規模的組織可以選擇適合自身的方式，來解決它面臨的首要業務問題，淘寶最初被人們接受一定不是因為它使用了哪種技術架構。但是無論選擇哪種架構，上面提到的 Serverless 原生心智都有助於我們專注業務。比如：

-   是否需要自己購置伺服器安裝資料庫，實現高可用、管理備份、升級版本等，還是可以把這些事情交給託管的服務如 RDS；是否可以使用表格儲存、Serverless HBase 等 Serverless 資料庫服務，實現按使用的彈性擴容縮容和付費；  
    
-   單體應用是需要自己購置伺服器執行，還是可以交給託管服務，如函式計算和 Serverless 應用引擎；  
    
-   是否可以透過函式來實現輕量級微服務，依賴函式計算提供的負載均衡、自動伸縮、按需付費、日誌採集、系統監控等能力；  
    
-   基於 Spring Cloud、Dubbo、HSF 等實現的微服務應用是否需要自己購置伺服器部署應用，管理服務發現，負載均衡，彈性伸縮，熔斷，系統監控等，還是可以將這些工作交給諸如 Serverless 應用引擎服務。

![4.JPG](https://intranetproxy.alipay.com/skylark/lark/0/2020/jpeg/285843/1593416261898-6f507fd9-20ec-426d-a35d-083e64167f3a.jpeg?x-oss-process=image%2Fresize%2Cw_1500 "4.JPG")

上圖右側的架構引入了 API 閘道器、函式計算或者 Serverless 應用引擎來實現計算層，將大量的工作交給了雲服務完成，讓使用者最大程度上專注實現業務邏輯。其中系統內部多個微服務的互動如下圖所示，透過提供一個商品聚合服務，將內部的多個微服務統一呈現給外部。這裡的微服務可以透過 SAE 或者函式實現。

![圖片描述](//img.mukewang.com/5fd9e014000111c310530594.png)

這樣的架構還可以繼續擴充套件，比如如何支援不同客戶端的訪問，如上圖右側所示。現實中這種需求是常見的，不同的客戶端需要的資訊可能是不同的，手機可以根據位置資訊做相關推薦。如何讓手機客戶端和不同瀏覽器都能受益於 Serverless 架構呢？這又牽扯出了另一個詞——Backend for fronted（BFF），即為前端定做的後端，這受到了前端開發工程師的推崇，Serverless 技術讓這個架構廣泛流行，因為前端工程師可以從業務角度出發直接編寫 BFF，而無需管理伺服器相關的令前端工程師更加頭疼的事情。更多實踐可以參見：[基於函式計算的 BFF 架構](https://yq.aliyun.com/articles/752780)。

# 場景3: 事件觸發

前面提到的動態頁面生成是同步請求完成的，還有一類常見場景，其中請求處理通常需要較長時間或者較多資源，比如使用者評論中的圖片和影片內容管理，涉及到如何上傳圖片和處理圖片（縮圖、水印、稽核等）及影片，以適應不同客戶端的播放需求。

![圖片描述](//img.mukewang.com/5fd9e0210001656810630597.png)

如何對上傳多媒體檔案實時處理呢？這個場景的技術架構大體經歷了以下演變：

![7.JPG](https://intranetproxy.alipay.com/skylark/lark/0/2020/jpeg/285843/1593416313755-7adb3bb6-645a-4b5f-86aa-ace9086d305c.jpeg?x-oss-process=image%2Fresize%2Cw_1500 "7.JPG")

-   基於伺服器的單體架構：多媒體檔案被上傳到伺服器，由伺服器處理，對多媒體的顯示請求也由伺服器完成；  
    
-   基於伺服器的微服務架構：多媒體檔案被上傳到伺服器，伺服器處理轉存到 OSS，然後將檔案地址加入訊息佇列，由另一組伺服器處理檔案，將處理結果儲存到 OSS，對多媒體的顯示請求由 OSS 和 CDN 完成；  
    
-   Serverless 架構：多媒體直接上傳到 OSS，由 OSS 的事件觸發能力直接觸發函式，函式處理結果儲存到 OSS，對多媒體的顯示請求由 OSS 和 CDN 完成。

基於伺服器的單體架構面臨以下問題：

-   如何處理海量檔案？單臺伺服器空間有限，購買更多的伺服器；  
    
-   如何擴充套件 Web 應用伺服器？Web 應用伺服器是否適合 CPU 密集型任務？  
    
-   如何解決上傳請求的高可用？  
    
-   如果解決顯示請求的高可用？  
    
-   如何應對請求負載的波峰波谷？

基於伺服器的微服務架構很好地解決了上述的大部分問題，但是仍然面臨一些問題：

-   管理應用伺服器的高可用性和彈性；  
    
-   管理檔案處理伺服器的彈性；  
    
-   管理訊息佇列的彈性。

而第三種 Serverless 架構很好地解決了上述所有問題。開發人員原來需要做的負載均衡、伺服器的高可用和彈性伸縮、訊息佇列都轉移到了服務內部。我們可以看到隨著架構的演進，開發人員做的事情越來越少，系統更加成熟，業務上更加聚焦，大大提升了交付速度。

這裡的 Serverless 架構主要體現的價值是：

-   事件觸發能力：函式計算服務與事件源（OSS）的原生整合讓使用者無需管理佇列資源，佇列自動擴充套件，實時處理上傳的多媒體檔案；  
    
-   高彈性和按需付費：圖片和影片（不同大小的影片）需要的計算資源規格是不同的，流量的波峰波谷對資源的需求是不同的，現在這種彈性由服務提供，按照使用者的真實使用去擴容縮容，讓使用者 100% 地利用資源，無需為閒置資源付費。

事件觸發能力是 FaaS 服務的一個重要特性，這種 Pub-Sub 事件驅動模式不是一個新的概念，但是在 Serverless 流行之前，事件的生產者、消費者以及中間的連線樞紐都是使用者負責的，就像前面架構演進中的第二個架構。

Serverless 讓生產者傳送事件，維護連線樞紐都從使用者職責中省略了，而只需關注消費者的邏輯，這就是 Serverless 的價值所在。

函式計算服務還整合其它雲服務事件源，讓你更方便地在業務中使用一些常見的模式，如 Pub/Sub、事件流模式、Event Sourcing 模式。關於更多的函式組合模式可以參見：[函式組合的 N 種方式](https://yq.aliyun.com/articles/722461)。

![8.JPG](https://intranetproxy.alipay.com/skylark/lark/0/2020/jpeg/285843/1593416331600-2df5f413-f4e1-4a4b-adb7-79c5731373b1.jpeg?x-oss-process=image%2Fresize%2Cw_1500 "8.JPG")

# 場景4: 服務編排

前面的商品頁面雖然複雜，但是所有的操作都是讀操作，聚合服務 API 是無狀態、同步的。我們來看一下電商中的一個核心場景——訂單流程。

![圖片描述](//img.mukewang.com/5fd9e0340001340f10560597.png)
  
這個場景涉及到多個分散式寫的問題，這是引入微服務架構導致的最麻煩的一個問題。單體應用在一定程度上可以比較容易地處理這個流程，因為使用了一個資料庫，可以透過資料庫事務保持資料一致性。但是現實中可能不得不去跟一些外部服務打交道，需要一定的機制保證流程的前進和回退順利完成，解決這個問題的一個經典模式是 Saga 模式，而實現這種模式有兩種不同架構：

一種做法是採用事件驅動模式，驅動流程完成。在這個架構裡，有一個訊息匯流排，感興趣的服務如庫存服務監聽事件，監聽者可以使用伺服器或者函式。藉助於函式計算和訊息主題的整合，這個架構也可以完全不使用伺服器。

這個架構模組是松耦合的，職責清晰。不足之處是隨著流程變得更長更加複雜，這個系統變得難以維護。比如很難直觀地瞭解業務邏輯，執行時的狀態也不宜跟蹤，可運維性比較差。

![image](https://intranetproxy.alipay.com/skylark/lark/0/2020/gif/285843/1593339365281-6b327ade-ae09-40f0-9f83-8664f0760412.gif "image")

另外一種架構是基於工作流的 Saga 模式。在這個架構裡，各個服務之間是獨立的，也不透過事件傳遞資訊，而是有一個集中的協調者服務來排程單個業務服務，業務邏輯和狀態由集中協調者維護。而實現這個集中的協調者通常面臨以下問題：

-   編寫大量程式碼來實現編排邏輯、狀態維護和錯誤重試等功能，而這些實現又很難被其它應用重用；  
    
-   維護執行編排應用的基礎設施，以確保編排應用的高可用性和可伸縮性；  
    
-   考慮狀態永續性，以支援多步驟長時間執行流程並確保流程的事務性。

依賴於雲服務，比如阿里雲的 Serverless 工作流服務，這些事情都可以交給平臺來做，使用者又回到了只需關注業務邏輯的狀態。

下圖右側是流程定義，我們可以看到這實現了前面基於事件的 Saga 模式的效果，並且流程大大簡化，提升了可觀測性。

![圖片描述](//img.mukewang.com/5fd9e0420001d01e10660594.png)

# 場景5: 資料流水線

隨著業務的進一步發展，資料變得越來越多，這時候就可以挖掘資料的價值。比如，分析使用者對網站的使用行為並做相應的推薦。一個資料流水線包括資料採集、處理、分析等多個環節。這樣的服務如果從頭搭建雖然是可行的，但是也是複雜的，我們這裡討論的業務是電商，而不是去提供一個資料流水線服務。有了這樣一個目標，我們做選擇時就會變得簡單明確。

-   日誌服務（SLS）提供了資料採集、分析和投遞功能；
-   函式計算（FC）可以對日誌服務的資料進行實時處理，將結果寫入其它服務，如日誌服務、OSS；
-   Serverless 工作流服務可以定時批次處理資料，透過函式定義靈活的資料處理邏輯，構建 ETL 作業；
-   資料湖分析（DLA）提供了 Serverless 化的互動式查詢服務，它使用標準 SQL分析物件儲存(OSS)、資料庫（PostgreSQL / MySQL等）、NoSQL（TableStore 等）等多個資料來源的資料。

# 總結

限於篇幅，我們只討論了 Serverless 架構在幾個場景中的應用，但是在實踐中我們可以看出一種共性，即如何將業務邏輯中與業務不相關的工作剝離出去，交給平臺和服務完成。這種各司其職、分工協作的做法在其它場合並不陌生，但是 Serverless 的思想讓這種形態更為明確。Less is more，少的不只是 Server 和圍繞 Server 相關的負擔，還可以是業務以外的方方面面，多的是專注的業務和產品的核心競爭力。

5 大場景深度探討何為 Serverless 架構模式？

相關文章