新作！分散式系統韌性架構壓艙石OpenChaos
摘要：本文首先以現今分散式系統的複雜性和穩定性的需求引出混沌工程概念，並闡述了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活動：//summer-ospp.ac.cn/#/org/prodetail/221bf0008
