什么是 Serverless 架構？按照 CNCF 對 Serverless 計算的定義，Serverless 架構應該是采用 FaaS（函數(shù)即服務）和 BaaS（后端服務）服務來解決問題的一種設計。

這個定義讓我們對 Serverless 的理解稍顯清晰，同時可能也造成了一些困擾和爭論。 隨著需求和技術的發(fā)展，業(yè)界出現(xiàn)了一些 FaaS 以外的其它形態(tài)的 Serverless 計算服務，比如 Google Cloud Run，阿里云推出的面向應用的 Serverless 應用引擎服務以及 Serverless K8s，這些服務也提供了彈性伸縮能力和按使用計費的收費模式，具備 Serverless 服務的形態(tài)，可以說進一步擴大了 Serverless 計算的陣營； 為了消除冷啟動影響，F(xiàn)aaS 類服務如阿里云的函數(shù)計算和 AWS 的 Lambda 相繼推出了預留功能，變得不那么“按使用付費”了； 一些基于服務器（Serverful）的后端服務也推出了 Serverless 形態(tài)產(chǎn)品，比如 AWS Serverless Aurora，阿里云 Serverless HBase 服務。 

這樣看來，Serverless 的界線是有些模糊的，諸多云服務都向著 Serverless 方向演進。一個模糊的東西如何指導我們解決業(yè)務問題呢？Serverless 有一個根本的理念是一直沒有改變的，即讓用戶最大化地專注業(yè)務邏輯，其它的特征如不關心服務器、自動彈性、按使用計費等，都是為了實現(xiàn)這個理念而服務。 著名的 Serverless 實踐者 Ben Kehoe 這樣描述 Serverless 原生心智，當我們在業(yè)務中考慮做什么時可以體會一下這種心智： 我的業(yè)務是什么？

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

在實踐 Serverless 架構時，最重要的心智不是選擇哪些流行服務和技術，攻克哪些技術難題，而是時刻將專注業(yè)務邏輯銘記在心，這樣更容易讓我們選擇合適的技術和服務，明確如何設計應用架構。人的精力是有限的，組織的資源是有限的，Serverless 的理念可以讓我們更好地用有限的資源解決真正需要解決的問題，正是因為我們少做了一些事情，轉(zhuǎn)而讓別人做這些事情，我們才可以在業(yè)務上做的更多。 接下來我們介紹一些常見的場景，并探討如何使用 Serverless 架構支持這些場景。我們主要會采用計算、存儲和消息通信等技術來設計架構，從可運維性、安全性、可靠性、可擴展性、成本幾個角度來衡量架構的優(yōu)劣。

為了讓這種討論不過于抽象，我們會用一些具體的服務作為參考，但是這些架構的思想是通用的，可以用其它類似產(chǎn)品實現(xiàn)。 **靜態(tài) Web 站點** 假如我們要做一個信息展示的網(wǎng)站，需求很簡單，就像早年的中國黃頁那樣，信息更新很少，大概有以下幾種主要選擇： 買臺服務器放在 IDC 機房里托管，運行站點； 去云廠商上買臺云服務器運行站點，為了解決高可用的問題又買了負載均衡服務和多個服務器； 采用靜態(tài)站點方式，直接由對象存儲服務（如 OSS）支持，并使用 CDN 回源 OSS。 這三種方式由云下到云上，由管理服務器到無需管理服務器，即 Serverless。這一系列的轉(zhuǎn)變給使用者帶來了什么變化呢？

前兩種方案需要預算，需要擴展，需要實現(xiàn)高可用，需要自行監(jiān)控等，這些都不是馬老師當年想要的，他只想去展示信息，讓世界了解中國，這是他的業(yè)務邏輯。Serverless 正是這樣一種理念，最大化地讓人去專注業(yè)務邏輯。第三種方式就是采用了 Serverless 架構去構建一個靜態(tài)站點，它有其它方案無法比擬的優(yōu)勢，比如： 可運維性：無需管理服務器，比如操作系統(tǒng)的安全補丁升級、故障升級、高可用性，這些云服務（OSS，CDN）都幫著做了； 可擴展性：無需對資源做預估和考慮未來的擴展，因為 OSS 本身是彈性的，使用 CDN 使得系統(tǒng)延遲更小、費用更低、可用性更高； 成本：按實際使用的資源付費，包括存儲費用和請求費用，沒有請求時不收取請求費用； 安全性：這樣一個系統(tǒng)甚至看不到服務器，不需要通過 SSH 登錄，DDoS 攻擊也交給云服務來解決。 

單體和微服務應用

靜態(tài)頁面和站點適合用于內(nèi)容少、更新頻率低的場景，反之，就需要動態(tài)站點了。比如淘寶的商品頁面，采用靜態(tài)頁面方式管理商品信息是不現(xiàn)實的。如何根據(jù)用戶請求動態(tài)地返回結果呢？我們來看兩種常見的解決方案： Web 單體應用：所有的應用邏輯都在一個應用中完成，結合數(shù)據(jù)庫，這種分層架構可以快速實現(xiàn)一些復雜度較低的應用； 微服務應用：隨著業(yè)務發(fā)展，功能多了，訪問量高了，團隊大了，這時候一般就需要將單體應用中的邏輯拆分成多個執(zhí)行單元，比如商品頁面上的評論信息、售賣信息、配送信息等，都可以對應一個單獨的微服務。

這種架構的好處是每個單元是高度自治的，易于開發(fā)（比如使用不同技術）、部署和擴展。但是這種架構也引入了分布式系統(tǒng)的一些問題，如服務間通信的負載均衡、失敗處理等。 處在不同階段不同規(guī)模的組織可以選擇適合自身的方式，來解決它面臨的首要業(yè)務問題，淘寶最初被人們接受一定不是因為它使用了哪種技術架構。

但是無論選擇哪種架構，上面提到的 Serverless 原生心智都有助于我們專注業(yè)務。比如： 是否需要自己購置服務器安裝數(shù)據(jù)庫，實現(xiàn)高可用、管理備份、升級版本等，還是可以把這些事情交給托管的服務如 RDS；是否可以使用表格存儲、Serverless HBase 等 Serverless 數(shù)據(jù)庫服務，實現(xiàn)按使用的彈性擴容縮容和付費； 單體應用是需要自己購置服務器運行，還是可以交給托管服務，如函數(shù)計算和 Serverless 應用引擎； 是否可以通過函數(shù)來實現(xiàn)輕量級微服務，依賴函數(shù)計算提供的負載均衡、自動伸縮、按需付費、日志采集、系統(tǒng)監(jiān)控等能力； 基于 Spring Cloud、Dubbo、HSF 等實現(xiàn)的微服務應用是否需要自己購置服務器部署應用，管理服務發(fā)現(xiàn)，負載均衡，彈性伸縮，熔斷，系統(tǒng)監(jiān)控等，還是可以將這些工作交給諸如 Serverless 應用引擎服務。 

上圖右側(cè)的架構引入了 API 網(wǎng)關、函數(shù)計算或者 Serverless 應用引擎來實現(xiàn)計算層，將大量的工作交給了云服務完成，讓用戶最大程度上專注實現(xiàn)業(yè)務邏輯。其中系統(tǒng)內(nèi)部多個微服務的交互如下圖所示，通過提供一個商品聚合服務，將內(nèi)部的多個微服務統(tǒng)一呈現(xiàn)給外部。

這里的微服務可以通過 SAE 或者函數(shù)實現(xiàn)。 這樣的架構還可以繼續(xù)擴展，比如如何支持不同客戶端的訪問，如上圖右側(cè)所示?，F(xiàn)實中這種需求是常見的，不同的客戶端需要的信息可能是不同的，手機可以根據(jù)位置信息做相關推薦。如何讓手機客戶端和不同瀏覽器都能受益于 Serverless 架構呢？這又牽扯出了另一個詞——Backend for fronted（BFF），即為前端定做的后端，這受到了前端開發(fā)工程師的推崇，Serverless 技術讓這個架構廣泛流行，因為前端工程師可以從業(yè)務角度出發(fā)直接編寫 BFF，而無需管理服務器相關的令前端工程師更加頭疼的事情。更多實踐可以參見基于函數(shù)計算的 BFF 架構。 

事件觸發(fā)

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

如何對上傳多媒體文件實時處理呢？這個場景的技術架構大體經(jīng)歷了以下演變： 基于服務器的單體架構：多媒體文件被上傳到服務器，由服務器處理，對多媒體的顯示請求也由服務器完成； 基于服務器的微服務架構：多媒體文件被上傳到服務器，服務器處理轉(zhuǎn)存到 OSS，然后將文件地址加入消息隊列，由另一組服務器處理文件，將處理結果保存到 OSS，對多媒體的顯示請求由 OSS 和 CDN 完成； Serverless 架構：多媒體直接上傳到 OSS，由 OSS 的事件觸發(fā)能力直接觸發(fā)函數(shù)，函數(shù)處理結果保存到 OSS，對多媒體的顯示請求由 OSS 和 CDN 完成。 基于服務器的單體架構面臨以下問題： 如何處理海量文件？單臺服務器空間有限，購買更多的服務器； 如何擴展 Web 應用服務器？Web 應用服務器是否適合 CPU 密集型任務？ 如何解決上傳請求的高可用？ 

如果解決顯示請求的高可用？ 如何應對請求負載的波峰波谷？ 基于服務器的微服務架構很好地解決了上述的大部分問題，但是仍然面臨一些問題： 管理應用服務器的高可用性和彈性； 管理文件處理服務器的彈性； 管理消息隊列的彈性。 而第三種 Serverless 架構很好地解決了上述所有問題。

開發(fā)人員原來需要做的負載均衡、服務器的高可用和彈性伸縮、消息隊列都轉(zhuǎn)移到了服務內(nèi)部。我們可以看到隨著架構的演進，開發(fā)人員做的事情越來越少，系統(tǒng)更加成熟，業(yè)務上更加聚焦，大大提升了交付速度。 這里的 Serverless 架構主要體現(xiàn)的價值是： 事件觸發(fā)能力：函數(shù)計算服務與事件源（OSS）的原生集成讓使用者無需管理隊列資源，隊列自動擴展，實時處理上傳的多媒體文件； 高彈性和按需付費：圖片和視頻（不同大小的視頻）需要的計算資源規(guī)格是不同的，流量的波峰波谷對資源的需求是不同的，現(xiàn)在這種彈性由服務提供，按照用戶的真實使用去擴容縮容，讓用戶 100% 地利用資源，無需為閑置資源付費。 事件觸發(fā)能力是 FaaS 服務的一個重要特性，這種 Pub-Sub 事件驅(qū)動模式不是一個新的概念，但是在 Serverless 流行之前，事件的生產(chǎn)者、消費者以及中間的連接樞紐都是用戶負責的，就像前面架構演進中的第二個架構。

Serverless 讓生產(chǎn)者發(fā)送事件，維護連接樞紐都從用戶職責中省略了，而只需關注消費者的邏輯，這就是 Serverless 的價值所在。 函數(shù)計算服務還集成其它云服務事件源，讓你更方便地在業(yè)務中使用一些常見的模式，如 Pub/Sub、事件流模式、Event Sourcing 模式。關于更多的函數(shù)組合模式可以參見函數(shù)組合的 N 種方式。 

服務編排

 前面的商品頁面雖然復雜，但是所有的操作都是讀操作，聚合服務 API 是無狀態(tài)、同步的。我們來看一下電商中的一個核心場景——訂單流程。 這個場景涉及到多個分布式寫的問題，這是引入微服務架構導致的最麻煩的一個問題。單體應用在一定程度上可以比較容易地處理這個流程，因為使用了一個數(shù)據(jù)庫，可以通過數(shù)據(jù)庫事務保持數(shù)據(jù)一致性。但是現(xiàn)實中可能不得不去跟一些外部服務打交道，需要一定的機制保證流程的前進和回退順利完成，解決這個問題的一個經(jīng)典模式是 Saga 模式，而實現(xiàn)這種模式有兩種不同架構： 一種做法是采用事件驅(qū)動模式，驅(qū)動流程完成。在這個架構里，有一個消息總線，感興趣的服務如庫存服務監(jiān)聽事件，監(jiān)聽者可以使用服務器或者函數(shù)。借助于函數(shù)計算和消息主題的集成，這個架構也可以完全不使用服務器。 這個架構模塊是松耦合的，職責清晰。

不足之處是隨著流程變得更長更加復雜，這個系統(tǒng)變得難以維護。比如很難直觀地了解業(yè)務邏輯，執(zhí)行時的狀態(tài)也不宜跟蹤，可運維性比較差。 另外一種架構是基于工作流的 Saga 模式。在這個架構里，各個服務之間是獨立的，也不通過事件傳遞信息，而是有一個集中的協(xié)調(diào)者服務來調(diào)度單個業(yè)務服務，業(yè)務邏輯和狀態(tài)由集中協(xié)調(diào)者維護。

而實現(xiàn)這個集中的協(xié)調(diào)者通常面臨以下問題： 編寫大量代碼來實現(xiàn)編排邏輯、狀態(tài)維護和錯誤重試等功能，而這些實現(xiàn)又很難被其它應用重用； 維護運行編排應用的基礎設施，以確保編排應用的高可用性和可伸縮性； 考慮狀態(tài)持久性，以支持多步驟長時間運行流程并確保流程的事務性。 依賴于云服務，比如阿里云的 Serverless 工作流服務，這些事情都可以交給平臺來做，用戶又回到了只需關注業(yè)務邏輯的狀態(tài)。 

下圖右側(cè)是流程定義，我們可以看到這實現(xiàn)了前面基于事件的 Saga 模式的效果，并且流程大大簡化，提升了可觀測性。 

數(shù)據(jù)流水線

 隨著業(yè)務的進一步發(fā)展，數(shù)據(jù)變得越來越多，這時候就可以挖掘數(shù)據(jù)的價值。比如，分析用戶對網(wǎng)站的使用行為并做相應的推薦。一個數(shù)據(jù)流水線包括數(shù)據(jù)采集、處理、分析等多個環(huán)節(jié)。這樣的服務如果從頭搭建雖然是可行的，但是也是復雜的，我們這里討論的業(yè)務是電商，而不是去提供一個數(shù)據(jù)流水線服務。有了這樣一個目標，我們做選擇時就會變得簡單明確。 

日志服務（SLS）提供了數(shù)據(jù)采集、分析和投遞功能； 函數(shù)計算（FC）可以對日志服務的數(shù)據(jù)進行實時處理，將結果寫入其它服務，如日志服務、OSS； Serverless 工作流服務可以定時批量處理數(shù)據(jù)，通過函數(shù)定義靈活的數(shù)據(jù)處理邏輯，構建 ETL 作業(yè)； 數(shù)據(jù)湖分析（DLA）提供了 Serverless 化的交互式查詢服務，它使用標準 SQL分析對象存儲(OSS)、數(shù)據(jù)庫（PostgreSQL / MySQL等）、NoSQL（TableStore 等）等多個數(shù)據(jù)源的數(shù)據(jù)。 

總結

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