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

高可用介紹

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

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

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

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

高可用挑戰(zhàn)

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

圖 1 FunctionGraph 的周邊交互

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

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

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

1.流量突變治理

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

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

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

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

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

4.變更引起治理

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

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

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

容災架構(gòu)

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

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

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

這個策略是邏輯多租服務設計的關鍵，需要解決無中心化后，組件擴縮容后的重均衡問題。

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

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

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

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

多維度的流控策略

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

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

圖 3 FunctionGraph 流控

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

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

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

針對 api 級別的流控

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

系統(tǒng)資源流控

FunctionGraph 是邏輯多租服務，控制面和數(shù)據(jù)面的資源是客戶共享的，當非法客戶惡意攻擊時，會造成系統(tǒng)不穩(wěn)定。FunctionGraph 針對共享資源實現(xiàn)基于請求并發(fā)數(shù)的客戶流控，嚴格限制客戶可用的資源。另外對共享資源的資源池化來保證共享資源的總量可控制，進而保證系統(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ù)的控制策略，嚴格限制了同一時刻的請求量，超過并發(fā)數(shù)直接拒絕，保護系統(tǒng)共享資源。

http 連接池

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

內(nèi)存池

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

協(xié)程池

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

異步消費速率控制

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

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

客戶實例配額

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

函數(shù)實例配額

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

4.高效的資源彈性能力

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

重試策略

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

圖 4 重試策略

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

同步請求

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

異步請求

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

2.依賴服務間的重試

中間件的重試機制

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

http 請求重試機制

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

緩存

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

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

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

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

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

圖 5 FunctionGraph 的緩存措施

熔斷

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

圖 6 熔斷策略模型

隔離

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

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

2.安全容器隔離

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

灰度升級

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

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

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

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

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

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

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

監(jiān)控告警

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

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

流程規(guī)范

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

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

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

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

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

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

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

客戶端容災

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

總結(jié)

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

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

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

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

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

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

客戶端容災：重試、熔斷、逃生

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

圖 7 FunctionGraph 高可用迭代實踐

參考文獻

[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

審核編輯 黃宇