—混沌鴻蒙，先行五太“天地渾沌如雞子，盤古生其中。萬八千歲，天地開闢。陽清為天，陰濁為地，盤古在其中。一日九變，神於天，聖於地。天日高一丈，地日厚一丈，盤古日長一丈。如此萬八千歲，天數極高，地數極深，盤古極長。故天去地九萬里，後乃有三皇。”《山海經》中這樣形容混沌鴻蒙到天地初開的情形。據一些古籍記載，天地誕生前經歷了五個狀態，叫做先天五太。而所謂的先天五太，即太易、太初、太始、太素和太極。這些都是中國的道家哲學，對宇宙、世界起源的一種哲學解釋。哲學的智慧產生於人類的實踐活動，源自於人們對實踐的追問和對世界的思考。近些年來，開源數字基礎設施迭代不斷加快，加速了企業在雲上部署其數據中心、業務中心的腳步。多雲、混合雲架構已經越來越多的成為企業數字辦公的首選方案。在這樣的背景下，為了讓基礎設施更好地適合複雜多變的運行環境，提供大規模、超高穩定的運行效率，一種“新”的軟件思潮，即“混沌工程學（Chaos Engineering）”被提升到一個很重要的高度。不過略感遺憾，這一理念的出現並非來自中國。2008年，Netflix決定把它的業務遷移到AWS上，而為了解決該階段暴露的問題，它們端到端的提出一套穩定性測試理念與工具框架，從2012年以來，Netflix陸續開源了猴子軍團系列（Chaos Monkey, Latency Monkey, Conformity Monkey, Docker Monkey, Security Monkey, 10-18 Monkey, Chaos Gorilla, Chaos Kong），催生了這一領域的蓬勃發展。隨著國家新基建，上雲等政策的大力倡導，國內接下來勢必將會迎來新一輪爆發期。而這一輪爆發、變革核心在於穩定的底盤，在於不可變的基礎設施。基礎設施本身是否能夠適應複雜的運行環境，以及迭代加速的數字升級戰場，這需要混沌工程的指導。在此基礎上，我們同樣需要某種手段驗證上層應用是否可以在這個過程中不受影響並保持一致，混沌工程的引入可以讓問題提前暴露、提前解決，從而在工程設計與實現上規避風險，不斷提高系統彈性，持續交付高質量產品。
02—Chaos框架應運而生
OpenMessaging是雲原生、廠商中立的分佈式消息開放規範的集合。Benchmark作為OpenMessaging中一套性能基準測試框架，已經被國內外各大評測機構和開發人員廣泛接受。但跑得快不一定意味著跑的穩，跑的遠，跑的happy。換言之，可靠性，可用性與可擴展性也是設計分佈式系統，尤其是雲原生應用需要重點考慮的。如何去設計這些度量點、如何去驗證設計是否符合預期，如何能夠持續快速的演進架構而不破壞這些不變的設計準則，儼然成為了分佈式基礎設施新的挑戰。
通常來說，分佈式系統可靠性的驗證可以採用形式化規範來進行，比如TLA+，但是這樣的驗證需要大量的特定理論知識。另一個方式是通過測試來驗證，但普通的單元測試和集成測試無法覆蓋到一些只有在高併發或者故障發生時才會出現的邊緣情況。人們在合理的架構，高質量的代碼，完善的測試等方面做了很多努力，然而仍舊無法讓自己的系統高可靠、高可用與彈性化，混沌工程為解決這些問題帶來新的思路，其基本原則可以概括為：
- 建立一個圍繞穩定狀態行為的假說
- 多樣化真實世界的事件
- 在生產環境中運行實驗
- 持續自動化運行實驗
- 最小化爆炸半徑
通過蓄意製造”破壞“來確保容錯機制不斷運行並接受考驗，從而驗證系統的可靠性、可用性與彈性伸縮，提高故障自然發生時系統能正確處理的信心。
當前，業界已經存在一些基於混沌工程的框架，但卻存在一些問題，比如ChaosMonkey提供了故障注入的手段，但無法給出針對於特定分佈式基礎設施的正確性、可靠性、可用性校驗結果。Jepsen能在特定故障下驗證分佈式系統是否滿足一致性，但是Jepsen並未針對領域特有順序性、故障恢復時間等檢測。此外，Jepsen測試需要用clojure語言編寫，而clojure作為一種小眾語言給分佈式系統的適配帶來了不小困難。
在這樣的背景下，OpenMessaging Chaos框架應運而生。作為分佈式消息領域的先行者，它借鑑了混沌工程的理念，內置了豐富的、擴展良好的檢測模型，通過標準化API，暴露衡量分佈式消息隊列的可靠性、可用性、順序性與可伸縮性的observable entrypoint，非常利於各個messaging 廠商的接入。另外，作為消息領域的Chaos框架，它操作簡單，適配容易，可以被集成到CI/CD框架（如Jenkins）中，持續幫助系統進行演進與迭代，提高雲原生消息架構的可靠性。
03—Chaos框架介紹
總體架構Chaos框架總體架構如上圖所示，主要由控制節點和若干個集群節點組成。控制節點由Driver（驅動）、Model（模型）、Fault（故障）和Checker（檢測器）組件組成。框架啟動後，控制節點會以SSH方式遠程登陸到集群節點，通過自動化部署或手動部署方式，使集群節點組成一個待測試的分佈式集群，並會根據需要測試的分佈式基礎設施找到對應的Driver組件並載入，根據設置的併發數建立相應個數的客戶端。測試開始後，控制節點根據Model組件定義的執行流程控制客戶端對集群進行操作，比如對於隊列模型來說，客戶端會併發地向待測試的分佈式消息隊列集群調用入隊和出隊操作。測試過程中，Fault組件會對集群節點進行故障模擬，包括網絡分區、網絡包延遲、隨機殺死進程等。測試結束，Checker組件對歷史日誌文件的自動化分析得出測試結果和可視化圖表。此外，框架提供了開放API，方便廠商對Driver、Model、Fault、Checker等組件進行自行擴展。
核心指標
伴隨著雲計算的發展，雲計算技術、容災應急響應機制都日趨成熟和完善。業界對於系統如何達到高可用、高可靠是有一些基本共識的，比如：服務拆分；併發控制，服務隔離；灰度發佈；限流降級；鏈路追蹤，全方位監控報警等。即便有這些最佳實踐的指導，我們仍不能忽略一些”突如其來“的災難，容災體系的建設依舊是嚴峻且富有挑戰的。近幾年世界最好的幾家雲計算公司頻發”故障“，如何面對這些突發而來的故障，是每一個基礎設施設計者需要深刻思考的。通常來說，容災系統設計中，往往會主要關注兩個指標：
- RPO（Recovery Point Objective）：即數據恢復點目標，以時間為單位，即在災難發生時，系統和數據必須恢復的時間點要求。RPO標誌系統能夠容忍的最大數據丟失量。
- RTO（Recovery Time Objective）：即恢復時間目標，以時間為單位，即在災難發生後，信息系統或業務功能從停止到必須恢復的時間要求。
RPO關注數據丟失，即系統可靠性，RTO關注服務丟失，即系統可用性。Chaos框架有內置的檢測模型，天然支持針對於消息領域的可靠性和可用性檢測。
除此之外，框架還支持檢測消息領域特有的一些核心指標：
- 投遞語義。檢測消息數據是否丟失或重複， 判斷消息系統在故障下是否滿足預期At least once、At most once 、Exactly Once投遞語義，驗證系統的可靠性。
- 故障恢復時間。檢測集群故障時間段是否發生不可用，以及不可用的後故障恢復時間，即檢測系統是否達到預期的RTO，驗證系統的可用性。
- 順序性。檢測消息系統的順序性，比如在故障下消息是否滿足預期的分區順序性。
另外，框架還提供了可視化的時延圖，可以幫助開發人員和測試人員進一步瞭解被測試的消息平臺在Chaos框架運行過程中的表現情況，發現可能存在的問題。
故障模擬
Chaos框架借鑑了混沌工程的理念，提供了各種類型的故障模擬，通過模擬各種極端環境，檢測分佈式基礎設施在故障下是否仍然符合預期的檢測指標，建立分佈式基礎設施承受生產環境中湍流條件能力的信心。如下圖所示，當前支持的故障類型主要包括：
- random-partition（fixed-partition）：挑選節點進行網絡隔離，模擬常見的對稱網絡分區。
- random-loss：挑選節點並對這些節點接收和發送的網絡包進行按比例丟棄，模擬一些節點網絡較差的情況。
- random-kill（fixed-kill、minor-kill、major-kill）：挑選節點並對節點上服務進程進行殺死和重啟，故障模擬常見的進程崩潰情況。
- random-suspend（fixed-suspend、minor-suspend、major-suspend）：挑選節點並利用SIGSTOP/SIGCONT信號量對節點上服務進程進行暫停，模擬一些慢節點的情況，比如發生Full GC、OOM等。
- bridge和partition-majorities-ring：模擬比較極端的非對稱網絡分區。
（注：fixed-xxx故障為用戶指定固定的節點進行故障模擬，minor-xxx為隨機挑選少數節點進行故障模擬，major-xxx為隨機挑選多數節點進行故障模擬）
04—快速上手
由上述架構可知，框架的運行需要一個控制節點以及由若干個測試節點組成的待測試集群，控制節點必須能SSH到測試節點上。因此通常來說測試需要多臺機器，但是框架也提供了docker啟動方式，能在一臺機器上完成整個測試。下面介紹如何利用Chaos框架（docker模式）測試Apache RocketMQ消息隊列。
首先利用docker-compose啟動控制節點容器和測試節點容器
<code>cd openmessaging-chaos/docker./up.sh --dev/<code>
然後再開一個shell，進入控制節點容器內部，並調用maven命令完成測試框架的安裝
<code>docker exec -it chaos-control bashmvn clean install/<code>
框架安裝完成後，就可以進行RocketMQ故障下的可靠性和可用性驗證。編輯`driver-rocketmq/rocketmq.yaml`，利用5個節點組成一個RocketMQ DLedger的broker組作為待測試的集群。以minor-kill故障模擬為例進行Chaos測試，minor-kill故障模擬會隨機挑選集群中少數節點進程殺死，由於殺死少數節點，即使集群故障後不可用也能在一段時間內恢復，方便測試集群的故障恢復時間。測試過程中我們設置4個客戶端併發向待RocketMQ DLedger集群發送和接收消息，故障模擬時間間隔為60s，即60s正常運行，60s故障模擬，一直循環，整個階段一共持續1200s。如果是第一次測試，需要在測試節點上安裝RocketMQ，因此還需添加--install參數（安裝完成後續測試可以不添加該參數）。最後我們開啟rto參數和order-test參數，測試集群故障恢復時間和消息的分區順序性。
<code>bin/chaos.sh --drivers driver-rocketmq/rocketmq.yaml --fault minor-kill --fault-interval 60 --limit-time 1200 --rate 1000 --install --rto --order-test/<code>
測試結束後，框架會給出測試結果和時延圖。下圖展示了整個測試過程中入隊操作的時延情況。
下圖是測試結束後Chaos框架給出的統計結果，可以看到一共成功發送了50W個數據，雖然故障導致8個消息重複（duplicateMessageCount=8），但沒有消息丟失（lostMessageCount=0），這表明，RocketMQ DLedger模式即使在故障下仍舊滿足At Least Once的投遞語義（atLeastOnce=true），RPO為0符合預期。RTOTestResult結果表明10次故障時間段一共發生了5次集群不可用的情況（與上述時延圖一致），但每次集群都能在30秒以內恢復，平均故障恢復時間在29秒左右（available failure recovery time = 29211ms，主要取決於客戶端更新路由的時間）。此外，OrderTestResult結果表明，消息平臺在故障發生後仍然保持了分區順序性（partition order = true）。
利用Chaos框架，我們檢測了基於 DLedger構建的Apache RocketMQ高可用順序消息集群在少數節點崩潰故障下的表現情況，除了minor-kill故障之外，我們還可以注入其他類型的故障，進一步驗證RocketMQ集群在故障下的可靠性、可用性和順序性，發現潛在的問題。
05—後續展望Chaos框架抽象出了一套針對於分佈式系統普適性的擴展點和API，方便各種分佈式基礎設施的集成。在驅動層，框架定義兩組接口：ChaosNode和ChaosClient。ChaosNode接口定義了集群節點的生命週期，主要包括setup、start、stop、kill、teardown等方法，來完成集群節點的遠程安裝、啟動、停止、殺死和卸載等操作，框架提供了實現這些方法的基礎API，可以方便地實現這些操作。ChaosClient接口定義客戶端的生命週期和執行操作，不同模型對應不同的執行操作，比如針對於消息領域，主要是enqueue和dequeue兩個方法，由於每一個消息平臺都會包含入隊和出隊的實現，因此適配難度很低。除此之外，用戶還可以利用Chaos框架提供的基礎API去自行擴展Model、Fault、Checker等組件，根據每個分佈式基礎設施的不同，實現自己的檢測模型，制定不同的場景進行測試。
目前，Chaos 框架已經發布了首個版本，按照規劃，接下來陸續發佈2個大版本，包括實現其它消息隊列的適配等重要特性。為了更好的幫助開源、雲廠商接入這套規範，OpenMessaging 技術委員會TSC成立了相關的workgroup，歡迎大家參與進來（留言加入），加速推進這個領域的不斷成熟。另外，我們也在積極地和CNCF Chaos WorkGroup進行交流，期望繼續推進整個領域的標準化與生態化。
混沌鴻蒙，先天五太。世界看中國，中國看我們。
備註：
[1] 項目地址：https://github.com/openmessaging/openmessaging-chaos
[2] Chaos Eng WG Proposal in CNCF : https://docs.google.com/document/d/1BeeJZIyReCFNLJQrZjwA4KMlUJelxFFEv3IwED16lHE/edit?ts=5ace0eab#heading=h.ephtflhfpd1d
[3] PRINCIPLES OF CHAOS ENGINEERING: http://principlesofchaos.org/?lang=ENcontent
閱讀更多 啟迪雲Tuscloud 的文章
