好玩又實用，阿里巴巴開源混沌工程工具 ChaosBlade

減小故障的最好方法就是讓問題常常性的發生。在可控範圍或環境下，經過不斷重複失敗過程，持續提高系統的容錯和彈性能力。

那麼，實施一次高效的混沌工程實驗，須要幾步呢？

答案：2 步。

① 登錄 ChaosBlade

② 下載 release 版本，打造故障演練專屬工具

高可用架構是保障服務穩定性的核心。

阿里巴巴在海量互聯網服務以及歷年雙11場景的實踐過程當中，沉澱出了包括全鏈路壓測、線上流量管控、故障演練等高可用核心技術，並經過開源和雲上服務的形式對外輸出，以幫助企業用戶和開發者享受阿里巴巴的技術紅利，提升開發效率，縮短業務的構建流程。

例如，藉助阿里雲性能測試 PTS，高效率構建全鏈路壓測體系，經過開源組件 Sentinel 實現限流和降級功能。這一次，經歷了 6 年時間的改進和實踐，累計在線上執行演練場景達數萬次，咱們將阿里巴巴在故障演練領域的創意和實踐，濃縮成一個混沌工程工具，並將其開源，命名爲 ChaosBlade。

訪問項目及體驗 Demo，點擊這裏。

ChaosBlade 是什麼

ChaosBlade 是一款遵循混沌工程實驗原理，提供豐富故障場景實現，幫助分佈式系統提高容錯性和可恢復性的混沌工程工具，可實現底層故障的注入，特色是操做簡潔、無侵入、擴展性強。

ChaosBlade 基於 Apache License v2.0 開源協議，目前有 chaosblade 和 chaosblade-exe-jvm 兩個倉庫。

chaosblade 包含 CLI 和使用 Golang 實現的基礎資源、容器相關的混沌實驗實施執行模塊。chaosblade-exe-jvm 是對運行在 JVM 上的應用實施混沌實驗的執行器。

ChaosBlade 社區後續還會添加 C++、Node.js 等其餘語言的混沌實驗執行器。

爲何要開源

不少公司已經開始關注並探索混沌工程，漸漸成爲測試系統高可用，構建對系統信息不可缺乏的工具。但混沌工程領域目前還處於一個快速演進的階段，最佳實踐和工具框架沒有統一標準。實施混沌工程可能會帶來一些潛在的業務風險，經驗和工具的缺失也將進一步阻止 DevOps 人員實施混沌工程。

混沌工程領域目前也有不少優秀的開源工具，分別覆蓋某個領域，但這些工具的使用方式千差萬別，其中有些工具上手難度大，學習成本高，混沌實驗能力單一，使不少人對混沌工程領域望而卻步。

阿里巴巴集團在混沌工程領域已經實踐多年，將混沌實驗工具 ChaosBlade 開源目的，是爲了：

• 讓更多人瞭解並加入到混沌工程領域；
• 縮短構建混沌工程的路徑；
• 同時依靠社區的力量，完善更多的混沌實驗場景，共同推動混沌工程領域的發展。

ChaosBlade 能解決哪些問題

衡量微服務的容錯能力
經過模擬調用延遲、服務不可用、機器資源滿載等，查看發生故障的節點或實例是否被自動隔離、下線，流量調度是否正確，預案是否有效，同時觀察系統總體的 QPS 或 RT 是否受影響。在此基礎上能夠緩慢增長故障節點範圍，驗證上游服務限流降級、熔斷等是否有效。最終故障節點增長到請求服務超時，估算系統容錯紅線，衡量系統容錯能力。

驗證容器編排配置是否合理
經過模擬殺服務 Pod、殺節點、增大 Pod 資源負載，觀察系統服務可用性，驗證副本配置、資源限制配置以及 Pod 下部署的容器是否合理。

測試 PaaS 層是否健壯
經過模擬上層資源負載，驗證調度系統的有效性；模擬依賴的分佈式存儲不可用，驗證系統的容錯能力；模擬調度節點不可用，測試調度任務是否自動遷移到可用節點；模擬主備節點故障，測試主備切換是否正常。

驗證監控告警的時效性
經過對系統注入故障，驗證監控指標是否準確，監控維度是否完善，告警閾值是否合理，告警是否快速，告警接收人是否正確，通知渠道是否可用等，提高監控告警的準確和時效性。

定位與解決問題的應急能力
經過故障突襲，隨機對系統注入故障，考察相關人員對問題的應急能力，以及問題上報、處理流程是否合理，達到以戰養戰，鍛鍊人定位與解決問題的能力。

功能和特色

場景豐富度高

ChaosBlade 支持的混沌實驗場景不只覆蓋基礎資源，如 CPU 滿載、磁盤 IO 高、網絡延遲等，還包括運行在 JVM 上的應用實驗場景，如 Dubbo 調用超時和調用異常、指定方法延遲或拋異常以及返回特定值等，同時涉及容器相關的實驗，如殺容器、殺 Pod。後續會持續的增長實驗場景。

使用簡潔，易於理解

ChaosBlade 經過 CLI 方式執行，具備友好的命令提示功能，能夠簡單快速的上手使用。命令的書寫遵循阿里巴巴集團內多年故障測試和演練實踐抽象出的故障注入模型，層次清晰，易於閱讀和理解，下降了混沌工程實施的門檻。

場景擴展方便

全部的 ChaosBlade 實驗執行器一樣遵循上述提到的故障注入模型，使實驗場景模型統一，便於開發和維護。模型自己通俗易懂，學習成本低，能夠依據模型方便快捷的擴展更多的混沌實驗場景。

ChaosBlade 的演進史

EOS（2012-2015）：

故障演練平臺的早期版本，故障注入能力經過字節碼加強方式實現，模擬常見的 RPC 故障，解決微服務的強弱依賴治理問題。

MonkeyKing（2016-2018）：

故障演練平臺的升級版本，豐富了故障場景（如：資源、容器層場景），開始在生產環境進行一些規模化的演練。

AHAS（2018.9-至今）：

阿里雲應用高可用服務，內置演練平臺的所有功能，支持可編排演練、演練插件擴展等能力，並整合了架構感知和限流降級的功能。

ChaosBlade（2019.3）：

是 MonkeyKing 平臺底層故障注入的實現工具，經過對演練平臺底層的故障注入能力進行抽象，定義了一套故障模型。配合用戶友好的 CLI 工具進行開源，幫助雲原生用戶進行混沌工程測試。

近期規劃

功能迭代：

• 加強 JVM 演練場景，支持更多的 Java 主流框架，如 Redis，GRPC
• 加強 Kubernetes 演練場景
• 增長對 C++、Node.js 等應用的支持

社區共建：

一、歡迎訪問 ChaosBlade@GitHub，參與社區共建，包括但不限於：

• 架構設計
• 模塊設計
• 代碼實現
• Bug Fix
• Demo樣例
• 文檔、網站和翻譯

本文做者：中間件小哥

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。