每年，網(wǎng)上都會報道 XXX 系統(tǒng)異常不可用，給客戶帶來巨大的經(jīng)濟(jì)損失。云服務(wù)的客戶基數(shù)更大，一旦出現(xiàn)問題，都將給客戶和服務(wù)自身帶來極大影響。本文將基于華為云 FunctionGraph 自身的實(shí)踐，詳細(xì)介紹如何構(gòu)建高可用的 Serverless 計算平臺，實(shí)現(xiàn)客戶和平臺雙贏。

高可用介紹

高可用性[1]（英語：high availability，縮寫為 HA），IT 術(shù)語，指系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度。是進(jìn)行系統(tǒng)設(shè)計時的準(zhǔn)則之一。

業(yè)界一般使用 SLA 指標(biāo)來衡量系統(tǒng)的可用性。

服務(wù)級別協(xié)議[2]（英語：service-level agreement，縮寫 SLA）也稱服務(wù)等級協(xié)議、服務(wù)水平協(xié)議，是服務(wù)提供商與客戶之間定義的正式承諾。服務(wù)提供商與受服務(wù)客戶之間具體達(dá)成了承諾的服務(wù)指標(biāo)——質(zhì)量、可用性，責(zé)任。例如，服務(wù)提供商對外承諾 99.999%的 SLA，則全年服務(wù)失效時間最大為 5.26 分鐘（365*24*60*0.001%）。

FunctionGraph 直觀度量系統(tǒng)可用性的兩個黃金指標(biāo)，SLI 和時延，SLI 是系統(tǒng)的請求成功率指標(biāo)，時延是系統(tǒng)處理的性能。

高可用挑戰(zhàn)

FunctionGraph 作為華為云中的子服務(wù)，在構(gòu)建自身能力的同時，不僅要考慮系統(tǒng)本身的健壯性，也要考慮周邊依賴服務(wù)的健壯性（例如依賴的身份認(rèn)證服務(wù)不可用了，進(jìn)行流量轉(zhuǎn)發(fā)的網(wǎng)關(guān)服務(wù)服務(wù)宕機(jī)了，存儲對象的服務(wù)訪問失敗了等等）。除此之外，系統(tǒng)依賴的硬件資源故障或者系統(tǒng)突然遭到流量攻擊等，面臨這些不可控的異常場景，系統(tǒng)如何構(gòu)建自己的能力來保持業(yè)務(wù)高可用是一個很大的挑戰(zhàn)。圖一展示了 FunctionGraph 的周邊交互。

圖 1 FunctionGraph 的周邊交互

針對常見的問題，梳理出了 4 個大類，如表 1 所示。

表 1 FunctionGraph 常見問題總結(jié)

針對這些問題，我們總結(jié)了如下幾類通用的治理辦法。

1.流量突變治理

過載保護(hù)+彈性擴(kuò)縮容+熔斷+異步削峰+監(jiān)控告警，基于防御式的設(shè)計思想，通過過載保護(hù)+熔斷確保系統(tǒng)所有資源受控，然后在此基礎(chǔ)上通過提供極致的擴(kuò)容能力來滿足大流量，合適的客戶場景推薦異步削峰來減緩系統(tǒng)壓力，監(jiān)控告警用來及時發(fā)現(xiàn)過載問題。

2.系統(tǒng)服務(wù)異常治理

容災(zāi)架構(gòu)+重試+隔離+監(jiān)控告警，通過容災(zāi)架構(gòu)避免系統(tǒng)整個宕機(jī)，通過重試來減少系統(tǒng)異常對客戶業(yè)務(wù)的影響，通過隔離快速剝離系統(tǒng)異常點(diǎn)，防止故障擴(kuò)散，通過監(jiān)控告警快速發(fā)現(xiàn)系統(tǒng)服務(wù)異常問題。

3.系統(tǒng)依賴服務(wù)異常治理

容災(zāi)架構(gòu)+緩存降級+監(jiān)控告警，通過容災(zāi)架構(gòu)減少依賴服務(wù)單點(diǎn)故障，通過緩存降級確保依賴服務(wù)故障后系統(tǒng)仍能正常運(yùn)行，通過監(jiān)控告警快速發(fā)現(xiàn)依賴服務(wù)異常問題。

4.變更引起治理

灰度升級+流程管控+監(jiān)控告警，通過灰度升級避免正式客戶由于系統(tǒng)升級異常而造成的全局故障，通過流程管控將人為變更的風(fēng)險降到最低，通過監(jiān)控告警快速發(fā)現(xiàn)變更后的故障。

FunctionGraph 系統(tǒng)設(shè)計實(shí)踐

為了解決表 1 出現(xiàn)的問題，F(xiàn)unctionGraph 在架構(gòu)容災(zāi)、流控、重試、緩存、灰度升級、監(jiān)控告警、管理流程上等多方面做了優(yōu)化，可用性大幅提升。下面主要介紹一些 FunctionGraph 面向異常的設(shè)計實(shí)踐，在彈性能力、系統(tǒng)功能等暫不展開。

容災(zāi)架構(gòu)

實(shí)現(xiàn)華為云容災(zāi) 1.1 架構(gòu)（例：服務(wù) AZ 級故障域、集群跨 AZ 自愈能力、AZ 級服務(wù)依賴隔離），F(xiàn)unctionGraph 管理面和數(shù)據(jù)面集群部署多套，每套集群 AZ 隔離，實(shí)現(xiàn)同 region 內(nèi)的 AZ 容災(zāi)。如圖 2 所示，F(xiàn)unctionGraph 部署多套數(shù)據(jù)面集群（承擔(dān) FunctionGraph 函數(shù)運(yùn)行業(yè)務(wù)）和 dispatcher 調(diào)度集群（承擔(dān) FunctionGraph 的流量集群調(diào)度任務(wù)），用來提升系容量以及容災(zāi)。當(dāng)前其中某個元戎集群異常時，dispatcher 調(diào)度組件能及時摘除故障集群，并將流量分發(fā)至其他幾個集群。

圖 2 FunctionGraph 簡略架構(gòu)圖

分布式無中心化架構(gòu)設(shè)計，支持靈活的橫向擴(kuò)縮容

這個策略是邏輯多租服務(wù)設(shè)計的關(guān)鍵，需要解決無中心化后，組件擴(kuò)縮容后的重均衡問題。

1.靜態(tài)數(shù)據(jù)管理的無中心化

邏輯多租服務(wù)的元數(shù)據(jù)，初期由于量少，可以全部存儲到同一套中間件中。隨著客戶上量，需要設(shè)計數(shù)據(jù)的拆分方案，支持?jǐn)?shù)據(jù)的分片，應(yīng)對后續(xù)海量數(shù)據(jù)讀寫，以及可靠性壓力。

2.流量調(diào)度功能的無中心化

組件功能設(shè)計，支持無中心化（常見中心化依賴：鎖、流控值、調(diào)度任務(wù)等），流量上量后，可擴(kuò)展組件副本數(shù)量，組件通過自均衡策略，完成流量的重新負(fù)載。

多維度的流控策略

FunctionGraph 上的客戶函數(shù)流量最終達(dá)到 runtime 運(yùn)行時之前，會經(jīng)過多個鏈路，每個鏈路都有可能出現(xiàn)超過其承載閾值的流量。因此，為了確保各個鏈路的穩(wěn)定性，F(xiàn)unctionGraph 在每條鏈路上，防御性的追加了不同的流控策略。基本原則解決計算(cpu)、存儲（磁盤、磁盤 I/0）、網(wǎng)絡(luò)（http 連接、帶寬）上的函數(shù)粒度的資源隔離。

函數(shù)流量從客戶側(cè)觸發(fā)，最終運(yùn)行起來的鏈路流控如圖 3 所示。

圖 3 FunctionGraph 流控

1.網(wǎng)關(guān) APIG 流控

APIG 是 FunctionGraph 的流量入口，支持 Region 級別總的流量控制，可以根據(jù) region 的業(yè)務(wù)繁忙程度進(jìn)行彈性擴(kuò)容。同時 APIG 支持客戶級別的流量控制，當(dāng)檢測到客戶流量異常時，可以快速通過 APIG 側(cè)限制客戶流量，減少個別客戶對系統(tǒng)穩(wěn)定性的影響。

2.系統(tǒng)業(yè)務(wù)流控

針對 api 級別的流控

客戶流量通過 APIG 后，走到 FunctionGraph 的系統(tǒng)側(cè)?；?APIG 流控失效的場景，F(xiàn)unctionGraph 構(gòu)建了自身的流控策略。當(dāng)前支持節(jié)點(diǎn)級別流控、客戶 api 總流控、函數(shù)級別流控。當(dāng)客戶流量超過 FunctionGraph 的承載能力時，系統(tǒng)直接拒絕，并返回 429 給客戶。

系統(tǒng)資源流控

FunctionGraph 是邏輯多租服務(wù)，控制面和數(shù)據(jù)面的資源是客戶共享的，當(dāng)非法客戶惡意攻擊時，會造成系統(tǒng)不穩(wěn)定。FunctionGraph 針對共享資源實(shí)現(xiàn)基于請求并發(fā)數(shù)的客戶流控，嚴(yán)格限制客戶可用的資源。另外對共享資源的資源池化來保證共享資源的總量可控制，進(jìn)而保證系統(tǒng)的可用性。例如：http 連接池、內(nèi)存池、協(xié)程池。

并發(fā)數(shù)控制

構(gòu)建基于請求并發(fā)數(shù)的 FunctionGraph 函數(shù)粒度的流控策略，F(xiàn)unctionGraph 的客戶函數(shù)執(zhí)行時間有毫秒、秒、分鐘、小時等多種類型，常規(guī)的 QPS 每秒請求數(shù)的流控策略在處理超長執(zhí)行的請求時有先天不足，無法限制同一時刻客戶占用的系統(tǒng)共享資源?；诓l(fā)數(shù)的控制策略，嚴(yán)格限制了同一時刻的請求量，超過并發(fā)數(shù)直接拒絕，保護(hù)系統(tǒng)共享資源。

http 連接池

構(gòu)建高并發(fā)的服務(wù)時，合理的維護(hù) http 的長連接數(shù)量，能最大限度減少 http 連接的資源開銷時間，同時保證 http 連接數(shù)資源的可控，確保系統(tǒng)安全性的同時提升系統(tǒng)性能。業(yè)界可以參考 http2 的連接復(fù)用，以及 fasthttp 內(nèi)部的連接池實(shí)現(xiàn)，其原理都是盡量減少 http 的數(shù)量，復(fù)用已有的資源。

內(nèi)存池

客戶的請求和響應(yīng)報文特別大，同時并發(fā)特別高的場景下，單位時間占用系統(tǒng)的內(nèi)存較大，當(dāng)超過閾值后，會輕松造成系統(tǒng)內(nèi)存溢出，導(dǎo)致系統(tǒng)重啟?；诖藞鼍埃現(xiàn)unctionGraph 新增了內(nèi)存池的統(tǒng)一控制，在請求入口和響應(yīng)出口，校驗客戶請求報文是否超過閾值，保護(hù)系統(tǒng)內(nèi)存可控。

協(xié)程池

FunctionGraph 構(gòu)建于云原生平臺上，采用的 go 語言。如果每一個請求都使用一個協(xié)程來進(jìn)行日志和指標(biāo)的處理，大并發(fā)請求來臨時，導(dǎo)致有海量的協(xié)程在并發(fā)執(zhí)行，造成系統(tǒng)的整體性能大幅下降。FunctionGraph 引入 go 的協(xié)程池，通過將日志和指標(biāo)的處理任務(wù)改造成一個個的 job 任務(wù)，提交到協(xié)程池中，然協(xié)程池統(tǒng)一處理，大幅緩解了協(xié)程爆炸的問題。

異步消費(fèi)速率控制

異步函數(shù)調(diào)用時，會優(yōu)先放到 FunctionGraph 的 kafka 中，通過合理設(shè)置客戶的 kafka 消費(fèi)速率，確保函數(shù)實(shí)例始終夠用，同時防止過量的函數(shù)調(diào)用，導(dǎo)致底層資源被迅速耗光。

3.函數(shù)實(shí)例控制

客戶實(shí)例配額

通過限制客戶總配額，防止惡意客戶將底層資源耗光，來保障系統(tǒng)的穩(wěn)定性。當(dāng)客戶業(yè)務(wù)確實(shí)有需要，可以通過申請工單的方式快速擴(kuò)充客戶配額。

函數(shù)實(shí)例配額

通過限制函數(shù)配額，防止單個客戶的函數(shù)將客戶的實(shí)例耗光，同時也能防止客戶配額失效，短時間內(nèi)造成大量的資源消耗。另外，客戶業(yè)務(wù)如果涉及數(shù)據(jù)庫、redis 等中間件的使用，通過函數(shù)實(shí)例配額限制，可以保護(hù)客戶的中間件連接數(shù)在可控范圍內(nèi)。

4.高效的資源彈性能力

流控屬于防御式設(shè)計思想，通過提前封堵的方式減少系統(tǒng)過載的風(fēng)險?？蛻粽I(yè)務(wù)突發(fā)上量需要大量的資源時，首先應(yīng)該解決的是資源彈性問題，保證客戶業(yè)務(wù)成功的前提下，通過流控策略兜底系統(tǒng)出現(xiàn)異常，防止爆炸面擴(kuò)散。FunctionGraph 支持集群節(jié)點(diǎn)快速彈性、支持客戶函數(shù)實(shí)例快速彈性、支持客戶函數(shù)實(shí)例的智能預(yù)測彈性等多種彈性能力，保證客戶業(yè)務(wù)突增時依然能正常使用 FunctionGraph。

重試策略

FunctionGraph 通過設(shè)計恰當(dāng)好處的重試策略，使系統(tǒng)在發(fā)生異常的時候，也可以保障客戶的請求最終執(zhí)行成功。如圖 4 所示，重試的策略一定要有終止條件，否則會造成重試風(fēng)暴，更輕松的擊穿系統(tǒng)的承載上限。

圖 4 重試策略

1.函數(shù)請求失敗重試

同步請求

當(dāng)客戶請求執(zhí)行時，遇到系統(tǒng)錯誤時，F(xiàn)unctionGraph 會將請求轉(zhuǎn)發(fā)至其他集群，最多重試 3 次，確?？蛻舻恼埱?，在遇到偶現(xiàn)的集群異常，也可以在其他集群執(zhí)行成功。

異步請求

由于異步函數(shù)對實(shí)時性要求不高，客戶函數(shù)執(zhí)行失敗后，系統(tǒng)可以針對失敗請求做更為精細(xì)的重試策略。當(dāng)前 FunctionGraph 支持二進(jìn)制指數(shù)退避的重試，當(dāng)函數(shù)由于系統(tǒng)錯誤異常終止后，函數(shù)會按 2,4,8,16 指數(shù)退避的方法，當(dāng)間隔退避到 20 分鐘時，后續(xù)重試均按照 20 分的間隔進(jìn)行，函數(shù)請求重試時間最大支持 6 小時，當(dāng)超過后，會按失敗請求處理，返回給客戶。通過二進(jìn)制指數(shù)退避的方式，可以最大程度保障客戶業(yè)務(wù)的穩(wěn)定性。

2.依賴服務(wù)間的重試

中間件的重試機(jī)制

以 redis 為例，當(dāng)系統(tǒng)讀寫 redis 偶現(xiàn)失敗時，會 sleep 一段時間，再重復(fù)執(zhí)行 redis 的讀寫操作，最大重試次數(shù) 3 次。

http 請求重試機(jī)制

當(dāng) http 請求由于網(wǎng)絡(luò)波動，發(fā)生 eof、io timeout 之類的錯誤時，會 sleep 一段時間，在重復(fù) http 的發(fā)送操作，最大重試次數(shù) 3 次。

緩存

緩存不僅可以加速數(shù)據(jù)的訪問，而且當(dāng)依賴的服務(wù)故障時，仍然可以使用緩存數(shù)據(jù)，保障系統(tǒng)的可用性。從功能類別劃分，F(xiàn)unctionGraph 需要進(jìn)行緩存的組件有兩類，1 是中間件，2 是依賴的云服務(wù)，系統(tǒng)優(yōu)先訪問緩存數(shù)據(jù)，同時定期從中間件和依賴的云服務(wù)刷新本地緩存數(shù)據(jù)。方式如圖 5 所示。

1.緩存中間件數(shù)據(jù)

FunctionGraph 通過發(fā)布訂閱的方式，監(jiān)聽中間件數(shù)據(jù)的變化及時更新到本地緩存，當(dāng)中間件異常時，本地緩存可以繼續(xù)使用，維持系統(tǒng)的穩(wěn)定性。

2.緩存關(guān)鍵依賴服務(wù)數(shù)據(jù)

以華為云的身份認(rèn)證服務(wù) IAM 為例，F(xiàn)unctionGraph 會強(qiáng)依賴 IAM，當(dāng)客戶發(fā)起首次請求，系統(tǒng)會將 token 緩存到本地，過期時間 24 小時，當(dāng) IAM 掛掉后，不影響老的請求。FunctionGraph 系統(tǒng)的使用。其他關(guān)鍵的云服務(wù)依賴做法一直，都是把關(guān)鍵的數(shù)據(jù)臨時緩存到本地內(nèi)存。

圖 5 FunctionGraph 的緩存措施

熔斷

上面的種種措施，可以保障客戶業(yè)務(wù)平穩(wěn)運(yùn)行，但當(dāng)客戶業(yè)務(wù)出現(xiàn)異常一直無法恢復(fù)或者有惡意客戶持續(xù)攻擊 FunctionGraph 平臺，系統(tǒng)資源會一直浪費(fèi)在異常流量上，擠占正常客戶的資源，同時系統(tǒng)可能會在持續(xù)高負(fù)荷運(yùn)行異常流量后出現(xiàn)不可預(yù)期的錯誤。針對這種場景，F(xiàn)unctionGraph 基于函數(shù)調(diào)用量模型構(gòu)建了自身的斷路器策略。具體如圖 6 所示，根據(jù)調(diào)用量的失敗率進(jìn)行多級熔斷，保證客戶業(yè)務(wù)的平滑以及系統(tǒng)的穩(wěn)定。

圖 6 熔斷策略模型

隔離

1.異步函數(shù)業(yè)務(wù)隔離

按照異步請求的類別，F(xiàn)unctionGraph 將 Kafka 的消費(fèi)組劃分為定時觸發(fā)器消費(fèi)組、專享消費(fèi)組、通用消費(fèi)組、異步消息重試消費(fèi)組，topic 同理也劃分為對等類別。通過細(xì)分 consumer 消費(fèi)組和 topic，定時觸發(fā)器業(yè)務(wù)和大流量業(yè)務(wù)隔離，正常業(yè)務(wù)和重試請求業(yè)務(wù)隔離，客戶的業(yè)務(wù)請求得到最高優(yōu)先級的保障。

2.安全容器隔離

傳統(tǒng) cce 容器基于 cgroup 進(jìn)行隔離，當(dāng)客戶增多，客戶調(diào)用量變大時，會偶現(xiàn)客戶間的互相干擾。通過安全容器可以做到虛擬機(jī)級別的隔離，客戶業(yè)務(wù)互不干擾。

灰度升級

邏輯多租服務(wù)，一旦升級出問題，造成的影響不可控。FunctionGraph 支持按 ring 環(huán)升級（根據(jù) region 上業(yè)務(wù)的風(fēng)險度進(jìn)行劃分）、藍(lán)綠發(fā)布、金絲雀發(fā)布策略，升級動作簡要描述成三個步驟：

1.升級前集群的流量隔離

當(dāng)前 FunctionGraph 升級時，優(yōu)先將升級集群的流量隔離，確保新流量不在進(jìn)入升級集群；

2.升級前集群的流量遷移、優(yōu)雅退出

將流量遷移到其他集群，同時升級集群的請求徹底優(yōu)雅退出后，執(zhí)行升級操作；

3.升級后的集群支持流量按客戶遷入

升級完成后，將撥測客戶的流量轉(zhuǎn)發(fā)到升級集群，待撥測用例全部執(zhí)行成功后，在將正式客戶的流量遷進(jìn)來。

監(jiān)控告警

當(dāng) FunctionGraph 出現(xiàn)系統(tǒng)無法兜住的錯誤后，我們給出的解決措施就是構(gòu)建監(jiān)控告警能力，快速發(fā)現(xiàn)異常點(diǎn)，在分鐘級別恢復(fù)故障，最大程度減少系統(tǒng)的中斷時間。作為系統(tǒng)高可用的最后一道防線，快速發(fā)現(xiàn)問題的能力至關(guān)重要，F(xiàn)unctionGraph 圍繞著業(yè)務(wù)關(guān)鍵路徑，構(gòu)建了多個告警點(diǎn)。如表 2 所示。

表 2 FunctionGraph 構(gòu)建的監(jiān)控告警

流程規(guī)范

上面的一些措施從技術(shù)設(shè)計層面解決系統(tǒng)可用性的問題，F(xiàn)unctionGraph 從流程上也形成了一套規(guī)章制度，當(dāng)技術(shù)短期無法解決問題后，可以通過人為介入快速消除風(fēng)險。具體有如下團(tuán)隊運(yùn)作規(guī)范：

1.內(nèi)部 war room 流程

遇到現(xiàn)網(wǎng)緊急問題，團(tuán)隊內(nèi)部快速組織起關(guān)鍵角色，第一時間恢復(fù)現(xiàn)網(wǎng)故障；

2.內(nèi)部變更評審流程

系統(tǒng)版本在測試環(huán)境浸泡驗證沒問題后，在正式變更現(xiàn)網(wǎng)前，需要編寫變更指導(dǎo)書，識別變更功能點(diǎn)和風(fēng)險點(diǎn)，經(jīng)團(tuán)隊關(guān)鍵角色評估后，才準(zhǔn)許上現(xiàn)網(wǎng)，通過標(biāo)準(zhǔn)的流程管理減少人為變更導(dǎo)致異常；

3.定期現(xiàn)網(wǎng)問題分析復(fù)盤

例行每周現(xiàn)網(wǎng)風(fēng)險評估、告警分析復(fù)盤，通過問題看系統(tǒng)設(shè)計的不足之處，舉一反三，優(yōu)化系統(tǒng)。

客戶端容災(zāi)

業(yè)界最先進(jìn)的云服務(wù)，對外也無法承諾 100%的 SLA。所以，當(dāng)系統(tǒng)自身甚至人力介入都無法在急短時間內(nèi)快速恢復(fù)系統(tǒng)狀態(tài)，這時候和客戶共同設(shè)計的容災(zāi)方案就顯得至關(guān)重要。一般，F(xiàn)unctionGraph 會和客戶一同設(shè)計客戶端的容災(zāi)方案，當(dāng)系統(tǒng)持續(xù)出現(xiàn)異常，客戶端需要針對返回進(jìn)行重試，當(dāng)失敗次數(shù)達(dá)到一定程度，需要考慮在客戶端側(cè)觸發(fā)熔斷，限制對下游系統(tǒng)的訪問，同時及時切換到逃生方案。

總結(jié)

FunctionGraph 在做高可用設(shè)計時，整體遵循如下原則“冗余+故障轉(zhuǎn)移”，在滿足業(yè)務(wù)基本需求的情況下，保證系統(tǒng)穩(wěn)定后在逐步完善架構(gòu)。

“冗余+故障轉(zhuǎn)移”包括以下能力：

容災(zāi)架構(gòu)：多集群模式、主備模式

過載保護(hù)：流控、異步削峰、資源池化

故障治理：重試、緩存、隔離、降級、熔斷

灰度發(fā)布：灰度切流、優(yōu)雅退出

客戶端容災(zāi)：重試、熔斷、逃生

未來，F(xiàn)unctionGraph 會持續(xù)從系統(tǒng)設(shè)計、監(jiān)控、流程幾個維度持續(xù)構(gòu)建更高可用的服務(wù)。如圖 7 所示，通過構(gòu)建監(jiān)測能力快速發(fā)現(xiàn)問題，通過可靠性設(shè)計快速解決問題，通過流程規(guī)范來減少問題，持續(xù)提升系統(tǒng)的可用性能力，為客戶提供 SLA 更高的服務(wù)。

圖 7 FunctionGraph 高可用迭代實(shí)踐

參考文獻(xiàn)

[1]高可用定義：

https://zh.wikipedia.org/zh-hans/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7

[2]SLA 定義：

https://zh.wikipedia.org/zh-hans/%E6%9C%8D%E5%8A%A1%E7%BA%A7%E5%88%AB%E5%8D%8F%E8%AE%AE

審核編輯 黃宇