雲計算

去哪兒網基於ChaosBlade的混沌工程實踐

作者 | 去哪兒網基礎平臺團隊

前言


微服務架構已經在去哪兒網(Qunar)實施多年,微服務應用數量達到數千之多,隨著服務之間的調用鏈路越來越複雜,故障頻頻發生,給公司帶來巨大的經濟損失,穩定性建設工作就成為了一項重要的工作。從 2010 年 Netflix 提出通過 Chaos Engineering 的方式提升系統穩定性之後,到今天 Chaos Engineering 已經被證明是一種有效的發現系統弱點,建立對系統抵禦生產環境中失控條件的能力以及信心的有效手段。從 2019 年底去哪兒網也結合自身的技術體系開始進行混沌工程相關的探索,下面就來介紹下我們的實踐經驗。


選型


為了避免重複造輪子,我們在啟動項目之初調研了當時已經開源的混沌工程相關工具,並結合自身的技術體系特點進行了分析:


  • 當時基礎資源以 KVM 為主,同時也在探索容器化,所以兩個平臺都需要支持。
  • 公司內部主要的技術棧為 Java。


基於上面的兩點,加上社區活躍情況等,選擇 ChaosBlade 為故障注入的工具,加上自研的混沌工程控制檯(當時還沒有 chaosblade-box)作為最終方案。


架構


基於公司內部的系統體系,整體的架構如下:


image

縱向來看,自上而下:


  • 服務治理,Portal(提供應用畫像,CICD的平臺)提供了應用的依賴關係,應用的屬性,運行時資源等信息,通過混沌工程UI可以創建出故障演練(故障演練包含了應用信息,應用資源,待注入故障等);


  • 混沌工程控制檯(Chaos控制檯),提供了多個應用多個故障的任務流程編排,故障演練流程的控制的功能;


  • Saltstack,chaosblade-operator 提供了 chaosblade 的安裝和卸載能力;


  • 應用的資源分為 KVM 和 K8S 承載的容器,故障演練編排系統通過 Restful API 和 chaosblade 啟動的 HTTP 服務進行通信,來進行故障的注入和恢復。


橫向來看:


  • 自動化測試平臺主要提供演練時線上 case 的迴歸能力,以及用來做強弱依賴的標記斷言;


  • 演練開始時,Chaos控制檯會監聽相關應用的核心指標告警,如果有告警信息會通知給相關負責人並終止和恢復演練,這樣可以及時止損。


系統演進


去哪兒網這邊的混沌工程主要經歷了 2 個階段:


1、故障注入能力的建設。這個階段主要解決的問題是用戶可以手動的通過創建故障演練,通過合適的故障策略來驗證系統的某些方面是否符合預期;


2、提供強弱依賴場景下的,依賴標記,強弱依賴驗證,以及自動化強弱依賴閉環的能力,用混沌工程來提高微服務治理效率。


4.1 故障演練


通過故障注入來模擬故障發生是混沌工程的基礎能力。在這個階段主要提供 3 種場景的故障注入,機器關機,OS 層的故障,以及 Java 應用的故障注入,在此基礎之上我們還做了場景化的功能。


image

4.1.1 演練流程


一個典型的演練流程如下:


image

4.1.2 難點


  • 開源故障策略不足


chaosblade-exec-jvm 中提供了 Java 故障注入的基礎能力,也提供了部分開源組件的插件,但是對於公司內部的組件來說還是不足。於是我們中間件的同學進行了二次開發,增加了 AsyncHttpClient, QRedis 故障注入相關的插件,同時也針對 HTTP DUBBO 增加了基於調用點的故障注入功能。

  • 容器化改造


2021年中,去哪兒網開始應用的容器化遷移,故障演練也需要支持容器化下的演練。基於 chaosblade-operator 做了如下幾個方案選型:


方案

說明

優勢

劣勢

chaosblade-operator

完全採用開源方案,Agent安裝和策略注入都使用CRD的方式

貼近雲原生,CRD比較完善

控制端需要重新開發一套對接K8s的故障注入流程,前端給用戶的策略也需要重新兼容,如果新增策略也需要開發CRD

sidecar

隨應用整個應用週期,也需要通過CRD或者exec的方式來操作agent


提前佔用內存,CPU資源,只解決了agent安裝問題,策略下發和控制端邏輯沒解決

chaosblade-operator + blade server

使用CRD完成Agent的安裝卸載,策略注入還是使用http端口交互的模式

改造成本小,控制端跟KVM的方式一致

需要對 chaosblade-operator 進行部分功能的二次開發


方案中主要關注的3個問題:


  • agent的安裝和卸載
  • 策略的注入和恢復
  • 控制端的改造成本


基於上面幾個方案的對比,最終是基於方案 3 進行實施的。


4.2 強弱依賴自動閉環


4.2.1 背景


基於故障演練平臺我們提供了強弱依賴場景下的故障演練功能:


  • 應用間依賴信息展示,依賴關係標註
  • 根據依賴信息,反填故障策略參數


但是整個強弱依賴關係的驗證還是需要人來驅動,於是我們結合了自動化測試工具開發強弱依賴自動標記的功能,通過自動化的流程完成強弱依賴關係的維護,形成閉環。

4.2.2 方案


chaos 控制檯會週期性的從服務治理平臺獲取應用的依賴關係,根據下游接口來生成基於拋異常策略的故障演練。接著對應用的測試環境進行故障注入,再通過自動化測試平臺跑 case 以及實時做 diff 來斷言,最終得到斷言結果。chaos 控制檯結合測試斷言加故障策略命中的日誌來判斷當前下游接口是強依賴還是弱依賴。

4.2.3 難點


1、java Agent 兼容性


自動化測試平臺支持錄製回放模式,在迴歸測試時,可以對某些接口使用事先錄製好的流量進行mock,這種模式下會使用基於 jvm-sandbox 的錄製回放agent。chaosblade-exec-jvm 也是基於 jvm-sandbox 的agent,2個agent在一起使用會有一些兼容性問題需要解決。


  • 兩個agent不能同時生效?jvm-sandbox 在1.3.0版本增加 namespace 功能,也就是說可以同時啟用多個基於 jvm-sandbox 的 java agent,但是前提條件是 namespace 不同。chaosblade 中默認使用的 default namespace, 通過修改 chaosblade 的中的 namespce 來解決。


  • AOP同時切一個Libary的時候,如果mock先生效,故障注入就無效了?在錄製回放的agent增加了黑名單的功能來規避這個問題。


2、測試斷言和普通測試有區別


使用自動化測試平臺做迴歸測試的時候,更關注是是數據的完整性和準確性,但是在做故障演練的時候,通常是弱依賴已經有問題,除了常規的狀態碼判斷等,對返回結果的判斷更多是核心數據節點是否正確。為此在自動化測試平臺中單獨多了一套斷言配置來適配故障演練。


開源貢獻


去哪兒網混沌工程的實踐過程中主要使用的開源項目是 Chaosblade。在使用過程對 chaosblade、chaosblade-exec-jvm、chaosblade-operator 有不同程度的二次開發和Bug修復,部分修改已經提交給官方repo並merge。同時也和 Chaosblade 社區有過交流溝通,準備進行社區共建,為開源社區貢獻自己的一份力量。


未來規劃


當前我們的故障演練平臺已經支持80+次模擬機房斷電演練,同時也已經有500+次日常演練,涉及核心應用50+,機器4000+,業務線也形成了按季度週期演練及上線前驗證的良好文化氛圍。


我們下一步的主要目標就是自動化線上隨機演練,通過服務依賴鏈路確定最小化爆炸半徑,建立線上演練穩態斷言,最終實現全司核心頁面的全部鏈路定期隨機演練,同時也會發掘混沌工程在服務治理、穩定性建設中的使用場景,為公司業務穩定發展提供技術保障。


image


雲原生人才計劃 2.0由阿里雲、Linux 開源軟件學園、馬哥教育聯合推出,首期內容 “Kubernetes 技術圖譜”已在阿里雲開發者社區上線,歡迎大家公眾號後臺回覆“人才計劃”加入學習,閱讀“導讀”文檔即可瞭解福利領取方式。

Leave a Reply

Your email address will not be published. Required fields are marked *