混沌工程 | 你所不知道的 ChaosBlade 那些事

項目背景

阿里巴巴內部從最先引入混沌工程解決微服務的依賴問題，到業務服務、雲服務穩態驗證，進一步升級到公共雲、專有云的業務連續性保障，以及在驗證雲原生系統的穩定性等方面積累了比較豐富的場景和實踐經驗。而且當時混沌工程相關的開源工具存在場景能力分散、上手難度大、缺乏實驗模型標準，場景難以擴展和沉澱等問題。這些問題就會致使很難實現平臺化，你很難經過一個平臺去囊括這些工具。因此咱們開源了 ChaosBlade 這個混沌工程實驗執行工具，目的是服務於混沌工程社區，共同推動混沌工程領域的發展。node

項目介紹

ChaosBlade 項目託管在 Github 平臺，放在 chaosblade-io 組織下，方便項目管理和社區發展。設計 ChaosBlade 初期就考慮了易用性和場景擴展的便捷性，方便你們上手使用以及根據各自須要擴展更多的實驗場景，遵循混沌實驗模型提供了統一的操做簡潔的執行工具，而且根據領域劃分將場景實現封裝成一個一個單獨的項目，方便實現領域內場景擴展。目前包含的場景領域以下：mysql

基礎資源：好比 CPU、內存、網絡、磁盤、進程等實驗場景
Java 應用：好比數據庫、緩存、消息、JVM 自己、微服務等，還能夠指定任意類方法注入各類複雜的實驗場景
C++ 應用：好比指定任意方法或某行代碼注入延遲、變量和返回值篡改等實驗場景
Docker 容器：好比殺容器、容器內 CPU、內存、網絡、磁盤、進程等實驗場景
Kubernetes 平臺：好比節點上 CPU、內存、網絡、磁盤、進程實驗場景，Pod 網絡和 Pod 自己實驗場景如殺 Pod，容器的實驗場景如上述的 Docker 容器實驗場景
雲資源：好比阿里雲 ECS 宕機等實驗場景

以上場景領域都單獨封裝成一個項目來實現，目前包含的項目以下：git

chaosblade：混沌實驗管理工具，包含建立實驗、銷燬實驗、查詢實驗、實驗環境準備、實驗環境撤銷等命令，是混沌實驗的執行工具，執行方式包含 CLI 和 HTTP 兩種。提供完善的命令、實驗場景、場景參數說明，操做簡潔清晰。
chaosblade-spec-go: 混沌實驗模型 Golang 語言定義，便於使用 Golang 語言實現的場景都基於此規範便捷實現。
chaosblade-exec-os: 基礎資源實驗場景實現。
chaosblade-exec-docker: Docker 容器實驗場景實現，經過調用 Docker API 標準化實現。
chaosblade-operator: Kubernetes 平臺實驗場景實現，將混沌實驗經過 Kubernetes 標準的 CRD 方式定義，很方便的使用 Kubernetes 資源操做的方式來建立、更新、刪除實驗場景，包括使用 kubectl、client-go 等方式執行，並且還可使用上述的 chaosblade cli 工具執行。
chaosblade-exec-jvm: Java 應用實驗場景實現，使用 Java Agent 技術動態掛載，無需任何接入，零成本使用，並且支持卸載，徹底回收 Agent 建立的各類資源。
chaosblade-exec-cplus: C++ 應用實驗場景實現，使用 GDB 技術實現方法、代碼行級別的實驗場景注入。

以上項目都遵循混沌實驗模型定義實驗場景，這樣不只實現實驗場景水平領域擴展，並且每一個場景領域單獨一個項目，使用該領域下標準方式去設計實現場景，因此很方便的實現領域內場景垂直擴展。github

除了實驗場景相關項目，還有相關的文檔項目：sql

chaosblade-help-doc: ChaosBlade 工具和場景使用文檔
chaosblade-dev-doc: ChaosBlade 項目開發文檔
awesome-chaosblade: ChaosBlade 相關的外部文檔

實驗模型

前面提到 ChaosBlade 項目是遵循混沌實驗模型設計，不只簡化了實驗場景定義，並且能夠很方便的擴展場景，而且經過 chaosblade cli 工具能夠統一調用，便於構建上層的混沌實驗平臺。下面經過實驗模型的推導、介紹、意義和具體的應用來詳細介紹此模型。docker

實驗模型的推導

目前的混沌實驗主要包含故障模擬，咱們通常對故障的描述以下：數據庫

10.0.0.1 機器上掛載的 A 磁盤滿形成了服務不可用
全部節點上的 B dubbo 服務由於執行緩慢形成上游 A dubbo 服務調用延遲，從而形成用戶訪問緩慢
Kubernetes A 集羣中 B 節點上 CPU 全部核使用率滿載，形成 A 集羣中的 Pod 調度異常
Kubernetes C 集羣中 D Pod 網絡異常，形成 D 相關的 Service 訪問異常

經過上述，咱們可使用如下句式來描述故障：由於某某機器（或集羣中的資源，如 Node，Pod）上的哪一個組件發生了什麼故障，從而形成了相關影響。咱們也能夠經過下圖來看故障描述拆分：
json

能夠經過這四部分來描述現有的故障場景，全部咱們抽象出了一個故障場景模型，也稱爲混沌實驗模型
api

實驗模型的介紹

此實驗模型詳細描述以下：緩存

Scope: 實驗實施範圍，指具體實施實驗的機器、集羣及其資源等
Target: 實驗靶點，指實驗發生的組件。如基礎資源場景中的 CPU、網絡、磁盤等，Java 場景中的應用組件如 Dubbo、Redis、RocketMQ、JVM 等，容器場景中的 Node、Pod、Container自身等
Matcher: 實驗規則匹配器，根據所配置的 Target，定義相關的實驗匹配規則，能夠配置多個。因爲每一個 Target 可能有各自特殊的匹配條件，好比 RPC 領域的 Dubbo、gRPC 能夠根據服務提供者提供的服務和服務消費者調用的服務進行匹配，緩存領域的 Redis，能夠根據 set、get 操做進行匹配。還能夠對 matcher 進行擴展，好比擴展實驗場景執行策略，控制實驗觸發時間。
Action: 指實驗模擬的具體場景，Target 不一樣，實施的場景也不同，好比磁盤，能夠演練磁盤滿，磁盤 IO 讀寫高，磁盤硬件故障等。若是是應用，能夠抽象出延遲、異常、返回指定值（錯誤碼、大對象等）、參數篡改、重複調用等實驗場景。若是是容器服務，能夠模擬 Node、Pod、Container 資源異常或者其上的基礎資源異常等。

使用此模型能夠很清晰表達出如下實施混沌實驗須要明確的問題：

混沌實驗的實施範圍是什麼
實施混沌實驗的對象是什麼
實驗對象觸發實驗的條件有哪些
具體實施什麼實驗場景

實驗模型的意義

此模型具備如下特色：

簡潔：層次清晰，通俗易懂
通用：覆蓋目前全部的故障場景，包含基礎資源、應用服務、容器服務、雲資源等
易實現：很方便的定義清晰的接口規範，實驗場景擴展實現簡單
語言、領域無關：能夠擴展多語言、多領域的模型實現

此模型具備如下的意義：

更精準的描述混沌實驗場景
更好的理解混沌實驗注入
方便沉澱現有的實驗場景
依據模型發掘更多的場景
混沌實驗工具更加規範、簡潔

實驗模型的應用

ChaosBlade 下的項目遵循此混沌實驗模型設計，須要注意的是此模型定義了混沌實驗場景如何設計，可是實驗場景的具體實現每一個領域各不相同，因此將 ChaosBlade 依據領域實現封裝成各自獨立的項目，每一個項目根據各領域的最佳實踐來實現，不只能知足各領域使用習慣，並且還能夠經過混沌實驗模型來創建與 chaosblade cli 項目的關係，方便使用 chaosblade 來統一調用，各領域下的實驗場景依據混沌實驗模型生成 yaml 文件描述，暴露給上層混沌實驗平臺，混沌實驗平臺根據實驗場景描述文件的變動，自動感知實驗場景的變化，無需新增場景時再作平臺開發，使混沌平臺更加專一於混沌工程其餘部分。如下分爲基於混沌實驗模型的 chaosblade cli 設計、基於混沌實驗模型的 chaosblade operator 設計和基於混沌實驗模型構建混沌實驗平臺三部分詳細介紹混沌實驗模型的應用。

基於混沌實驗模型的 chaosblade cli 設計

chaosblade 項目自己使用 Golang 構建，解壓即用，工具採用 CLI 方式執行，使用簡單，具有完善的命令提示。根據 chaosblade-spec-go 項目對混沌實驗模型的定義，解析遵循混沌實驗模型實現的實驗場景 yaml 描述，將實驗場景轉換爲 cobra 框架所支持的命令參數，實現變量參數化、參數規範化，並且將整個實驗對象化，每一個實驗對象都會有個 UID，方便管理。

經過一個具體的實驗場景來講明 chaosblade cli 的使用。

咱們執行的實驗是對其中一個 provider 服務實例注入調用 mk-demo 數據庫延遲的故障，能夠看到上圖左下角，這個就是對 demo 數據庫注入延遲的命令，能夠看出命令很是簡潔清晰，好比很明確的表達出咱們的實驗目標是 mysql，咱們的實驗場景是作延遲，後面這些都是這些數據庫的匹配器，好比表，查詢類型，還有控制實驗的影響條數等等，使用 ChaosBlade 能夠頗有效的控制實驗的爆炸半徑。執行這條命令就能夠對這臺機器的 provider 服務注入故障，你們能夠看到我注入故障以後，這裏這個圖就是我馬上收到了釘釘的報警，那麼這個 case 是符合預期的 case，可是即便符合預期的case，也是有價值的，須要相關的開發和運維人員是要去排查延遲的問題根因並恢復，有助於提升故障應急效率。
chaosblade 的中文使用文檔：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn

基於混沌實驗模型的 chaosblade operator 設計

chaosblade-operator 項目是針對 Kubernetes 平臺所實現的混沌實驗注入工具，遵循上述混沌實驗模型規範化實驗場景，把實驗定義爲 Kubernetes CRD 資源，將實驗模型中的四部分映射爲 Kubernetes 資源屬性，很友好的將混沌實驗模型與 Kubernetes 聲明式設計結合在一塊兒，依靠混沌實驗模型便捷開發場景的同時，又能夠很好的結合 Kubernetes 設計理念，經過 kubectl 或者編寫代碼直接調用 Kubernetes API 來建立、更新、刪除混沌實驗，並且資源狀態能夠很是清晰的表示實驗的執行狀態，標準化實現 Kubernetes 故障注入。除了使用上述方式執行實驗外，還可使用 chaosblade cli 方式很是方便的執行 kubernetes 實驗場景，查詢實驗狀態等。
遵循混沌實驗模型實現的 chaosblade operator 除上述優點以外，還能夠實現基礎資源、應用服務、Docker 容器等場景複用，大大方便了 Kubernetes 場景的擴展，因此在符合 Kubernetes 標準化實現場景方式之上，結合混沌實驗模型能夠更有效、更清晰、更方便的實現、使用混沌實驗場景。
下面經過一個具體的案例來講明 chaosblade-operator 的使用：對 cn-hangzhou.192.168.0.205 節點本地端口 40690 訪問模擬 60% 的網絡丟包。
使用 yaml 配置方式，使用 kubectl 來執行實驗

apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
  name: loss-node-network-by-names
spec:
  experiments:
  - scope: node
    target: network
    action: loss
    desc: "node network loss"
    matchers:
    - name: names
      value: ["cn-hangzhou.192.168.0.205"]
    - name: percent
      value: ["60"]
    - name: interface
      value: ["eth0"]
    - name: local-port
      value: ["40690"]

執行實驗：

kubectl apply -f loss-node-network-by-names.yaml

查詢實驗狀態，返回信息以下（省略了 spec 等內容）：

~ » kubectl get blade loss-node-network-by-names -o json                                                            
{
    "apiVersion": "chaosblade.io/v1alpha1",
    "kind": "ChaosBlade",
    "metadata": {
        "creationTimestamp": "2019-11-04T09:56:36Z",
        "finalizers": [
            "finalizer.chaosblade.io"
        ],
        "generation": 1,
        "name": "loss-node-network-by-names",
        "resourceVersion": "9262302",
        "selfLink": "/apis/chaosblade.io/v1alpha1/chaosblades/loss-node-network-by-names",
        "uid": "63a926dd-fee9-11e9-b3be-00163e136d88"
    },
        "status": {
        "expStatuses": [
            {
                "action": "loss",
                "resStatuses": [
                    {
                        "id": "057acaa47ae69363",
                        "kind": "node",
                        "name": "cn-hangzhou.192.168.0.205",
                        "nodeName": "cn-hangzhou.192.168.0.205",
                        "state": "Success",
                        "success": true,
                        "uid": "e179b30d-df77-11e9-b3be-00163e136d88"
                    }
                ],
                "scope": "node",
                "state": "Success",
                "success": true,
                "target": "network"
            }
        ],
        "phase": "Running"
    }
}

經過以上內容能夠很清晰的看出混沌實驗的運行狀態，執行如下命令中止實驗：

kubectl delete -f loss-node-network-by-names.yaml

或者直接刪除此 blade 資源

kubectl delete blade loss-node-network-by-names

還能夠編輯 yaml 文件，更新實驗內容執行，chaosblade operator 會完成實驗的更新操做。

使用 chaosblade cli 的 blade 命令執行

blade create k8s node-network loss --percent 60 --interface eth0 --local-port 40690 --kubeconfig config --names cn-hangzhou.192.168.0.205

若是執行失敗，會返回詳細的錯誤信息；若是執行成功，會返回實驗的 UID：

{"code":200,"success":true,"result":"e647064f5f20953c"}

可經過如下命令查詢實驗狀態：

blade query k8s create e647064f5f20953c --kubeconfig config

{
  "code": 200,
  "success": true,
  "result": {
    "uid": "e647064f5f20953c",
    "success": true,
    "error": "",
    "statuses": [
      {
        "id": "fa471a6285ec45f5",
        "uid": "e179b30d-df77-11e9-b3be-00163e136d88",
        "name": "cn-hangzhou.192.168.0.205",
        "state": "Success",
        "kind": "node",
        "success": true,
        "nodeName": "cn-hangzhou.192.168.0.205"
      }
    ]
  }
}

銷燬實驗：

blade destroy e647064f5f20953c

除了上述兩種方式調用外，還可使用 kubernetes client-go 方式執行，具體可參考：https://github.com/chaosblade-io/chaosblade/blob/master/exec/kubernetes/executor.go 代碼實現。

經過上述介紹，能夠看出在設計 ChaosBlade 項目初期就考慮了雲原生實驗場景，將混沌實驗模型與 Kubernetes 設計理念友好的結合在一塊兒，不只能夠遵循 Kubernetes 標準化實現，還能夠複用其餘領域場景和 chaosblade cli 調用方式，所謂的歷史包袱根本不存在 :-)。

基於混沌實驗模型構建混沌實驗平臺

前面也提到了遵循混沌實驗模型實現的實驗場景，可經過 yaml 文件來描述，上層實驗平臺能夠自動感知實驗場景的變動，無需平臺再作開發，達到實驗平臺與實驗場景解耦的目的，使你們能夠更加專一於混沌實驗平臺自己的開發上。下面拿 AHAS Chaos 平臺舉例來講明如何基於混沌實驗模型和 ChaosBlade 構建混沌實驗平臺。

能夠看到:

chaosblade 會合並全部領域場景的 yaml 文件，提供給 ChaosBlade SDK
ChaosBlade SDK 感知 yaml 文件變化，從新解析場景描述文件，透傳給上層平臺，包含場景和場景參數的變動
ChaosBlade SDK 透傳用戶在平臺上所配置的參數，調用 chaosblade 工具執行
chaosblade 工具會根據調用參數，和解析各領域 yaml 場景描述文件來調用不一樣的執行器

總結

混沌實驗模型的應用可概括爲如下幾點：

混沌實驗模型使實驗場景變量參數化，參數規範化
可遵循模型實現實驗場景領域化的水平擴展
可將混沌實驗模型和領域內標準化實現相結合，便捷實現領域內場景垂直擴展
上層的領域場景能夠複用遵循混沌實驗模型定義的場景
經過混沌實驗模型聲明的場景描述能夠很好的接入到 chaosblade cli 中
遵循實驗模型能夠很方便的構建上層混沌實驗平臺

項目意義

混沌工程領域已提出多年，混沌工程社區的每個人都貢獻着本身的力量來完善整個混沌工程領域體系，尤爲是混沌工程理論的提出推進了整個混沌工程領域快速發展。咱們在阿里巴巴內部實踐混沌工程不少年，深知落地混沌工程之路充滿各類挑戰，也知道注入混沌實驗只是混沌工程中的一環，混沌工程背後的思考、落地方案和實踐經驗也是很重要的一部分。咱們只是想把咱們認爲好用的內部工具奉獻給社區，隨後將剛纔提到的實踐經驗也經過各類渠道分享給你們，你們能夠將此工具與實踐經驗相結合，做爲企業落地混沌工程的一個入手點，共同推動混沌工程領域的進步，僅此而已。
上述詳細介紹了 ChaosBlade 工具的設計和背後的思考，以及將混沌實驗模型與各領域標準實現相結合的優點，歡迎對高可用架構感興趣的各位加入到 ChaosBlade 社區中來，加入到混沌工程社區中來。總而言之，ChaosBlade 相信：開源世界中，任何幫助都是貢獻。

將來規劃

ChaosBlade 社區在加強原有領域的同時，好比加強雲原生領域場景，還會增長更多領域的場景，例如：

Golang 應用混沌實驗場景
NodeJS 應用混沌實驗場景

除實驗場景外，還會如下規劃：

提供一個混沌實驗平臺供你們使用
完善 ChaosBlade 各項目的開發文檔
完善 chaosblade 工具的英文文檔

歡迎你們加入，一塊兒共建，不限於：

bug report
feature request
performance issue
help wanted
doc incomplete
test missing
feature design
any question on project

ChaosBlade 項目纔剛剛開始，歡迎開源愛好者在使用 ChaosBlade 過程當中產生的任何想法和問題，均可以經過 issue 或者 pull request 的方式反饋到 Github 上。

查看更多：https://yq.aliyun.com/articles/743102?utm_content=g_1000102888

上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/