# Serverless 架構演進與實踐

# **1. 介紹**

Serverless 並不僅僅是一個概念，很多地方都已經有了它的影子和思想，本文將給大家介紹最近比較火的 Serverless。

首先放出官方對 Serverless 的解釋：

Serverless 的全稱是 Serverless computing 無伺服器運算，又被稱為函式即服務（Function-as-a-Service，縮寫為 FaaS），是雲端計算的一種模型。以平臺即服務（PaaS）為基礎，無伺服器運算提供一個微型的架構，終端客戶不需要部署、配置或管理伺服器服務，程式碼執行所需要的伺服器服務皆由雲端平臺來提供。國內外比較出名的產品有阿里雲 Function Compute、AWS Lambda、Microsoft Azure Functions 等。

有人說它是雲端計算的未來，代表了一種技術趨勢、理念和發展方向，因為不是官方科普，說說個人的理解。

- 首先 Serverless 代表了一種思想或者服務理念，使用者無需再關心除了業務邏輯之外的機器資源容量、配置管理等事項，不需要關注運營維護，是一種去 DevOps 的理念；
- 然後他又是一種全新的架構模式，透過一系列技術手段使得各項資源都到最充分的利用；
- 同時也是一種雲服務產品的形態，現在已經陸續開始有云產品 (比如阿里雲的資料倉儲 PostgreSQL、阿里雲多模資料庫 Lindorm、阿里雲 MongoDB) 開始提供 Serverless 版本支援，這個可以理解為服務的 plus 的版本，比如我們常見的 MySQL、Redis、ES、分散式 ID、MQ 等一系列的服務，如果提供了 Serverless 版本的支援，那我們不再需要關心這些服務的申請機器、資源部署、資源碎片、彈性擴縮容問題，不再需要日夜值守關心各個依賴元件各項指標出現的問題，我們只需要聚焦在自己的上層業務邏輯上進行實現和最佳化，並且再也不會有閒置資源或者碎片資源問題 (按需使用)，這個就是 Serverless 想要構建的架構體系。

## **2. 架構演進**

![img](https://oscimg.oschina.net/oscnet/up-b6c8598120cc2234f12b73645592ca576a5.png)

早期的軟體部署模式是透過採購物理機的形式，有多大規模採購多少臺機器，採購多了或者配置差了都會存在比較大的資源浪費。

虛擬化技術出來後緩和了這個問題，允許將物理機切分成一個一個 VM 例項，一臺機器上可以執行多個例項，採購多了那就執行其他服務，配置差的機器多執行一些例項，配置好的少執行一些，但是虛擬化本身還是挺重的，每個 VM 需要維護自己的 OS 核心，切的越多浪費越大，並且不利於維護統一基線，安裝外掛配置 agent 上傳指令碼很容易造成應用內一批機器不一致，並且銷燬重建也不是那麼容易的事情，這個階段運維的事務性工作還是不少。

接下來雲的浪潮鋪開，傳統的伺服器廠商開始轉型擁抱雲，將自己的伺服器搬到雲上透過虛擬化技術進行線上售賣提供基礎 IaaS 服務，到這個階段僅僅是轉變了商業模式，上面的問題依然還是存在。

再到後面 docker 容器技術產生，docker 本身還是一種虛擬化技術，但是他是依託於宿主機作業系統之上的虛擬化，僅僅只是一個獨立程式共享 OS 核心，資源碎片和記憶體佔用浪費問題會少很多，並且重建銷燬比較容易，非常利於維護應用統一基線，透過一套標準映象自定義 dockerfile 進行統一交付，一次構建到處執行，運維可以脫離繁瑣重複的工作去做更多工具類的產品。

![img](https://oscimg.oschina.net/oscnet/up-60c9a4ef3a0fd98437d1fd1253fcb108f94.png)

DevOps 概念在這個階段變得火熱，大廠內甚至要求消滅運維，強制運維轉型開發，想起來也不無道理，在 docker 技術出來之前，一次建站往往需要運維們準備一堆指令碼和安裝順序手冊，搭建作業系統環境，安裝閘道器、DB、軟負載等一系列中介軟體，編譯配置安裝然後使得服務可用，中間一旦有一個步驟出錯還得從頭再來，但是運維往往是不瞭解應用的，啟動不起來配置錯誤報錯資訊等問題還是需要開發介入，而讓開發來負責上線部署，很多服務軟體不知道如何部署，兩者中間有一道很明顯的鴻溝，所以一次建站或者新平臺的搭建，需要拉上運維和開發通宵好幾個晚上一起攻堅，效率低下，這個時候急需一個瞭解開發的人把運維的事情幹了，而容器技術出現之後，就如上面介紹，docker 映象統一基線使得建站部署變得更加標準化和簡單，開發運維一體化這個事情就會變得水到渠成，透過 dockerfile、swarm 叢集編排或者 k8s 可以很容易的讓開發把運維的事情幹了，這個時候運維自然會顯得多餘，當然完全消滅運維也是不可能的，變革是漸進式的，需要有一些人去負責歷史包袱的資產系統，同時與開發有更好的協同具備提升系統穩定性和做自動化工具化系統研發能力的 SRE 出現也代表了運維轉型的決心。

到目前為止，還是停留在開發需要關心運維的階段，但是隨著 docker 技術的普及，很多運維相關的工作已經變得非常容易了，這個時候雲廠商開始考慮是否可以把運維這個事情從開發手中收走，讓運維自動化，變得對開發更加透明，開發人員只需關注核心業務邏輯的開發，進而精益整個產品開發流程，快速適應市場變化，這個時候 Serverless 的概念開始產生，所以從這個角度來看，在整個 it 架構演進中，docker 的普及無疑是進一步推動了 Serverless 的快速發展。

從整個演進過程中來看，一直都在朝著資源切分粒度越來越細 (物理機 -> 作業系統 -> 程式 ->function)，資源利用率越來越高，運維工作逐漸減少，開發更聚焦業務的方向發展的，Serverless 的產生也是符合歷史發展的一般規律。

## **3. 應用場景**

一個比較典型的應用場景是雲上的巡檢產品，業務很簡單類似於 360 安全衛士，定期巡檢雲使用者的三方依賴元件，產出包括安全、效能、穩定、成本的巡檢報告並且給出建議，由於需要和一些微服務治理高可用等產品做捆綁售賣，本身也是免費產品，以前的 ECS 部署模式成本較高也不是很靈活，所以需要做改造來適應現在的雲原生環境，準備將其託管到雲上 Function Compute Serverless 平臺，部署架構如下圖：

![img](https://oscimg.oschina.net/oscnet/up-29fd200a37ee87ca66ba752908c013f7d3a.png)

這是一個比較典型的依託於 Serverless 平臺的 SaaS 應用交付，即我們提供了一套通用的程式碼模板，提交給了 Serverless 平臺進行執行，服務開發商也就是我們無需關注承載服務的系統架構和資源運維，不會因為服務的客戶越來越多而導致運維負擔或者設計重構問題，只需要關心服務業務的實現，然後消費方開箱即用，這套模板可以無限複製給更多的使用方，只要模板是固定的，不管未來新增多少個三方依賴元件要加入巡檢，我們都只是新增模板實現然後提交任務給 Serverless 平臺而已，而由採集端負責觸發任務執行，對於應用或者業務的創新成本都是極低的。整個 Serverless 平臺就是 FaaS 和 BaaS 的組合服務，FaaS 是函式即服務，負責執行任務例項，BaaS 是後端即服務，是任務依賴的三方依賴元件透過 API 的形式提供資料，你可以在 Serverless 平臺編寫程式碼 (FaaS 能力)，然後呼叫一些第三方依賴元件的 API 進行資料互動 (BaaS)。

## **4. Serverless 如何影響微服務**

微服務和 Serverless 並不衝突，一個微服務應用可以是基於 Serverless 架構搭建部署的，也可以是傳統的先申請資源再進行部署的方式，Serverless 本身是技術架構，而微服務是業務架構，經濟基礎決定上層建築，底層的技術架構形式會影響上層的業務，當 Serverless 以 function 為粒度提供服務的時候，對於上層微服務的架構組織帶來了新的契機。

以前的微服務更多是以應用的形式來組織的，一個應用關注一個特定的業務功能集合，很多服務可能都會使用到相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而導致程式碼重複。儘管可以使用共享庫來解決這個問題 (例如可以將這個功能封裝成公共元件，需要該功能的微服務引用該元件)，但共享庫在多語言環境下就不一定行得通了，而在 Serverless 架構中以 function 為最小粒度組織的模式下，你的業務分隔粒度可以無限的小，任何一個模組功能甚至方法都可以獨立存在，不再需要透過共享元件程式碼複用強耦合的方式來組織應用，在 Serverless 架構中，微服務元件的相互隔離和模組松耦合可以做的更好，應用甚至可以以獨立函式的形式存在，當然這不代表你的微服務拆的越細越好，也需要考慮到你的業務邊界定義是否有利於不同團隊組織之間獨立工作，這裡不展開討論，事實上雲廠商們已經開始進行了這方面探索，將 Serverless 和微服務打包做成組合拳產品提供解決方案。

![img](https://oscimg.oschina.net/oscnet/up-6706b30b14724cad2457c8f3299e24a4e67.png)

## **5. Serverless 和雲原生的關係**

Serverless 就是為雲而生的東西，天生具有云的基因 (免運維彈性伸縮按量計費)，使用者將服務託管給了雲廠商，只需要聚焦業務邏輯不需要去關心和管理資源問題，是對容器技術的封裝，代表了雲原生的高階階段。

## **6. Serverless 要解決的問題**

在我們公司內部其實也有類似和 Serverless 相似的產品，比如演算法推薦平臺，他本身提供的是 FaaS 服務，希望能夠讓使用者更快更好的實踐自己的演算法而不用關心機器部署配置的一些細節，但他還不是一個 Serverless 模式，實現 Serverless 需要有對應幾個能力的建設，首先先介紹下 Serverless 要解決的幾個問題。

- **機器資源分配不均**

一個大型系統因為需要支撐各種業務，往往會拆分叢集來進行業務隔離，不同叢集由於業務的特性，會出現差距較大的資源利用率，這顯然是對資源的一種浪費，當然透過人肉運維調整叢集機器配比可以解決這個問題，但是這種重複勞動本身也是對人效的浪費。

![img](https://oscimg.oschina.net/oscnet/up-9aeaea0b7dd5313cbe0054ecb68518ad302.png)

- **錯峰問題**

每個流量本身就有一定的規律，比如白天流量高晚上流量低，大促流量高常態流量低，如果就為了一天 1 個小時的高峰流量來準備全天的機器，那剩下來的那 23 小時也是一種資源的浪費。

![img](https://oscimg.oschina.net/oscnet/up-15c5c03eee7c81579106a3d26a6db640f3a.png)

- **碎片化問題**

微服務（博主的環境都是部署在[cnaaa伺服器](https://www.cnaaa.com/)上的）之間的資料互動主要是 RPC 和 MQ，常見的 RPC 框架本身就有比較完善的探活和負載均衡機制能夠保證流量在不同機器的的均衡性，而 MQ 受限於順序消費、失敗重發、訊息分割槽等特性沒有辦法很好的保證消費端負載均衡，比如我們常用的 RocketMQ 預設使用了一種分頁的演算法，即在客戶端將消費者和分割槽分別按照字典序排好，再按照平均分配的原則每個消費者分 "一頁" 的分割槽，所以這裡就會引申出碎片的問題，當一個叢集中消費的 Metaq 訊息都是小分割槽的訊息，所有的訊息都會被流入叢集中的前幾個機器中，造成叢集整體流量不均，帶來叢集資源碎片。

- **資源問題**

對於新接入的使用者和業務，我們常見的做法是評估峰值業務量然後為其開啟新叢集預先分配一批機器，這裡就有兩個問題，一個是對於資源的預先評估是否能夠準確而不造成浪費，另一個是成本結算方式，如果使用機器數來給使用者或者業務方結算成本，對於有明顯波峰波谷的使用者來說也是一種很大的成本資源浪費。

- **運維問題**

在每次大促或者壓測之前都需要提前擴縮容準備資源、修改叢集配置，隨著各種大促小促和壓測次數越來越密集，這種運維開銷成本也變得越來越大。

## **7. Serverless 特性**

Serverless 的產生就是為了解決上面這些問題，它應該具有的特性有：

- **FaaS 化**

FaaS 化的目的是為了做任務的抽象標準化和對業務的更細粒度拆分，以函式的方式進行組織，這和我們常說的流程化編排元件化建設其實初衷是一樣的，如果有了這一層抽象，任何業務形式都可以在這個標準化平臺上像搭積木一樣進行構建，並且對於業務元件化和資源拆分的粒度是 Function，這個對於上層微服務的架構組織帶來了新的契機，上面篇幅已經介紹過這裡不再累述。

- **無維護**

這裡不是真正的沒有維護，而是機器幫助人去實現自動化運維進行彈性擴縮容，管理員不必關心應用執行的狀態，是否在工作，是否有資源碎片等等，任務不再是固定的跑在某個叢集裡，而是可以在任意機器裡進行遷移。

- **按需使用**

有了 Serverless，應用水位會維持在一個固定的範圍，什麼時候該擴容什麼時候該縮容都由平臺按照當前的負載情況來決定。

- **按量收費**

根據執行次數執行時間來計算費用，只為實際使用的計算資源付費，是一種資源粒度精細化的管理模式。雲端計算歸根結底是一種 IT 服務提供模式，不論是公共雲還是專有云（以 IT 裝置的歸屬不同分類），其本質都是幫助 IT 的最終使用者隨時隨地，並且簡便快速地獲取 IT 服務，目前的 IaaS、PaaS 都已經做到了按需付費，PaaS 甚至做到了按請求付費，如 DB、CACHE、MQ 等，但是 IaaS 的付費粒度仍然是時間維度，最快按照小時付費，以分鐘來交付。因此，當下的雲端計算場景，應用的開發維護方式相比傳統 IDC 時代的開發維護，差別還不是很大，本質上都是做預算然後購買交付，但 Serverless 平臺提供了一種全新的開發維護方式，使用者只需要寫好業務程式碼，提交到雲上，所有和機器容量、可用性、機器為單位的運維工作可以全部交給雲平臺，這種模式極大的釋放了雲的彈性價值，真正做到了按需付費。

- **事件監聽**

Serverless 中的 function 透過事件監控的方式被觸發執行，這裡的事件監聽可以是 HTTP API 觸發、訊息監聽、定時觸發、控制檯觸發。

## **8. 如何實現 Serverless 平臺**

結合上面說到的 Serverless 特性，我們的任務都以函式的方式進行組織，任務可以在任意機器裡進行遷移和啟動，並且支援自動彈性擴縮容，為了實現這些特性，大前提是我們需要保證函式的無狀態。

- **無狀態**

在 Serverless 平臺中由於執行函式的容器是不確定的、執行順序也不確定，一個容器可能會被併發的執行多次，也不存在執行順序，函式執行時根據業務彈性，可能伸縮到 0，所以無法在執行環境中儲存狀態資料，這就要求我們的函式是無狀態的，以便於隨時進行水平伸縮，否則可能會出現一些意料之外的結果，比如:

![img](https://oscimg.oschina.net/oscnet/up-cba565aecb78abb1f13e30e8c3ade143cdc.png)

如果連續兩次執行 handler (3)，會得到不一樣的結果，因為這裡儲存了狀態變數 sum，兩次執行間共享了這個狀態變數，影響了最終執行的結果，所以無狀態也是要求函式開發者在編碼過程中保證儘量少的使用外部變數，但是也不代表完全不使用外部變數，對於一些有限資源比如資料庫連線，這部分資源是可以被複用的，我們可以提前在函式外進行提前初始化，這樣當容器預熱之後就可以直接使用；還有一些狀態資訊比如登入狀態，我們可以利用外部服務、產品，例如資料庫或快取，實現狀態資料的儲存，以便可以用來獲取登入資訊。

- **快上快下**

因為按需使用的特性，對於長時間不使用的函式會主動退出以節省記憶體，當函式呼叫請求傳入時，我們會檢查是否已有一個空閒的容器可以使用，如果沒有那就需要重新拉起一個容器啟動，這個就是 "冷啟動" 問題，一個容器的拉起和函式初始化載入工作需要一定的時間，冷啟動會拖慢函式的響應速度。對此業界最常見的做法是準備 buffer 池，提前申請一部分資源，拉取映象建立容器載入資源包，這樣當有突發流量進入、執行中容器無法承載的時候，會自動進行快上快下，將 buffer 池中預熱好的容器拿出來直接灌入流量，而流量下降後，執行中容器負載下降則會自動進行快下操作，將一部分容器摘流放回 buffer 池中，那這裡有同學可能會問如果提前準備 buffer 機器那不是違背了 Serverless 降低成本的初衷了嗎，注意 buffer 池中的資源並不是一個高優先順序的絕對資源佔用，他實質上並不屬於任何一個應用的，預先載入多少 buffer 資源也是由 Serverless 平臺的演算法策略決定，所以在資源緊缺的情況下完全可以挪出去供其他業務使用，一般不超過 Serverless 平臺總機器數的 10%，是一種在程式複製技術還不成熟的情況下的折中方案。

![img](https://oscimg.oschina.net/oscnet/up-3bb1f24d6d8d9f8cf84f251f62fcc24ca2f.png)

- **統一叢集**

引入叢集的目的是做分治管理，來提高機器集中運維效率，而在 Serverless 平臺中，所有機器均被統一的部署和管理 (同一物理區域內)，叢集管理的方式已經失去了意義，Serverless 平臺的機器全部跑在一個大叢集中被無差異的執行，機器實際使用量根據實時水位自動進行調整。

- **混合部署**

標準的 Serverless 平臺應該是一容器一函式的部署方式然後透過容器的資源隔離能力做到完全的隔離，但是實操過程中由於管理的需要，往往是一容器多函式的部署方式，當然也有效能方面的考慮，因為頻繁的建立銷燬容器做資源隔離也會帶來資源消耗 (容器資源隔離透過核心 cgroup 機制實現)，過多的 cgroup 組會對核心造成額外的開銷。之前在實踐中曾經遇到過一個線上問題，當時發現只要和 Serverless 平臺混部的應用 sys CPU 都會莫名的高出一截，因為做了執行緒級別的 CPU 隔離 (透過建立 cgroup 組進行執行緒 pid 繫結的方式)，但是在函式退出時沒有做 cgroup 的清理，導致宿主機因為繫結過多 cgroup 組 (上萬) 進行了核心態空轉引起 sys CPU 飈高，所以控制宿主機上容器的數量以及使用一容器多函式的部署方式還是很有必要的。

混合部署的方式徹底解決了之前說到的碎片化問題，函式可以自由排程，各個機器都得到了充分的利用。雖然是一容器多函式的部署方式，但是也不是意味著就可以隨意的混部，混合部署會盡量做到各機器的水位均衡，也就說到下面的自動排程的話題。

![img](https://oscimg.oschina.net/oscnet/up-8948b3bfdca1e5f1c000945af7770abacd6.png)

- **任務分類**

我們在第一版測試中，為每臺機器都設定了相同的執行緒池執行緒數，最後的結果是機器負載非常不均衡，因為不同的函式執行耗時不同，以前可以透過叢集來隔離這些不同的業務為每個叢集預設不同的執行緒池配置，而現在 Serverless 平臺統一了叢集，不同的函式可以在機器間任意遷移，當機器中存在耗時較高的任務，執行緒池立馬被佔滿來不及消費，但是機器水位很低，這種情況下再給他分配任務反而會加劇這個問題，當機器中都是耗時較低的任務時，水位會保持的較高。

所以為了規避這個問題，我們將函式進行了分類，分為 IO 密集型任務和 CPU 密集型任務，事先分配好兩個執行緒池，IO 密集型任務跑在 IO 執行緒池中，CPU 密集型任務跑在 CPU 執行緒池中，由於 CPU 密集型任務可以近似認為是純 CPU 計算型，所以 CPU 執行緒池執行緒數近似等於核數大小，IO 密集型任務由於不同的任務耗時也大不相同，所以採用累加的形式，每個 IO 函式都要設定使用的 IO 執行緒數，該容器上 IO 執行緒池的執行緒數等於所有 IO 函式設定的執行緒數之和，這是一個動態的數，會隨著任務排程而變化。

- **自動排程**

之前說到 buffer 池的方案中需要提前預熱一批資源，如何設定合理的 buffer 池資源數量以保證成本和效率的最優解是比較重要的問題。

在第一版的嘗試中我們引入過多個指標的資料透過綜合判定來進行排程，這裡的指標包括系統指標 CPU、load 和業務 SLA 指標、佇列堆積量、執行 RT，但是最後會發現，透過這些指標並不能很好的均衡各機器的水位，因為不同函式的瓶頸並不完全一致，有 IO 密集型的，有 CPU 密集型的，一個場景可能在 CPU 不超過 30% 的情況下，就已經出現了容量不足的問題，有的場景高水位 CPU 執行的很好，但是有的場景相對較低的 CPU 可能就出問題了，或者機器本身的問題導致的 load 突然飆高，佇列堆積增加的問題，其實並不是容量不足導致的。所以透過系統指標和業務指標並不能很好的衡量機器當前的水位。

透過對第一版的分析，我們發現這中間最主要的問題是我們一直在透過外部表象資料來判斷機器水位，而這些資料在不同業務場景下表現又不盡相同，還容易受到外部環境的干擾造成資料抖動。所以在第二版中，我們增加了負載率的概念，在講負載率之前先看一下並行度的概念，並行度 (執行緒數) 理論值為:

![img](https://oscimg.oschina.net/oscnet/up-a55690a2fb1e6482ab797330e6c2af9759a.png)

但是由於混合部署，每個函式指令碼都不相同，導致整個機器上總的執行緒等待時間與執行緒 CPU 時間之比是一個不確定值，所以並行度是一個經驗值設定，CPU 密集型規則可以儘可能靠近核數以提高 CPU 的資源利用率，IO 密集型可以調大，但是不是一味的調大，過多的執行緒數會導致頻繁的上下文切換等損失，反而降低了效能，畢竟 CPU 時間片有限，太多並行度也執行不過來，並行度和資源利用率近似如下圖的關係 (正相關的折線，到達最佳並行度後資源利用率開始緩慢下降)。

![img](https://oscimg.oschina.net/oscnet/up-bd59d02a503f37904b22f197291893c64ae.png)

所以為了達到最佳並行度，每臺機器上的執行緒數都是一個動態變化的值，和這臺機器上跑了哪些任務有關係。

負載率是用來衡量執行緒池利用率的指標，這個指標只和單機的執行緒池配置和流入的任務量有關，和這臺機器的外部表象指標 (CPU load 任務堆積量等等) 都沒有關係，定義為:

![img](https://oscimg.oschina.net/oscnet/up-4946a4c97c3bc8e8a6db3dac6712d02e2bc.png)

負載率是在並行度基礎上的概念，當並行度不變時，耗時總和越大負載率越大，但是不會超過 1，達到 1 說明機器的執行緒資源已經全部使用了，要麼提高並行度要麼擴機器。負載率還有一個意義在於可以精確的獲取每個任務消耗執行緒資源的比重以便於進行比較精確的任務排程，因為 IO 密集型和 CPU 密集型任務已經用不同執行緒池進行了分隔，可以把這個消耗執行緒資源的比重，近似認為是消耗機器資源的比重。

自動化排程是第一步，再往下就是基於基線和時間相關性做一些演算法智慧化排程的探索，因為沒有實踐過這裡不展開討論。

- **排程預熱的處理**

當容器啟動後到灌入第一批流量期間，存在一段時間執行能力較差，負載率偏高的問題，因為對於 Java 來說當一個新加容器在到達 100% 服務能力之前需要充分的程式碼預熱 (python ruby 這類指令碼語言可能會好些)，為了防止在預熱期間負載率偏高造成錯誤的排程，增加了對於預熱期的判定，只要有一臺機器正在啟動，排程就停止，直到啟動完成後一段時間再恢復排程。

- **最大消費者數**

訊息消費的負載均衡取決於上游訊息中介軟體，比如對於 RocketMQ 來說訂閱者數必須小於消費組佇列數，才能保證每個訂閱者都有訊息可消費，否則會出現部分訂閱者無訊息消費的問題，如果排程策略不考慮 RocketMQ 每個 topic 的佇列數情況，無限制的增加訂閱者，最後又會出現上面提到的碎片化問題。所以必須保證每個訂閱者都有訊息消費，每次排程都是有效的排程。

為了解決這個問題，我們增加了一個最大消費者數的概念，對於單個任務來說能夠分配的消費機器數必須小於等於這個任務對應的 topic 的最大消費者數，防止出現無效的排程。對於 RocketMQ 來說最大消費者數等於該 topic 佇列 (分割槽) 數，對於 DRC 來說，不支援負載均衡所以最大消費者數等於 1，其他訊息中介軟體依此類推。

- **排程策略**

我們的排程策略是把負載率控制在一個穩態區間，然後結合最大消費者數進行排程。比如單機的 CPU 密集型任務負載率範圍設定為 5%-30%，大於這個值則給 CPU 密集型任務中負載率最高的前 5 個任務擴容器，如果所有線上容器都已經在消費該任務則從 buffer 池快上容器來給任務擴容，如果已經擴充至最大消費者數，則進行任務遷移，將這臺機器上的任務遷移至低負載率的機器上；小於這個值則將該機器快下放進 buffer 池。IO 密集型任務的排程也是類似，最終的目標是將所有線上機器收斂至穩態區間，同時為了避免在任務擴縮容和機器快上快下上出現 "擴過了頭" 或者 "縮過了頭" 的情況，限制了單次擴縮容的機器數和單臺機器排程的最小時間間隔，也是防止一臺機器剛剛任務擴容又立馬任務縮容或者快下。

我們來考慮幾種典型場景在這種排程策略下的應用:

1. 某個訊息 topic 任務的 TPS 高，佇列數 (最大消費者數) 小，只要消費該任務的機器負載率都偏高，因為負載率超出了設定的穩態區間，排程策略對其進行任務擴容，但是已經達到了最大消費者數，只能進行任務遷移。最後這個任務會一直處於一個動態平衡中，即任務不斷的在不同的機器裡遷移，達到了一種超出佇列數負載均衡消費的效果。
2. 某個 topic 佇列數很大，突然流量猛增，造成消費該 topic 的機器負載率都偏高，此時進行任務擴容，直到擴充到所有的線上容器，如果負載率還是偏高，則進行 buffer 池快上容器，直到 buffer 池的機器全部被快上或者負載率進入穩態區間範圍。流量恢復正常後，因為很多的機器都在負載均衡消費該 topic，造成機器負載率降低 (尤其是之前快上的機器只消費該任務)，一部分負載率較低的容器會被快下進 buffer 池，此時恢復至最初的狀態。
3. 很多 topic 一起流量猛增，造成消費這些 topic 的機器負載率都偏高，此時對這些 topic 進行任務擴容，直到擴充到所有的線上機器或者達到最大消費者數，如果負載率還是偏高，則進行 buffer 池快上機器，為了防止出現 "擴過了頭" 的問題，一次只將負載率最高的前 5 個任務的 topic 擴充至快上的機器中，隨著負載率最高的前 5 個任務不斷的增加機器，它們的負載率會下降，之後負載率最高的任務排名發生了變化，換成了另外 5 個任務，對它在進行擴容或者快上，慢慢地所有流量猛增的 topic 都會被擴容，最終就會達到穩定區間狀態。
4. 第一次任務分配的容器不均，導致大部分任務都分配給了相同的一組容器，這部分容器會出現負載率偏高的現象，對這些容器中的任務進行擴容，直至擴容到最大消費者數，如果之前的那組容器因為分配的任務過多，導致負載率仍然偏高，繼續進行任務擴容，但是已經達到最大消費者數，此時會進行任務遷移，將負載率最高的容器中的負載率排名前 5 的任務進行任務遷移，遷移至負載率較低的容器中，之前的那組機器分配的任務數會被逐漸遷移開來，達到和其他機器平均分配任務的效果。

## **9. 遇到的問題以及建議改進**

- **混部策略**

混合部署中僅僅以水位為依據進行隨機混部對於比較核心的任務不是很友好容易被資源搶佔，需要設定不同的任務等級標籤和混部策略，保證資源不足的情況下高等級任務被優先執行保證 SLA。

- **自動降級機制**

如何防止某些實現有問題的任務，消耗大量的資源，不斷觸發擴容，從而掏空整個叢集，影響正常規則的執行，引發不公平，我們可能需要增加一種自動降級機制，針對某些不重要的任務或者問題任務在資源不夠的情況下或者在預熱的時間段觸發降級。

- **擴縮容速度**

雖然現在針對單次任務排程或者 buffer 池機器快上可以做到秒級，但是為了避免擴過了頭或者縮過了頭的問題，我們限制了單次任務擴縮容和快上快下的機器數，所以目前擴縮容對於相對較小的流量猛增可以做到秒級，但是對於幾百倍甚至幾千倍的流量猛增需要一定次數的擴容迭代週期來達到最終平衡，目前的策略雖然能很好的支援常態期間的秒級排程，但是對於大促場景還需要進行一定的改進。

- **自動壓測機制**

目前問題函式的發現依賴於線上真實流量，這是一種亡羊補牢的方式，而且任務的執行緒數配置和 CPU 密集型 IO 密集型的劃分也是依賴於人工判斷，存在預判的誤差，如果有一套自動壓測機制，針對每一個新上線的規則進行自動壓測，獲取它的效能資料，自動判斷是否存在問題並且劃分任務型別設定執行緒數，對於排程和 buffer 池容量評估也能提供更加科學準確的依據。

## **10. 總結**

本文介紹了在接觸實踐 Serverless 中遇到的一些實際問題和做法，當應用規模擴充套件到一定程度的時候，勢必會要求做更精細化的資源管理，比如上面說到的資源分配不均、碎片化、錯峰資源、混合部署、運維等等問題，透過 Serverless 的架構模式來實現自動化運維排程以及更加靈活的彈性，能讓系統資源做到更加合理充分的利用，也讓雲的紅利離我們越來越近。

Serverless 架構演進與實踐

相關文章