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

# Serverless 架構

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

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/22169fd0adfb4ddf912c7616ed0fd3ef~tplv-k3u1fbpfcp-zoom-1.image)

- 隨著需求和技術的發展，業界出現了一些 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 架構時，最重要的心智不是選擇哪些流行服務和技術，攻克哪些技術難題，而是時刻銘記在心專注業務邏輯，這樣更容易讓我們選擇合適的技術和服務，明確如何設計應用架構。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/61c0f741bc75475cb4cebc46095f6fe4~tplv-k3u1fbpfcp-zoom-1.image)

# 靜態站點

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

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d0cb7e6149c4913a48e5531a8d76979~tplv-k3u1fbpfcp-zoom-1.image)

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

- 它的頁面是偏靜態的展示資訊。

- 其頁面更新並不頻繁。

- 不確定訪問量。

# 架構的演進

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

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/206b3cd3652c4d26b310085191b70dcb~tplv-k3u1fbpfcp-zoom-1.image)

1. 買臺伺服器放在 IDC 機房裡託管，執行站點。

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

3. 採用靜態站點方式，站長直接將站點由物件儲存服務（如 OSS）支援，並使用 CDN 做快取。

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

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

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

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

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

- 安全性：這樣一個系統甚至看不到伺服器，不需要透過 SSH 登入，DDOS 攻擊也交給雲服務來解決。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/79cc0e1183e44dd090aea332e14b9cfd~tplv-k3u1fbpfcp-zoom-1.image)

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

比如說目前很多安卓應用，要釋出到如小米應用商店、華為應用商店等各種渠道商，開發者更希望的是打包好一個母包，放在物件儲存裡，而不是反覆做打渠道包維護等重複工作。對使用者來說，只需要維護一個母包，然後再維護一個簡單的動態計算即可。其實 CDN 不只可以回源到物件儲存，還可以回源到動態後端，如 API 閘道器，函式計算，負載均衡器等，也不止有 CDN 可以這種型別的快取，還可以使用 Redis，以及程式內的快取。

# 單體和微服務

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

- 淘寶的商品頁面，採用靜態頁面方式管理商品資訊是不現實的。商品數量眾多，商品上架、下架資訊更新頻繁，商品頁面複雜。

- 網易、新浪入口網站， 實時新聞不斷更新，評論、點贊， 轉發等

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e0dffdf944584f94a3b7ade3be21c308~tplv-k3u1fbpfcp-zoom-1.image)

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

1. 商品是海量的。

2. 更新頻繁。

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

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

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

2. 單體應用是需要自己購置伺服器執行，還是可以交給託管服務，如函式計算和 Serverless 應用引擎。

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

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

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

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ae2666149014f398e9ae74121877e31~tplv-k3u1fbpfcp-zoom-1.image)

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

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/49ebb0a6980245a1961f887bc0c881b5~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

# 事件觸發

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

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a90c3294c8284310aa17c22c7475c21a~tplv-k3u1fbpfcp-zoom-1.image)

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

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

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d9bd0f39566b45a0b2bfb4aab3f697e0~tplv-k3u1fbpfcp-zoom-1.image)

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

# 服務編排

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

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc16b212cef84475975b4e8f52724b56~tplv-k3u1fbpfcp-zoom-1.image)

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

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/17b226a48f484dfc864d7052c9b96497~tplv-k3u1fbpfcp-zoom-1.image)

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

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

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5af7fab04c96498a955a52c68077f998~tplv-k3u1fbpfcp-zoom-1.image)

在這個 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）新增雲原生小助手！入群即可獲雲原生一手資訊~
![二維碼.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cce933c029364c579c8f3e249369616e~tplv-k3u1fbpfcp-zoom-1.image)

Serverless 架構模式及演進

相關文章