深度解讀：分布式系統韌性架構壓艙石OpenChaos

作者 | 思瑩，嘉浩，馬海

Key Takeaways

1. 本文首先以現今分布式系統的複雜性和穩定性的需求引出混沌工程概念，并闡述了 OpenChaos 在傳統混沌工程之上所做的優化與創新。

2. 第二部分介紹了 OpenChaos 的架構，詳細講解了它的可靠性模型和彈性模型的工作原理，并以兩個實戰案例展示了 OpenChaos 在實際應用場景中可以發揮的效果。

3. 最後一部分展望未來，提出了 OpenChaos 後續的發展方向。

背 景

随着 Serverless、微服務（含服務網格）與越來越多的容器化架構應用的出現，我們建構、傳遞與運維系統的方式變得越發複雜。這種複雜性增加了系統狀态可觀測性的難度。在已有的生産環境中，我們有不同的方式來擷取資訊，增強系統的可觀測性。最初可能是非常簡單地給定一個特定的條件，産生一個特定的名額輸出。進一步的，使用結構化和關聯日志，或進行分布式跟蹤，引入事件總線如 Apache EventMesh、EventGrid 等。随着 Codeless 組合式應用快速發展，Serverless 設計理念也被一些分布式系統設計者逐漸接受。免運維、按需付費、極緻彈性、多租共池等等無不在逼迫我們重新審視老式架構的合理性，催生新架構的不斷演進。融合架構是這幾年被提得最多的一個詞，以往支撐線上 / 離線系統的複雜架構不斷被融合，通過可分可合的設計與部署方式去适配各種業務場景。在這樣的背景下，我們開始認真審視并思考，是否有一種更為現代化的工具，能夠幫助發現并應對分布式雲這種底座對架構設計以及上層應用帶來的諸如可靠、安全、彈性等一系列韌性架構的挑戰。

混沌工程思想給我們帶來了一定程度的啟發。Netflix 最初為了搬遷基礎設施上雲建立了 Chaos Monkey，由此拉開了混沌工程學的序幕。再到後來，CNCF 成立了專門的興趣小組，希望能夠推動這一領域的标準誕生。OpenChaos 創始團隊早期也和這些社群的先行者進行過多輪交流。可惜的是，2019 年該興趣組并入 App Delivery SIG 後再無太大動靜。這幾年國家政策大力引導下，企業的數字化更新不斷加快，越來越多的 CIO、CTO 甚至包括 CEO 開始重視并投入到混沌工程實踐中。國内由中國信通院牽頭的混沌工程實驗室也在積極推動該領域标準的制定，從全鍊路壓測、混沌故障引入到催生未來架構變革的多雲多活參考架構，這些無不昭示着這一産業在飛速發展。根據國内外科技媒體調研統計，到 2025 年，80% 的組織将實施混沌工程實踐。通過全鍊路壓測、混沌故障，以及多雲多活架構等政策的整體導入，可以将意外停機時間減少 50%，實作真正意義上的秒級 RTO/RPO，讓應用、業務創新更加專注。

良藥雖好，但也有局限

混沌工程的最基本流程是在生産環境小規模定期自動化執行試驗，為系統随機注入故障，來觀察 “系統邊界”。它主要關注系統面對故障所展現出的容錯能力和可靠性。目前市面上絕大部分混沌工程工具，傾向于構造以黑盒随機為主的故障類型，對底層基礎設施（硬體、作業系統、資料庫與中間件）了解與洞察較少。缺少統一的架構标準、成熟的 specific 度量名額。同時，分析回報較弱，無法給出全面徹底的診斷建議，尤其通過強化學習，生成式 AI 等能力可以進一步解決目前随機故障注入，進行自愈風險分析與優化建議。

面向有更多複雜特性的分布式系統，僅通過觀察系統應對故障的表現是有局限的，并且依賴于觀察是極其主觀的，很難形成統一的評測标準，也較難針對表現分析系統缺陷。系統的可觀測性，不僅需要模型的全面覆寫，還需要完備的監測系統，并提供全面的結果報告，甚至智能預測，來指導架構提升自身的韌性能力。分布式領域資深技術專家、開源頂級項目 Apache RocketMQ、OpenMessaging 最初的創始人馮嘉曾表示“雲原生分布式架構的演進正在朝着組裝式架構、韌性架構進一步發展”。在這樣的背景下，他提出并帶領團隊創造了 OpenChaos 這一新興項目。

OpenChaos 需要解決的本質問題

韌性架構，覆寫高靠性、安全、彈性、不可變基礎設施等特性。實作真正的韌性架構毫無疑問是現代分布式系統的演進方向。針對分布式系統韌性能力，OpenChaos 借助混沌工程思想，對其定義進行延伸擴充。針對一些分布式系統特有屬性，如 Pub/Sub 系統的投遞語義與推送效率，排程編排系統的精準排程、彈性伸縮與冷啟效率，streaming 系統的流批實時性、反壓效率，檢索系統的查全率與查準率，分布式系統共識元件的一緻性等，設定專用的檢測模型。OpenChaos 内置可擴充的模型支援，以便驗證在大規模資料請求以及各種故障沖擊下的韌性表現，并為架構演進提供進一步優化建議。

架構與案例解析

圖 1

整體架構

OpenChaos 的工作原理是這樣的：控制面對整個流程進行控制，負責使叢集節點組成一個待測試的分布式叢集，并會根據需要測試的分布式基礎設施找到對應的 Driver 元件并載入，根據設定的并發數建立相應個數的用戶端。控制節點根據 Model 元件定義的執行流程控制用戶端對叢集進行操作。演練過程中，Detection Model 會對叢集節點根據不同的觀測特性引入對應的事件。Metrics 子產品會在實驗中監測被測叢集的表現。演練結束後，Checker 元件會對實驗中的業務和非業務資料進行自動化分析，得出測試結果并輸出可視化圖表。

如圖 1 所示，OpenChaos 的整體架構可以分為管理層、執行層與被測元件層。

最上層為管理層，它包含了使用者界面和控制器（Control），控制器負責排程引擎層的元件進行工作。最下層為被測元件，它可以是自部署的分布式系統叢集，也可以是容器或者雲廠商承載的分布式系統。

中間層是執行層，也是 OpenChaos 強大能力的秘密所在。模型（Model）是執行的流程的基本單元，它定義了對分布式系統進行操作的基本形式。控制器在模型中載入需要測試的分布式系統的驅動（Driver），并根據配置的并發數建立相應的用戶端（Client），最終使用用戶端對分布式系統執行操作。檢測模型（Detection Model）會根據使用者關注的不同觀測特性引入對應的事件，比如引入故障或者系統的擴縮容。Metrics 子產品會在實驗中監測被測叢集的表現。演練結束後，度量模型（Measurement Model）元件會對實驗中的業務和非業務資料進行自動化分析，得出測試結果并輸出可視化圖表。

檢測模型與度量模型

檢測模型

傳統混沌工程主要關注系統的穩定性，它們的普遍實作是通過黑盒的故障注入來模拟一些常見的通用故障。OpenChaos 中的檢測模型關注更高次元的屬性——韌性，它包含可靠性，還包含如彈性、安全性等特性的檢測模型。相較于傳統混沌工程，OpenChaos 不僅支援普遍的黑盒故障注入，還可惡意針對分布式基礎軟體如消息或緩存等的主備倒換，網絡分區導緻的腦裂等問題做定制檢測，以觀察他們在這種情況下的表現。

度量模型

由于分布式系統的複雜性，對于分布式系統韌性的觀測更需要一個簡單直覺的分析報告，來讓人更友善地發現分布式系統可能存在的缺陷和不足。度量模型會對系統的表現進行分析，以統一的标準化計算輸出結果與圖表，友善使用者進行對比分析。

以消息系統的穩定性評估為例，度量模型會根據實驗中故障注入情況與系統表現，計算出系統的 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）。輸出叢集的處理語義情況，如是否符合 at least once 或 exactly once；故障恢複情況，故障期間是否出現系統不可用，及不可用的恢複時間；故障下是否滿足預期的分區順序性；系統在整個實驗過程中的響應時間等。

可靠性案例分析

我們使用 OpenChaos 對 ETCD 叢集進行可靠性測試，發現在主節點網絡斷開、單獨成為一個分區的場景下，ETCD 用戶端視角下，叢集缺乏自動恢複能力。

圖 2

下面是利用 OpenChaos 執行的一個實驗結果示例，是一個 3 節點 ETCD 叢集在主節點與從節點網絡斷開，單獨成為一個分區時的表現，模拟的業務流量速率為 1000 tps。

圖 3

從圖中可以看出實驗持續 10 分鐘，共注入十次主節點網絡分區故障，間隔為 30 秒，故障期間叢集表現不一緻。下圖為更詳細的實驗結果。

在第 1/3/6/8 次故障期間，叢集無法自行恢複；其他故障期間花費 7 秒會恢複叢集為可用狀态，但整個實驗中沒有出現資料丢失。

圖 4

通過檢視實驗過程資訊，發現每次主節點被分區時，叢集均可在故障期間自行轉移主節點。通過分析源碼 ，ETCD 用戶端在面對 ETCD 内部錯誤時，不會進行重試連接配接其他節點。導緻在用戶端優先連接配接的節點為主節點，并發生不可用時，即便主節點已經成功轉移，整體叢集恢複為可用，業務仍處于未恢複狀态。該問題我們也已經 report 給 ETCD 社群，等待進一步修複。

彈性案例分析

彈性也是分布式系統需要重點關注的能力，除可靠性外，OpenChaos 支援對系統擴縮容能力的度量與評測。與可靠性不同，分布式系統的彈性能力不能通過編排固定頻率的事件以觸發檢測。OpenChaos 可以根據使用者設定的作業系統名額或業務名額門檻值來觸發擴縮容。例如，你可以指定叢集 CPU 平均占用的預期值為 40%，或系統響應的預期時間為 100ms。彈性檢測模型會根據指定的預期值與目前系統表現，根據 OpenChaos 内置的算法來計算出要彈到的目标規模，來觸發擴縮容動作。實驗結束後，度量模型會計算出叢集的“加速比效率”，與“擴縮代價”和對應規模下叢集的性能。

注：“加速比效率”和“擴縮代價”為 OpenChaos 中度量分布式系統彈性能力的名額，前者表示分布式系統并行化的性能和效果，後者表示系統伸縮的速率。

彈性的含義不僅包括執行個體節點的伸縮能力，同樣也包含具體業務（應用）單元的伸縮能力。為了探索 Kafka 分區的最佳使用實踐，我們設計了實驗以探索單個 topic 分區的擴容能力。在實驗中我們還會統計在不同分區個數下消息收發的吞吐量，以了解分區數量對消息吞吐量的影響和達到最大吞吐量的最優分區數數量。

圖 5 為三節點叢集上的一個 topic 的分區從 1 擴到 9000 時的 tps 和延遲情況。

圖 5

圖 6 為各名額随着實驗時間的變化情況。

圖 6

圖 7 是具體的彈性評測結果部分截圖，展示了在不同規模下，系統表現出的性能以及彈性變更的花銷與效率。其中 changeCost 和 resilienceEfficienty 為上文描述的擴縮代價與加速比效率結果。

圖 7

從上述結果能夠看出，此實驗規格下的 Kafka 叢集，新增 1 個分區的平均時間約 20ms。在分區數量達到 26 的時候性能達到最優，該情況下吞吐量達到 130 萬，此時 CPU 總體使用率達到 93%。在分區數達到 450+ 時，性能明顯下降。當分區數達到 1992 時，吞吐量降到 3.8 萬，CPU 總體使用率達到 97%。

未來規劃

目前 OpenChaos 已支援接入大多數分布式系統，如 Apache Kafka、Apache RocketMQ、DLedger、 Redis、ETCD 等。随着開源之夏 2022 活動[1]的召開，我們開放了更多分布式系統接入的工作，供廣大學生選擇與參與。

與此同時，華為雲與混沌工程實驗室緊密合作，助力中國信通院釋出了國内首個《分布式消息隊列穩定性評估标準》，是該項标準的主要貢獻者。另外，華為雲中間件消息産品家族是唯一一個全面通過驗收标準的應用服務。

面向未來，OpenChaos 将推出更多通用的韌性标準和智能預測功能，以期不僅能評測出架構已有的能力，還能夠基于系統的觀測做出預測，避免出現超出系統本身韌性能力的異常發生。百尺竿頭更進一步，我們會持續打磨該項目，通過生态合作方式內建更多分布式系統，努力将 OpenChaos 打造成分布式系統韌性架構的壓艙石，進而推動雲原生架構不斷演進，關鍵時候方能“任憑風浪起，穩坐釣魚船”。

[1]開源之夏 2022 活動：

https://summer-ospp.ac.cn/#/org/prodetail/221bf0008

作者簡介：

思瑩，資深研發工程師，對分布式系統一緻性算法，韌性架構，模式識别有深刻的了解與研究。

嘉浩，資深中間件研發工程師，負責華為雲分布式中間件設計與研發，擅長中間件性能優化，喜歡大道至簡的設計理念。

馬海，華為雲中間件可靠性技術專家，擅長混沌工程、性能測試，事件驅動架構設計。