每年，網上都會報道 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 在每條鏈路上，防御性的追加了不同的流控策略。基本原則解決計算(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 每秒請求數的流控策略在處理超長執行的請求時有先天不足，無法限制同一時刻客戶占用的系統共享資源。基于并發數的控制策略，嚴格限制了同一時刻的請求量，超過并發數直接拒絕，保護系統共享資源。

http 連接池

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

內存池

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

協程池

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

異步消費速率控制

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

3.函數實例控制

客戶實例配額

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

函數實例配額

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

4.高效的資源彈性能力

流控屬于防御式設計思想，通過提前封堵的方式減少系統過載的風險。客戶正常業務突發上量需要大量的資源時，首先應該解決的是資源彈性問題，保證客戶業務成功的前提下，通過流控策略兜底系統出現異常，防止爆炸面擴散。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 平臺，系統資源會一直浪費在異常流量上，擠占正常客戶的資源，同時系統可能會在持續高負荷運行異常流量后出現不可預期的錯誤。針對這種場景，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

審核編輯 黃宇