帶你從零入門 Serverless | 一文詳解 Serverless 架構(gòu)模式

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

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

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

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

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

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

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

單體和微服務(wù)應(yīng)用

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

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

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

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

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

事件觸發(fā)

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

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

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

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

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

服務(wù)編排

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

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

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

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

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

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

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

總結(jié)

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