開發十年，就只剩下這套架構體系了！ >>>   

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

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

答案：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 等應用的支援

社群共建：

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

• 架構設計
• 模組設計
• 程式碼實現
• Bug Fix
• Demo樣例
• 文件、網站和翻譯

本文作者：中介軟體小哥

原文連結

本文為雲棲社群原創內容，未經