導讀：混沌工程屬於一門新興的技術學科，行業認知和實踐積累比較少，大多數IT團隊對它的理解還沒有上升到一個領域概念，但它實際上是一種提高技術架構彈性能力的複雜技術手段。這篇文章旨在解釋混沌工程是什麼、它是如何使用的以及阿里開源ChaosBlade模型的定義及使用方法。
混沌工程是在分佈式系統上進行實驗的學科, 目的是建立對系統抵禦生產環境中失控條件的能力以及信心，最早由Netflix及相關團隊提出。
瞭解混沌工程
擁抱"混沌"
爲了支持日益複雜的業務，Netflix一直都發力基礎設施。現在Netflix擁有分佈在190多個國家的1億用戶。早期公司的服務器運行在自己機房，但這會造成單點故障和其他問題。在2008年8月，數據庫的問題導致了三天宕機，在此期間在Netflix無法看任何視頻。Netflix工程師在2011年將服務遷移到Amazon Web Services。
這種由數百個微服務組成的新型分佈式架構消除了單點故障。但它也引入了新的複雜性問題，需要更加可靠和容錯性更強的系統。正是在這一點上，Netflix的工程團隊學到了重要的教訓：通過不斷失敗避免失敗。
"混沌"新用法
爲此，Netflix工程師創建了Chaos Monkey，使用該工具可以在整個系統中在隨機位置引發故障。隨着Chaos Monkey的出現，一門新學科誕生了：混沌工程，被描述爲“在分佈式系統上進行實驗的學科，目的是建立對系統承受生產環境中湍流條件能力的信心。”。
2012年，Netflix開源了Chaos Monkey。今天，許多公司(包括谷歌，亞馬遜，IBM，耐克等），都採用某種形式的混沌工程來提高現代架構的可靠性。Netflix甚至將其混沌工程工具集擴展到包括整個“Simian Army(中文可以譯爲猿軍)”，用它攻擊自己的系統。
混沌工程：不是那麼混亂
將混沌工程視爲實際混亂是一種誤解。事實上，大量測試是非隨機的。相反，混沌工程會在實施前進行深入思考，組織有計劃和受控制的實驗，旨在揭示系統在失敗時的表現。
儘量減少雷區
Amalgam Insights的研究員Tom Petrocelli在接受採訪時說，混沌工程最佳實踐的關鍵是“儘量減少雷區。這意味着最大限度地減少對業務的影響。”
爲了確保不會破壞業務，Petrocelli建議工程團隊“精心策劃”混亂工程。
不只是測試，也是生成知識的實驗
Netflix混沌團隊前工程經理Casey Rosenthal在DZone Q＆A中明確指出，混沌工程不僅僅是測試系統的一種方法，它也是一種產生新知識的正確方法。Rosenthal在問答環節中表示，傳統測試仍然至關重要，但混沌工程應該是傳統測試的補充。
1.定義並測量系統的“穩定狀態”。首先精確定義指標，在混沌工程中，業務指標通常比技術指標更有用，因爲它們更適合衡量用戶體驗或運營。
2.創建假設。混沌工程應該包括真正的實驗，涉及真正的未知數。
DevOps解決方案策略師、New Relic SRE Beth Long認爲：“混沌工程不適用於那些可預測的、被運行手冊覆蓋的、你知道必須自動化但還沒有開始的事件。”“你需要它來處理由複雜性本身產生的各種因素。因爲不知道該怎麼介入，所以每個人覺得老虎喫天，無從下爪。”
3.模擬現實世界中可能發生的事情。在《混沌工程：通過實驗建立對系統行爲的信心》一書中，Netflix架構師，Casey Rosenthal，Lorin Hochstein，Aaron Blohowiak，Nora Jones和Ali Basiri，提出了許多混沌工程實踐方法：
-
模擬數據中心的故障
-
強制系統時鐘不同步
-
在驅動程序代碼中模擬I/O異常
-
模擬服務之間的延遲
-
隨機引發函數拋異常
一定要優先考慮潛在的錯誤。系統越複雜，越重要，它就越有可能成爲混沌工程的候選對象。”
4.證明或反駁你的假設。將穩態指標與干擾注入系統後收集的指標進行比較。如果您發現測量結果存在差異，那麼您的混沌工程實驗已經成功 - 您現在可以繼續加固系統，以便現實世界中的類似事件不會導致大問題。或者，如果您發現穩定狀態可以保持，那麼你對該系統的穩定性大可放心。
上述內容來自高可用架構公衆號。
阿里開源工具ChaosBlade
3月底，阿里把六年來在故障演練領域的創意和實踐匯濃縮而成的工具進行開源，命名爲 “ChaosBlade”。混沌工程工具 ChaosBlade 自開源以來，由於其操作簡潔、無侵入、擴展性強的特點，不少開發者將它用來測試自身系統的容錯能力和健壯性，還將它用來驗證容器編排配置是否合理。
接下來，我們將從模型的定義和實現兩個方面爲大家介紹 ChaosBlade 混沌實驗模型，遵循此模型，我們可以簡單明瞭地執行一次混沌實驗，不僅可以控制實驗的最小爆炸半徑，而且可以方便快捷地擴展新的實驗場景或者增強現有場景。chaosblade 和 chaosblade-exec-jvm 工程都是根據此模型來實現。
chaosblade 工程鏈接：
https://github.com/chaosblade-io/chaosblade
chaosblade-exec-jvm 工程鏈接：
https://github.com/chaosblade-io/chaosblade-exec-jvm
模型定義
在給出模型之前，我們先明確實施一次混沌實驗所涉及的一些問題：
-
對什麼做混沌實驗？
-
混沌實驗實施的範圍是什麼？
-
具體實施什麼實驗？
-
實驗生效的匹配條件有哪些？
舉個例子：
一臺 IP 是 10.0.0.1 機器上的應用，調用 [email protected] Dubbo 服務延遲 3s。根據上述的問題列表，先明確的是要對 Dubbo 組件做混沌實驗，實施實驗的範圍是 10.0.0.1 單機，對調用 [email protected] 服務模擬 3s 延遲等等。明確以上內容，就可以精準的實施一次混沌實驗。我們將這些步驟總結並抽象出以下模型：
-
Target：實驗靶點，指實驗發生的組件，例如容器、應用框架（Dubbo、Redis、Zookeeper）等。
-
Scope：實驗實施的範圍，指具體觸發實驗的機器或者集羣等。
-
Matcher：實驗規則匹配器，根據所配置的 Target，定義相關的實驗匹配規則，可以配置多個。由於每個 Target 可能有各自特殊的匹配條件，比如 RPC 領域的 HSF、Dubbo，可以根據服務提供者提供的服務和服務消費者調用的服務進行匹配；緩存領域的 Redis，可以根據 set、get 操作進行匹配。
-
Action：指實驗模擬的具體場景，Target 不同，實施的場景也不一樣，比如磁盤，可以演練磁盤滿、磁盤 IO 讀寫高、磁盤硬件故障等實驗場景。如果是應用，可以抽象出延遲、異常、返回指定值（錯誤碼、大對象等）、參數篡改、重複調用等實驗場景。
回到上述的例子，我們可以將實驗總結成一句話：對 Dubbo 組件（Target）進行故障演練，演練的是 10.0.0.1 主機（Scope）的應用，調用 [email protected] （Matcher）服務延遲 3s（Action）。
僞代碼可以寫成：
Toolkit. // 實驗靶點 dubbo. // 範圍，此處是主機 host("1.0.0.1"). // 組件匹配器，消費者還是服務提供者 consumer(). // 組件匹配器，服務接口 service("com.example.HelloService"). // 組件匹配器，1.0.0 接口版本 version("1.0.0"). // 實驗場景，延遲 3s delay(3000);
ChaosBlade 模型的實現
chaosblade cli 調用
針對上述例子，chaosblade 的調用命令是：
blade create dubbo delay --time 3000 --consumer --service com.example.HelloService --version 1.0.0
-
delay: 模型中的 action，執行延遲演練場景。
-
--time: 模型中 action 參數，指延遲時間。
-
--consumer、 --service、 --version：模型中的 matchers，實驗規則匹配器。
注： 由於 chaosblade 是在單機執行的工具，所以混沌實驗模型中的 scope 默認爲本機，不再顯示聲明。
chaosblade 模型的定義
-
一個組件混沌實驗模型的定義，包含組件名稱和所支持的實驗場景列表。
type ExpModelCommandSpec interface { // 組件名稱 Name() string // 支持的場景列表 Actions() []ExpActionCommandSpec // ... 略 }
-
一個實驗場景 action 的定義，包含場景名稱、場景所需參數和一些實驗規則匹配器。
type ExpActionCommandSpec interface { // 演練場景名稱 Name() string // 規則匹配器列表 Matchers() []ExpFlagSpec // Action 參數列表 Flags() []ExpFlagSpec // Action 執行器 Executor(channel Channel) Executor // ... 略 }
-
一個實驗匹配器的定義，包含參數名、參數描述等等。
type ExpFlagSpec interface { // 參數名 FlagName() string // 參數描述 FlagDesc() string // 是否需要參數值 FlagNoArgs() bool // 是否是必要參數 FlagRequired() bool }
chaosblade 模型的具體實現
以 network 組件爲例，network 作爲混沌實驗組件，目前包含網絡延遲、網絡屏蔽、網絡丟包、DNS 篡改演練場景，則依據模型規範，具體實現爲：
type NetworkCommandSpec struct { } func (*NetworkCommandSpec) Name() string { return "network" } func (*NetworkCommandSpec) Actions() []exec.ExpActionCommandSpec { return []exec.ExpActionCommandSpec{ &DelayActionSpec{}, &DropActionSpec{}, &DnsActionSpec{}, &LossActionSpec{}, } }
network target 定義了 DelayActionSpec、 DropActionSpec、 DnsActionSpec、 LossActionSpec 四種混沌實驗場景，其中 DelayActionSpec 定義如下：
type DelayActionSpec struct { } func (*DelayActionSpec) Name() string { return "delay" } func (*DelayActionSpec) Matchers() []exec.ExpFlagSpec { return []exec.ExpFlagSpec{ &exec.ExpFlag{ Name: "local-port", Desc: "Port for external service", }, &exec.ExpFlag{ Name: "remote-port", Desc: "Port for invoking", }, &exec.ExpFlag{ Name: "exclude-port", Desc: "Exclude one local port, for example 22 port. This flag is invalid when --local-port or remote-port is specified", }, &exec.ExpFlag{ Name: "device", Desc: "Network device", Required: true, }, } } func (*DelayActionSpec) Flags() []exec.ExpFlagSpec { return []exec.ExpFlagSpec{ &exec.ExpFlag{ Name: "time", Desc: "Delay time, ms", Required: true, }, &exec.ExpFlag{ Name: "offset", Desc: "Delay offset time, ms", }, } } func (*DelayActionSpec) Executor(channel exec.Channel) exec.Executor { return &NetworkDelayExecutor{channel} }
DelayActionSpec 包含 2 個場景參數和 4 個規則匹配器。
上述ChaosBlade的相關內容來自阿里巴巴中間件公衆號，作者肖長軍（花名：穹谷），GitHub ID @xcaspar，阿里巴巴高級開發工程師，多年應用性能監控和混沌工程領域工作經驗，阿里雲產品 AHAS 核心開發，ChaosBlade 開源項目負責人。
第五屆深圳GIAC（6月21-23日）精心策劃了“混沌工程”的專題，特邀肖長軍作爲此專場講師，分享《分佈式服務下的混沌工程實踐》的話題。
此外，組委會從互聯網架構最熱門的AI、大中臺、混沌工程、軟件工程、中間件、Java專場等領域甄選最前沿的技術創新實踐案例，識別圖中二維碼看詳情，大會7.5折購票即將截止，席位有限，速速來搶購吧！
