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

高可用介紹

高可用性[1]（英語：high availability，縮寫為 HA），IT 術(shù)語，指系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度。是進(jìn)行系統(tǒng)設(shè)計(jì)時的準(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è)計(jì)思想，通過過載保護(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è)計(jì)實(shí)踐

為了解決表 1 出現(xiàn)的問題，F(xiàn)unctionGraph 在架構(gòu)容災(zāi)、流控、重試、緩存、灰度升級、監(jiān)控告警、管理流程上等多方面做了優(yōu)化，可用性大幅提升。下面主要介紹一些 FunctionGraph 面向異常的設(shè)計(jì)實(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è)計(jì)，支持靈活的橫向擴(kuò)縮容

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

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

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

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

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

多維度的流控策略

FunctionGraph 上的客戶函數(shù)流量最終達(dá)到 runtime 運(yùn)行時之前，會經(jīng)過多個鏈路，每個鏈路都有可能出現(xiàn)超過其承載閾值的流量。因此，為了確保各個鏈路的穩(wěn)定性，F(xiàn)unctionGraph 在每條鏈路上，防御性的追加了不同的流控策略。基本原則解決計(jì)算(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)共享資源。基于并發(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)重啟。基于此場景，F(xiàn)unctionGraph 新增了內(nèi)存池的統(tǒng)一控制，在請求入口和響應(yīng)出口，校驗(yàn)客戶請求報文是否超過閾值，保護(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è)計(jì)思想，通過提前封堵的方式減少系統(tǒng)過載的風(fēng)險。客戶正常業(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è)計(jì)恰當(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è)計(jì)層面解決系統(tǒng)可用性的問題，F(xiàn)unctionGraph 從流程上也形成了一套規(guī)章制度，當(dāng)技術(shù)短期無法解決問題后，可以通過人為介入快速消除風(fēng)險。具體有如下團(tuán)隊(duì)運(yùn)作規(guī)范：

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

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

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

系統(tǒng)版本在測試環(huán)境浸泡驗(yàn)證沒問題后，在正式變更現(xiàn)網(wǎng)前，需要編寫變更指導(dǎo)書，識別變更功能點(diǎn)和風(fēng)險點(diǎn)，經(jīng)團(tuán)隊(duì)關(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è)計(jì)的不足之處，舉一反三，優(yōu)化系統(tǒng)。

客戶端容災(zāi)

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

總結(jié)

FunctionGraph 在做高可用設(shè)計(jì)時，整體遵循如下原則“冗余+故障轉(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è)計(jì)、監(jiān)控、流程幾個維度持續(xù)構(gòu)建更高可用的服務(wù)。如圖 7 所示，通過構(gòu)建監(jiān)測能力快速發(fā)現(xiàn)問題，通過可靠性設(shè)計(jì)快速解決問題，通過流程規(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

審核編輯 黃宇