究竟什么是 Serverless 架構(gòu)？

什么是 Serverless 架構(gòu)业踢？按照 CNCF 對(duì) Serverless 計(jì)算的定義，Serverless 架構(gòu)應(yīng)該是采用 FaaS（函數(shù)即服務(wù)）和 BaaS（后端服務(wù)）服務(wù)來(lái)解決問(wèn)題的一種設(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)恳蹲，可以說(shuō)進(jìn)一步擴(kuò)大了 Serverless 計(jì)算的陣營(yíng)虐块；

為了消除冷啟動(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ù)儡率。

這樣看來(lái)，Serverless 的界線是有些模糊的以清，諸多云服務(wù)都向著 Serverless 方向演進(jìn)儿普。一個(gè)模糊的東西如何指導(dǎo)我們解決業(yè)務(wù)問(wèn)題呢？Serverless 有一個(gè)根本的理念是一直沒(méi)有改變的掷倔，即讓用戶最大化地專注業(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ù)出類拔萃篮洁？

如果不能，我為什么要做這件事情而不是讓別人來(lái)解決這個(gè)問(wèn)題殃姓？

在解決業(yè)務(wù)問(wèn)題之前沒(méi)有必要解決技術(shù)問(wèn)題袁波。

在實(shí)踐 Serverless 架構(gòu)時(shí)，最重要的心智不是選擇哪些流行服務(wù)和技術(shù)蜗侈，攻克哪些技術(shù)難題篷牌，而是時(shí)刻將專注業(yè)務(wù)邏輯銘記在心，這樣更容易讓我們選擇合適的技術(shù)和服務(wù)踏幻，明確如何設(shè)計(jì)應(yīng)用架構(gòu)枷颊。人的精力是有限的，組織的資源是有限的该面，Serverless 的理念可以讓我們更好地用有限的資源解決真正需要解決的問(wèn)題夭苗，正是因?yàn)槲覀兩僮隽艘恍┦虑椋D(zhuǎn)而讓別人做這些事情隔缀，我們才可以在業(yè)務(wù)上做的更多题造。

接下來(lái)我們介紹一些常見(jiàn)的場(chǎng)景，并探討如何使用 Serverless 架構(gòu)支持這些場(chǎng)景猾瘸。我們主要會(huì)采用計(jì)算界赔、存儲(chǔ)和消息通信等技術(shù)來(lái)設(shè)計(jì)架構(gòu)，從可運(yùn)維性牵触、安全性淮悼、可靠性、可擴(kuò)展性揽思、成本幾個(gè)角度來(lái)衡量架構(gòu)的優(yōu)劣袜腥。為了讓這種討論不過(guò)于抽象，我們會(huì)用一些具體的服務(wù)作為參考绰更，但是這些架構(gòu)的思想是通用的瞧挤，可以用其它類似產(chǎn)品實(shí)現(xiàn)锡宋。

場(chǎng)景 1: 靜態(tài) Web 站點(diǎn)

假如我們要做一個(gè)信息展示的網(wǎng)站儡湾，需求很簡(jiǎn)單，就像早年的中國(guó)黃頁(yè)那樣执俩，信息更新很少徐钠，大概有以下幾種主要選擇：

買臺(tái)服務(wù)器放在 IDC 機(jī)房里托管，運(yùn)行站點(diǎn)役首；

去云廠商上買臺(tái)云服務(wù)器運(yùn)行站點(diǎn)尝丐，為了解決高可用的問(wèn)題又買了負(fù)載均衡服務(wù)和多個(gè)服務(wù)器显拜；

采用靜態(tài)站點(diǎn)方式，直接由對(duì)象存儲(chǔ)服務(wù)（如 OSS）支持爹袁，并使用 CDN 回源 OSS远荠。

這三種方式由云下到云上，由管理服務(wù)器到無(wú)需管理服務(wù)器失息，即 Serverless譬淳。這一系列的轉(zhuǎn)變給使用者帶來(lái)了什么變化呢？前兩種方案需要預(yù)算盹兢，需要擴(kuò)展邻梆，需要實(shí)現(xiàn)高可用，需要自行監(jiān)控等绎秒，這些都不是馬老師當(dāng)年想要的浦妄，他只想去展示信息，讓世界了解中國(guó)见芹，這是他的業(yè)務(wù)邏輯剂娄。Serverless 正是這樣一種理念，最大化地讓人去專注業(yè)務(wù)邏輯玄呛。第三種方式就是采用了 Serverless 架構(gòu)去構(gòu)建一個(gè)靜態(tài)站點(diǎn)宜咒，它有其它方案無(wú)法比擬的優(yōu)勢(shì)，比如：

可運(yùn)維性：無(wú)需管理服務(wù)器把鉴，比如操作系統(tǒng)的安全補(bǔ)丁升級(jí)故黑、故障升級(jí)、高可用性庭砍，這些云服務(wù)（OSS场晶，CDN）都幫著做了；

可擴(kuò)展性：無(wú)需對(duì)資源做預(yù)估和考慮未來(lái)的擴(kuò)展怠缸，因?yàn)?OSS 本身是彈性的诗轻，使用 CDN 使得系統(tǒng)延遲更小、費(fèi)用更低揭北、可用性更高扳炬；

成本：按實(shí)際使用的資源付費(fèi)，包括存儲(chǔ)費(fèi)用和請(qǐng)求費(fèi)用搔体，沒(méi)有請(qǐng)求時(shí)不收取請(qǐng)求費(fèi)用恨樟；

安全性：這樣一個(gè)系統(tǒng)甚至看不到服務(wù)器，不需要通過(guò) SSH 登錄疚俱，DDoS 攻擊也交給云服務(wù)來(lái)解決劝术。

場(chǎng)景 2: 單體和微服務(wù)應(yīng)用

靜態(tài)頁(yè)面和站點(diǎn)適合用于內(nèi)容少、更新頻率低的場(chǎng)景，反之养晋，就需要?jiǎng)討B(tài)站點(diǎn)了衬吆。比如淘寶的商品頁(yè)面，采用靜態(tài)頁(yè)面方式管理商品信息是不現(xiàn)實(shí)的绳泉。如何根據(jù)用戶請(qǐng)求動(dòng)態(tài)地返回結(jié)果呢逊抡？我們來(lái)看兩種常見(jiàn)的解決方案：

Web 單體應(yīng)用：所有的應(yīng)用邏輯都在一個(gè)應(yīng)用中完成，結(jié)合數(shù)據(jù)庫(kù)零酪，這種分層架構(gòu)可以快速實(shí)現(xiàn)一些復(fù)雜度較低的應(yīng)用秦忿；

微服務(wù)應(yīng)用：隨著業(yè)務(wù)發(fā)展，功能多了蛾娶，訪問(wèn)量高了灯谣，團(tuán)隊(duì)大了，這時(shí)候一般就需要將單體應(yīng)用中的邏輯拆分成多個(gè)執(zhí)行單元蛔琅，比如商品頁(yè)面上的評(píng)論信息胎许、售賣信息、配送信息等罗售，都可以對(duì)應(yīng)一個(gè)單獨(dú)的微服務(wù)辜窑。這種架構(gòu)的好處是每個(gè)單元是高度自治的，易于開(kāi)發(fā)（比如使用不同技術(shù)）寨躁、部署和擴(kuò)展穆碎。但是這種架構(gòu)也引入了分布式系統(tǒng)的一些問(wèn)題，如服務(wù)間通信的負(fù)載均衡职恳、失敗處理等所禀。

處在不同階段不同規(guī)模的組織可以選擇適合自身的方式，來(lái)解決它面臨的首要業(yè)務(wù)問(wèn)題放钦，淘寶最初被人們接受一定不是因?yàn)樗褂昧四姆N技術(shù)架構(gòu)色徘。但是無(wú)論選擇哪種架構(gòu)，上面提到的 Serverless 原生心智都有助于我們專注業(yè)務(wù)操禀。比如：

是否需要自己購(gòu)置服務(wù)器安裝數(shù)據(jù)庫(kù)褂策，實(shí)現(xiàn)高可用、管理備份颓屑、升級(jí)版本等斤寂，還是可以把這些事情交給托管的服務(wù)如 RDS；是否可以使用表格存儲(chǔ)揪惦、Serverless HBase 等 Serverless 數(shù)據(jù)庫(kù)服務(wù)遍搞，實(shí)現(xiàn)按使用的彈性擴(kuò)容縮容和付費(fèi)；

單體應(yīng)用是需要自己購(gòu)置服務(wù)器運(yùn)行丹擎，還是可以交給托管服務(wù)尾抑，如函數(shù)計(jì)算和 Serverless 應(yīng)用引擎；

是否可以通過(guò)函數(shù)來(lái)實(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)用是否需要自己購(gòu)置服務(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)用引擎來(lái)實(shí)現(xiàn)計(jì)算層指蚁，將大量的工作交給了云服務(wù)完成，讓用戶最大程度上專注實(shí)現(xiàn)業(yè)務(wù)邏輯自晰。其中系統(tǒng)內(nèi)部多個(gè)微服務(wù)的交互如下圖所示凝化，通過(guò)提供一個(gè)商品聚合服務(wù)，將內(nèi)部的多個(gè)微服務(wù)統(tǒng)一呈現(xiàn)給外部酬荞。這里的微服務(wù)可以通過(guò) SAE 或者函數(shù)實(shí)現(xiàn)搓劫。

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

場(chǎng)景 3: 事件觸發(fā)

前面提到的動(dòng)態(tài)頁(yè)面生成是同步請(qǐng)求完成的滔迈，還有一類常見(jiàn)場(chǎng)景止吁，其中請(qǐng)求處理通常需要較長(zhǎ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)面臨以下問(wèn)題：

如何處理海量文件蚂踊？單臺(tái)服務(wù)器空間有限，購(gòu)買更多的服務(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)很好地解決了上述的大部分問(wèn)題炬灭，但是仍然面臨一些問(wèn)題：

管理應(yīng)用服務(wù)器的高可用性和彈性醋粟；

管理文件處理服務(wù)器的彈性；

管理消息隊(duì)列的彈性重归。

而第三種 Serverless 架構(gòu)很好地解決了上述所有問(wèn)題米愿。開(kāi)發(fā)人員原來(lái)需要做的負(fù)載均衡、服務(wù)器的高可用和彈性伸縮鼻吮、消息隊(duì)列都轉(zhuǎn)移到了服務(wù)內(nèi)部育苟。我們可以看到隨著架構(gòu)的演進(jìn)，開(kāi)發(fā)人員做的事情越來(lái)越少椎木，系統(tǒng)更加成熟违柏，業(yè)務(wù)上更加聚焦博烂，大大提升了交付速度。

這里的 Serverless 架構(gòu)主要體現(xiàn)的價(jià)值是：

事件觸發(fā)能力：函數(shù)計(jì)算服務(wù)與事件源（OSS）的原生集成讓使用者無(wú)需管理隊(duì)列資源漱竖，隊(duì)列自動(dòng)擴(kuò)展禽篱，實(shí)時(shí)處理上傳的多媒體文件；

高彈性和按需付費(fèi)：圖片和視頻（不同大小的視頻）需要的計(jì)算資源規(guī)格是不同的闲孤，流量的波峰波谷對(duì)資源的需求是不同的谆级，現(xiàn)在這種彈性由服務(wù)提供烤礁，按照用戶的真實(shí)使用去擴(kuò)容縮容讼积，讓用戶 100% 地利用資源，無(wú)需為閑置資源付費(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ù)中使用一些常見(jiàn)的模式沦疾，如 Pub/Sub称近、事件流模式、Event Sourcing 模式哮塞。關(guān)于更多的函數(shù)組合模式可以參見(jiàn)：函數(shù)組合的 N 種方式刨秆。

場(chǎng)景 4: 服務(wù)編排

前面的商品頁(yè)面雖然復(fù)雜，但是所有的操作都是讀操作忆畅，聚合服務(wù) API 是無(wú)狀態(tài)衡未、同步的。我們來(lái)看一下電商中的一個(gè)核心場(chǎng)景——訂單流程家凯。

這個(gè)場(chǎng)景涉及到多個(gè)分布式寫的問(wèn)題眠屎，這是引入微服務(wù)架構(gòu)導(dǎo)致的最麻煩的一個(gè)問(wèn)題。單體應(yīng)用在一定程度上可以比較容易地處理這個(gè)流程肆饶，因?yàn)槭褂昧艘粋€(gè)數(shù)據(jù)庫(kù)改衩，可以通過(guò)數(shù)據(jù)庫(kù)事務(wù)保持?jǐn)?shù)據(jù)一致性。但是現(xiàn)實(shí)中可能不得不去跟一些外部服務(wù)打交道驯镊，需要一定的機(jī)制保證流程的前進(jìn)和回退順利完成葫督，解決這個(gè)問(wèn)題的一個(gè)經(jīng)典模式是 Saga 模式竭鞍，而實(shí)現(xiàn)這種模式有兩種不同架構(gòu)：

一種做法是采用事件驅(qū)動(dòng)模式，驅(qū)動(dòng)流程完成橄镜。在這個(gè)架構(gòu)里偎快，有一個(gè)消息總線，感興趣的服務(wù)如庫(kù)存服務(wù)監(jiān)聽(tīng)事件洽胶，監(jiān)聽(tīng)者可以使用服務(wù)器或者函數(shù)晒夹。借助于函數(shù)計(jì)算和消息主題的集成，這個(gè)架構(gòu)也可以完全不使用服務(wù)器姊氓。

這個(gè)架構(gòu)模塊是松耦合的丐怯，職責(zé)清晰。不足之處是隨著流程變得更長(zhǎng)更加復(fù)雜翔横，這個(gè)系統(tǒng)變得難以維護(hù)读跷。比如很難直觀地了解業(yè)務(wù)邏輯，執(zhí)行時(shí)的狀態(tài)也不宜跟蹤禾唁，可運(yùn)維性比較差效览。

另外一種架構(gòu)是基于工作流的 Saga 模式。在這個(gè)架構(gòu)里荡短，各個(gè)服務(wù)之間是獨(dú)立的丐枉，也不通過(guò)事件傳遞信息，而是有一個(gè)集中的協(xié)調(diào)者服務(wù)來(lái)調(diào)度單個(gè)業(yè)務(wù)服務(wù)掘托，業(yè)務(wù)邏輯和狀態(tài)由集中協(xié)調(diào)者維護(hù)瘦锹。而實(shí)現(xiàn)這個(gè)集中的協(xié)調(diào)者通常面臨以下問(wèn)題：

編寫大量代碼來(lái)實(shí)現(xiàn)編排邏輯、狀態(tài)維護(hù)和錯(cuò)誤重試等功能烫映，而這些實(shí)現(xiàn)又很難被其它應(yīng)用重用沼本；

維護(hù)運(yùn)行編排應(yīng)用的基礎(chǔ)設(shè)施，以確保編排應(yīng)用的高可用性和可伸縮性锭沟；

考慮狀態(tài)持久性抽兆，以支持多步驟長(zhǎng)時(shí)間運(yùn)行流程并確保流程的事務(wù)性。

依賴于云服務(wù)族淮，比如阿里云的 Serverless 工作流服務(wù)辫红，這些事情都可以交給平臺(tái)來(lái)做，用戶又回到了只需關(guān)注業(yè)務(wù)邏輯的狀態(tài)祝辣。>

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

場(chǎng)景 5: 數(shù)據(jù)流水線

隨著業(yè)務(wù)的進(jìn)一步發(fā)展，數(shù)據(jù)變得越來(lái)越多孕荠，這時(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ù)蝶柿，通過(guò)函數(shù)定義靈活的數(shù)據(jù)處理邏輯，構(gòu)建 ETL 作業(yè)非驮；

數(shù)據(jù)湖分析（DLA）提供了 Serverless 化的交互式查詢服務(wù)交汤，它使用標(biāo)準(zhǔn) SQL 分析對(duì)象存儲(chǔ)(OSS)、數(shù)據(jù)庫(kù)（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)力褐隆。