作者：西流
編輯&排版：雯燕

Serverless 架構

按照 CNCF 對 Serverless 計算的定義，Serverless 架構應該是采用 FaaS（函數即服務）和 BaaS（后端服務）服務來解決問題的一種設計，這個定義讓我們對 Serverless 的理解稍微清楚了一些，但是可能也造成了一些爭論。

• 隨著需求和技術的發展，業界出現了一些 FaaS 以外的其它形態的 Serverless 計算服務，比如 Google CloudRun，阿里云推出了面向應用的 Serverless 應用引擎服務，這些服務也提供了彈性伸縮能力和按使用計費的收費模式，具備 Serverless 服務的形態，可以說進一步擴大了 Serverless 計算的陣營。

• 為了解決冷啟動影響，FaaS 類如阿里云的函數計算和 AWS 的 Lambda 也相繼推出了預留功能。

• 另外一些基于服務器（Serverful）的后端服務也推出了 Serverless 形態產品，比如 AWS Serverless Aurora，阿里云 Serverless HBase 服務。

因此，Serverless 的界線有些模糊，但是云服務在 Serverless 方向上是不斷演進的。一個模糊的東西如何指導我們解決業務問題呢？Serverless 有一個最根本的理念是：讓用戶最大化的專注業務邏輯。其它的特征如不關心服務器，自動彈性，按使用計費等等都是為了實現這個理念而服務。Serverless 的理念可以讓我們更好地用有限的資源解決真正需要解決的問題，正是因為我們少做了一些事情，轉而讓別人做這些事情，我們才可以在業務上做的更多。

著名的 Serverless 實踐者 Ben Kehoe 這樣描述 Serverless 原生心智：

• 我的業務是什么？

• 做這件事情能不能讓我的業務出類拔萃？

• 如果不能，我為什么要做這件事情而不是讓別人來解決這個問題？

• 在解決業務問題之前沒有必要解決技術問題。
  ?

在實踐 Serverless 架構時，最重要的心智不是選擇哪些流行服務和技術，攻克哪些技術難題，而是時刻銘記在心專注業務邏輯，這樣更容易讓我們選擇合適的技術和服務，明確如何設計應用架構。

靜態站點

Serverless 架構從使用技術上有計算，數據存儲，消息通信，我們可從運維性，安全性，可靠性，可擴展性，成本幾個角度來衡量架構的優劣。本文會介紹一些常見的業務場景，探討如何使用 Serverless 架構來支持這些場景。為了讓這種討論不過于抽象，下面會介紹一些具體的技術實現作為參考，但是這些架構的思想是通用的，可以用其它類似產品實現。

靜態站點的業務需求是比較簡單的，它相當于一個信息展示的站點。比如早期網站都是靜態展示，如圖是 1997 年的中國黃頁，它其實就是一個單層的頁面。其特征可以分為三點：

• 它的頁面是偏靜態的展示信息。

• 其頁面更新并不頻繁。

• 不確定訪問量。

架構的演進

圖中所展示出的由云下到云上，由管理服務器到無需管理服務器（即 Serverless）的轉變給開發者帶來了巨大的受益。如前兩種方案需要預算，擴展，實現高可用，自行監控等，而當年中國黃頁開發者的業務邏輯只是想單純的展示信息，讓世界了解中國。正好與 Serverless 原生心智相吻合，即讓開發者最大化的去專注業務邏輯。

買臺服務器放在 IDC 機房里托管，運行站點。

為了解決高可用的問題又買了負載均衡服務和多個服務器。

采用靜態站點方式，站長直接將站點由對象存儲服務（如 OSS）支持，并使用 CDN 做緩存。

傳統架構模式下開發網站，會把網站部署在服務器上，隨后再把這個服務器托管到機房，然后用戶或者客戶端用電腦瀏覽器去訪問這個網站。它所存在弊端就是：如果這個網站出現問題，服務器不再可用，為了維護這個網站的高可用性，會再掛一個負載均衡和兩個儲備服務器，這就是 Serverful 服務的架構。Serverless 架構對于開發人員來說，它只需要把它的靜態頁面直接發布到對象存儲，而對象存儲本身就是一個 Serverless 的文件存儲服務，它可以存儲靜態頁頁面、圖片、音頻、視頻等等，并且做到無限擴展。

Serverless 架構有著其它方案無法比擬的優勢：

• 無需管理服務器，比如操作系統的安全補丁升級，故障升級，高可用性，這些云服務（OSS，CDN）都幫著做了。

• 無需對資源做預估和考慮未來的擴展，因為 OSS 本身是彈性的，使用 CDN 使得系統延遲更小，費用更低，可用性更高。

• 按實際使用的資源付費，包括存儲費用和請求費用，沒有請求時不收取請求費用。

• 安全性：這樣一個系統甚至看不到服務器，不需要通過 SSH 登錄，DDOS 攻擊也交給云服務來解決。

靜態是個好東西，緩存也是軟件開發經常用到的技術，雖然有句玩笑是說計算機技術只有兩個最難的事情，讓緩存失效和命名。但是這也體現了緩存的重要性，只要運用得當，能大大提升系統的性能。

比如說目前很多安卓應用，要發布到如小米應用商店、華為應用商店等各種渠道商，開發者更希望的是打包好一個母包，放在對象存儲里，而不是反復做打渠道包維護等重復工作。對用戶來說，只需要維護一個母包，然后再維護一個簡單的動態計算即可。其實 CDN 不只可以回源到對象存儲，還可以回源到動態后端，如 API 網關，函數計算，負載均衡器等，也不止有 CDN 可以這種類型的緩存，還可以使用 Redis，以及進程內的緩存。

單體和微服務

為何會有單體和微服務，因為靜態站點的話，它可能只是解決一些展示信息的需求，但是隨著業務需求復雜程度增加，就需要動態站點了。比如：

• 淘寶的商品頁面，采用靜態頁面方式管理商品信息是不現實的。商品數量眾多，商品上架、下架信息更新頻繁，商品頁面復雜。

• 網易、新浪門戶網站， 實時新聞不斷更新，評論、點贊， 轉發等

靜態頁面和站點適合用于內容少更新頻率低的場景，反之，比如像圖中淘寶的一個商品詳情頁，使用靜態站點的頁面是不太現實的，原因有下：

商品是海量的。

更新頻繁。

動態信息來源廣泛，如基本信息、價格、運費、銷量、庫存、評論等是實時變化的。

上面提到的 Serverless 原生心智有助于我們專注業務。比如：

是否需要自己購置服務器安裝數據庫，實現高可用，管理備份，升級版本等，還是可以把這些事情交給托管的服務如 RDS；是否可以使用表格存儲，Serverless HBase 等 Serverless 數據庫服務，實現按使用的彈性擴容縮容和付費。

單體應用是需要自己購置服務器運行，還是可以交給托管服務，如函數計算和 Serverless 應用引擎。

是否可以通過函數來實現輕量級微服務，依賴函數計算提供的負載均衡、自動伸縮、按需付費、系統監控等能力。

基于 Spring Cloud、Dubbo、HSF 等實現的微服務應用是否需要自己購置服務器部署應用，管理服務發現，負載均衡，彈性伸縮，熔斷，系統監控等，還是可以將這些工作交給諸如 Serverless 應用引擎服務。

關于架構的演進，經歷了 Serverful 單體架構到 Serverful 微服務架構再到 Serverless 微服務架構過程。隨著業務的發展，組織規模的不斷增大，這時候一般就需要將單體應用中的邏輯拆分成多個執行單元，比如商品頁面上的評論信息，售賣信息，配送信息等都可以對應一個單獨的微服務；而右圖的架構引入了 API 網關、函數計算或 SAE 來實現計算層，將大量工作交換云服務完成。Serverless 這種微服務架構的好處是每個單元都能高度自治，單元之間松耦合，易于開發（比如使用不同技術）、部署和擴展。

但是這種架構也引入了分布式系統的一些問題，如服務間通信的負載均衡，失敗處理，分布式事務等。處在不同階段不同規模的組織可以選擇適合的方式，來解決它面臨的首要的業務問題。

其實這里的商品頁面雖然信息繁多，但是相對來說依舊比較簡單，主要是因為這里只是涉及到了讀操作。這種圖顯示了系統內部多個微服務的交互。通過提供一個商品聚合服務，將內部的多個微服務統一的呈現給外部。這里的微服務可以通過 SAE 或者函數實現。

另一個延伸是，我們開始的業務需求沒有提到需要支持不同客戶端的訪問，現實中這種需求是常見的，不同的客戶端需要的信息可能是不同的。比如手機可以根據位置信息做相關推薦。如何讓手機客戶端和不同瀏覽器都能受益于 Serverless 架構呢？

這又牽扯出了另一個詞，BFF，Backend For Fronted，即為前端定做的后端，這受到了前端開發工程師的推崇，Serverless 技術讓這個架構廣泛流行，因為前端工程師可以從業務角度出發直接編寫 BFF，而無需管理服務器相關的讓前端工程師更加頭疼的事情。

事件觸發

下面通過介紹一個具體的業務場景：對于事件觸發類的場景，闡述 Serverless 架構是怎樣解決問題的。前面提到的動態頁面生成是同步請求完成的，還有一類常見場景，其中請求處理通常需要較長時間或者較多資源，比如用戶評論中的圖片和視頻內容管理，涉及到如何上傳圖片和處理圖片（縮略圖，水印，審核等），視頻處理以適應不同客戶端播放需求等。比如該圖中業務場景是一個買家秀，當買家完成了交易，想要發表圖片或者視頻的評論，買家完成后，后端的服務要對這個圖片加水印，然后縮放并且審核；視頻也需要做多種格式的轉換和審核，因為要適配各種不同的終端。

這種業務特征實際上是非常耗 CPU 的，每次任務執行的時間一般比較長，因此針對于這種業務，我們可能會有一些技術架構的演進。

比如大家所熟悉的抖音，就是用戶上傳視頻的業務場景。在抖音后端也是需要對視頻進行統一處理的：如加水印，轉碼成各種不同的碼率或者是長寬分辨率去配適不同的手機。這個業務落戶是十分消耗 CPU 計算資源的。同時帶寬的壓力也很大。這個時候你只能不停地加帶寬，加機器，其結果就是運維和維護成本不斷增加；第二個問題就是會存在波峰波谷，比如說早上 8 點鐘的地鐵時間和中午吃飯的 1 鐘或者晚上 8 點鐘的時候，業務量可能是非常高的，如果你的業務需要 1000 臺機器，但是到了凌晨，這 1000 臺機器可能就用不上，因此便會造成資源的一些浪費，同時你還要處理運維監控，擴彈性，擴縮容等工作。

將架構演進再延伸一下，事件觸發能力是 FaaS 非常重要的特性，這種 Pub-Sub 事件驅動模式不是一個新的概念，但是在 Serverless 流行之前，事件的生產者，消費者，以及中間的連接樞紐都是用戶負責的，就像前面架構演進中的第二個架構。Serverless 讓生產者發送事件，維護連接樞紐都從用戶職責中省略了，而只需關注消費者的邏輯，這是 Serverless 的價值。函數計算服務還集成其它云服務事件源，讓你更方便的在業務中使用一些常見的模式，如 Pub/Sub，事件流模式，Event Sourcing 模式。

服務編排

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

比如說用戶在淘寶里面進行了購物，或者說在餓了么下單了外賣，它都是涉及到一個訂單的流程。這種訂單流程是比商品展示更為復雜的。因為在訂單流程里面，它所要保留更多的事情。比如有用戶下單時，我們第一步要檢查庫存，庫存儲量夠的話，然后庫存減 1 ，隨后接通支付寶或者說微信的服務去支付扣款，單子下來了以后，還要安排物流去配送，同時還要查看物流的詳情并進行短信通知等等。

同時在這些代碼邏輯中你要寫各種重試邏輯。如果說最終失敗的話，我們便要對已完成的事情進行回滾，如若用戶取消訂單，那么需要回滾的則更多。比如說這個錢要退還給用戶，這個場景是是非常復雜的，我們可以看一下這個流程怎么發起來的。比如說第一步用戶下單之后，其實是走到了這個訂單服務，這個訂單服務會生成訂單號；然后會涉及到買家是誰，賣家是誰。第二步我們會把消息發送到消息總線，其他的這些服務（配送服務、庫存服務、支付服務）是訂閱到消息總線的。

另一方面它的可觀測性、可描述性并不好，其次在編排上，它的復用性很差。如若說開發者改成了另外一個流程的服務，那么這一套就要重新改寫了。

在這個 Serverless 架構里，各個服務直接是獨立的，也不通過事件傳遞信息，而是有一個集中的協調者服務來調度單個業務服務，業務邏輯和狀態由集中協調者維護。從網關層下單后，觸發函數計算的一次函數執行，函數執行的邏輯會觸發一個工作流的執行。就比如說右邊這張圖其實就是用戶自己去編寫的，這個流程，就是工作流。

比如說第一步下單，第二步付錢，付錢成功了會如何，付錢失敗了應該怎樣。整個訂單就相當于是右側流程的執行。而每次流程的執行都是可以被追溯的。你可以理解成他就是個組織者，然后調用其他的云服務。

所以在這個架構，我們可以看出對開發者而言，不需要去做消息總線，從事邏輯的處理，維護數據的一致性等。他只需要專注他的業務邏輯，把每個流程調用的服務寫好，把這些編排的流程寫好就可以了。

• 編寫大量代碼來實現編排邏輯、狀態維護和錯誤重試等功能，而這些實現又很難被其它應用重用。

• 維護運行編排應用的基礎設施，以確保編排應用的高可用性和可伸縮性。

• 考慮狀態持久性，以支持多步驟長時間運行流程并確保流程的事務性。

如果直接依賴于云上的服務，比如阿里云的 Serverless 工作流服務，這些事情都可以交給平臺來做。用戶又回到了只需關注業務邏輯的狀態。右圖是流程定義，我們可以看到這實現了前面基于事件的 Saga 模式的效果，并且流程的復雜度大大簡化。

Serverless 技術毫無疑問將會承擔更多的責任，讓用戶更快更好的構建應用。使用 Serverless 架構可以覆蓋很多場景，這里只是介紹了 Web 網站前端后端，微服務，事件觸發，服務編排等幾個場景的架構。Less is more 把事情交給可靠的平臺（比如云廠商）去做，讓開發者可以更加聚焦自身的核心業務價值，是 Serverless 所一直推崇的理念。

作者簡介：西流｜阿里云智能云原生函數計算技術專家

負責阿里云函數計算產品功能開發（runtime 開發、事件源集成以及企業級 Serverless 解決方案落地等），目前專注在 Serverless 開發者工具鏈的建設，是云原生 Serverless Dev Tools 研發負責人之一，主導了 S/FC 組件的開發工作。關注 Serverless 最新技術動態以及在企業級解決方案的落地，致力于推動 Serverless 在開發者群體的流行

相關鏈接：

1）社區官網
http://www.serverless-devs.com/
2）項目倉庫
https://github.com/Serverless-Devs/Serverless-Devs
3）Serverless Desktop 桌面客戶端
https://serverlessdevs.resume.net.cn/zh-cn/desktop/index.html
4）Serverless 應用開發者套件
http://serverless-dk.oss.devsapp.net/docs/tutorial-dk/intro/react
5）Serverless Devs CLI
https://serverlessdevs.resume.net.cn/zh-cn/cli/index.html
6）Serverless Hub 應用中心
https://serverlesshub.resume.net.cn/#/hubs/special-view

了解更多云原生相關信息，請掃描下方二維碼或搜索微信號（AlibabaCloud888）添加云原生小助手！入群即可獲云原生一手資訊~

總結

以上是生活随笔為你收集整理的Serverless 架构模式及演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。