華為云 FunctionGraph 構建高可用系統的實踐

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

高可用介紹

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

業界一般使用 SLA 指標來衡量系統的可用性。

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

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

高可用挑戰

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

圖 1 FunctionGraph 的周邊交互

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

表 1 FunctionGraph 常見問題總結

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

1.流量突變治理

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

2.系統服務異常治理

容災架構+重試+隔離+監控告警，通過容災架構避免系統整個宕機，通過重試來減少系統異常對客戶業務的影響，通過隔離快速剝離系統異常點，防止故障擴散，通過監控告警快速發現系統服務異常問題。

3.系統依賴服務異常治理

容災架構+緩存降級+監控告警，通過容災架構減少依賴服務單點故障，通過緩存降級確保依賴服務故障后系統仍能正常運行，通過監控告警快速發現依賴服務異常問題。

4.變更引起治理

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

FunctionGraph 系統設計實踐

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

容災架構

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

圖 2 FunctionGraph 簡略架構圖

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

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

1.靜態數據管理的無中心化

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

2.流量調度功能的無中心化

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

多維度的流控策略

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

函數流量從客戶側觸發，最終運行起來的鏈路流控如圖 3 所示。

圖 3 FunctionGraph 流控

1.網關 APIG 流控

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

2.系統業務流控

針對 api 級別的流控

客戶流量通過 APIG 后，走到 FunctionGraph 的系統側?；?APIG 流控失效的場景，FunctionGraph 構建了自身的流控策略。當前支持節點級別流控、客戶 api 總流控、函數級別流控。當客戶流量超過 FunctionGraph 的承載能力時，系統直接拒絕，并返回 429 給客戶。

系統資源流控

FunctionGraph 是邏輯多租服務，控制面和數據面的資源是客戶共享的，當非法客戶惡意攻擊時，會造成系統不穩定。FunctionGraph 針對共享資源實現基于請求并發數的客戶流控，嚴格限制客戶可用的資源。另外對共享資源的資源池化來保證共享資源的總量可控制，進而保證系統的可用性。例如：http 連接池、內存池、協程池。

并發數控制

構建基于請求并發數的 FunctionGraph 函數粒度的流控策略，FunctionGraph 的客戶函數執行時間有毫秒、秒、分鐘、小時等多種類型，常規的 QPS 每秒請求數的流控策略在處理超長執行的請求時有先天不足，無法限制同一時刻客戶占用的系統共享資源?；诓l數的控制策略，嚴格限制了同一時刻的請求量，超過并發數直接拒絕，保護系統共享資源。

http 連接池

構建高并發的服務時，合理的維護 http 的長連接數量，能最大限度減少 http 連接的資源開銷時間，同時保證 http 連接數資源的可控，確保系統安全性的同時提升系統性能。業界可以參考 http2 的連接復用，以及 fasthttp 內部的連接池實現，其原理都是盡量減少 http 的數量，復用已有的資源。

內存池

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

協程池

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

異步消費速率控制

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

3.函數實例控制

客戶實例配額

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

函數實例配額

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

4.高效的資源彈性能力

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

重試策略

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

圖 4 重試策略

1.函數請求失敗重試

同步請求

當客戶請求執行時，遇到系統錯誤時，FunctionGraph 會將請求轉發至其他集群，最多重試 3 次，確?？蛻舻恼埱?，在遇到偶現的集群異常，也可以在其他集群執行成功。

異步請求

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

2.依賴服務間的重試

中間件的重試機制

以 redis 為例，當系統讀寫 redis 偶現失敗時，會 sleep 一段時間，再重復執行 redis 的讀寫操作，最大重試次數 3 次。

http 請求重試機制

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

緩存

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

1.緩存中間件數據

FunctionGraph 通過發布訂閱的方式，監聽中間件數據的變化及時更新到本地緩存，當中間件異常時，本地緩存可以繼續使用，維持系統的穩定性。

2.緩存關鍵依賴服務數據

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

圖 5 FunctionGraph 的緩存措施

熔斷

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

圖 6 熔斷策略模型

隔離

1.異步函數業務隔離

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

2.安全容器隔離

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

灰度升級

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

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

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

2.升級前集群的流量遷移、優雅退出

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

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

升級完成后，將撥測客戶的流量轉發到升級集群，待撥測用例全部執行成功后，在將正式客戶的流量遷進來。

監控告警

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

表 2 FunctionGraph 構建的監控告警

流程規范

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

1.內部 war room 流程

遇到現網緊急問題，團隊內部快速組織起關鍵角色，第一時間恢復現網故障；

2.內部變更評審流程

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

3.定期現網問題分析復盤

例行每周現網風險評估、告警分析復盤，通過問題看系統設計的不足之處，舉一反三，優化系統。

客戶端容災

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

總結

FunctionGraph 在做高可用設計時，整體遵循如下原則“冗余+故障轉移”，在滿足業務基本需求的情況下，保證系統穩定后在逐步完善架構。

“冗余+故障轉移”包括以下能力：

容災架構：多集群模式、主備模式

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

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

灰度發布：灰度切流、優雅退出

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

未來，FunctionGraph 會持續從系統設計、監控、流程幾個維度持續構建更高可用的服務。如圖 7 所示，通過構建監測能力快速發現問題，通過可靠性設計快速解決問題，通過流程規范來減少問題，持續提升系統的可用性能力，為客戶提供 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

審核編輯 黃宇