開發與維運

面對不可避免的故障,我們造了一個“上帝視角”的控制檯

頭圖.png

作者 | 肖長軍(穹谷)
來源 | 阿里巴巴雲原生公眾號

混沌工程隨著雲原生的發展逐漸進入大家的視野,通過混沌工程可以很好地發現和解決在雲原生化過程中的高可用問題。阿里巴巴在 2019 年開源了底層的混沌工程工具 - chaosblade,今年年初再次開源混沌工程控制檯 chaosblade-box,ChaosBlade 品牌進一步升級。本文主要圍繞雲原生面臨的高可用挑戰和混沌工程機遇,詳細介紹開源控制檯的設計、特性和實踐和未來規劃,旨在幫助企業更好的瞭解控制檯並通過其來實現混沌工程落地,解決雲原生系統下高可用問題。

1.png

去年年底 AWS 和 Google 都出現了比較嚴重的服務故障:AWS 故障是由於處理數據流服務 kinesis 出現問題,導致很多雲服務不可用;Google 故障是由於登錄服務的擴容配額問題導致多服務不可用。從中可以發現,他們都存在因服務依賴不合理,導致一個服務故障影響多個服務不可用,缺少應急預案,整個故障恢復時間比較長,監控告警系統不完善等問題,Google 故障發生幾十分鐘後才感知故障的發生,AWS 的 CloudWatch 處於不可用的狀態。故障不可避免,所有的一切時時刻刻存在著失敗的風險。

2.png

尤其隨著敏捷開發、DevOps、微服務、雲原生架構和治理的出現,應用的交付能力大大提升,但系統的複雜度也日益增加,在業務快速迭代的同時,如何保障業務持續的高可用性和穩定性面臨著很大的挑戰。混沌工程通過主動注入故障的方式,提前發現系統的薄弱點,推進架構的改進,最終實現業務韌性。

3.png

打不倒我的必使我強大,建設韌性架構是混沌工程的目標。韌性架構包含兩部分,一部分是韌性系統,比如具備冗餘性、擴展性、降級熔斷、故障隔離等,避免級聯故障,構建容災容錯的韌性系統。另一部分是韌性組織,包含高效交付、故障預案、應急響應等組織協同建設。高度韌性的系統也會出現預期之外的故障,所以韌性的組織能彌補韌性系統缺失的部分,通過混沌工程構建極致的韌性架構。

4.png

常見的雲原生高可用架構架構基本上是基於多可用區,或者是跨地域級的容災架構,業務應用採用微服務架構下集群部署,中間件具備容錯容災能力等等。從底層設施到上層業務,都存在潛在的故障風險,比如機房斷網、整個可用區不可用、集群宕機、中間件節點 crash 等。從可用區到集群、主機,再到細粒度的請求,故障影響的爆炸半徑逐漸減小,這也是混沌工程原則中非常重要的一點 -- 控制爆炸半徑。控制爆炸半徑的方式一般有兩種:一是環境隔離,通過隔離實驗的機房、集群等來控制影響面;二是基於實驗工具或平臺自身的場景控制能力,比如 chaosblade 實驗工具,通過實驗參數來控制實驗粒度,比如微服務調用延遲,可以控制到單個服務接口、版本,甚至一次請求。下面我們來介紹一下 chaosblade 混沌實驗工具。

5.png

Chaosblade 是一款遵循混沌實驗模型的混沌實驗執行工具,具有場景豐富度高、簡單易用等特點,而且擴展場景也特別方便,開源不久便被加入到 CNCF Landspace 中,成為主流的一款混沌工具。chaosblade 是個直接下載解壓即可使用的工具,不需要安裝,它支持的調用方式包含 CLI 方式,直接執行 blade 命令,這裡舉個做網絡屏蔽的例子:我們添加 -h 參數就可以看到非常完善的命令提示,比如要一個 9520 端口調用做網絡丟包,它的演練目標是 network;它的 action 是丟包;它的 matcher 就是調用遠程的一個服務端口 9520。執行成功後會返回實驗結果,每一個實驗場景我們都會作為一個對象,它會返回一個實驗對象的 UID,此 UID 用於後續的實驗管理,比如銷燬、查詢實驗都是通過此 UID 來做的。要銷燬實驗,也就是恢復實驗,直接執行 blade destroy 命令就可以。

6.png

Chaosblade 支持多平臺、多語言環境,包含 Linux、Kubernetes、Docker 平臺,以及 Java、NodeJS、C++、Golang 語言應用。共涉及 200 多個場景、3000 多個參數,為用戶提供豐富的場景和實驗參數控制。使用 blade -h 命令可以查看詳細的使用文檔,包含案例和場景、參數介紹。下面我們重點介紹一下 chaosblade 對應用服務場景的支持。

7.png

Chaosblade 支持 Java、C++、Golang、NodeJS 語言應用,其中對 Java 應用的支持能力更豐富,包含 OOM、線程池滿、指定線程數、CPU 負載、codecache 滿等 JVM 本身的場景,還支持很多常用組件,比如 Druid、Dubbo、Elasticsearch、HBase、HttpClient、Redis、Kafka、Lettuce、MongoDB、MySQL、PostgreSQL、RabbitMQ、RocketMQ、Servlet、Tars、gRPC 等。Java 場景更強大的一個功能是可用指定任意類和方法注入異常、延遲、篡改返回,甚至可以通過自己編寫 Groovy 或 Java 腳本,實現更加複雜的實驗場景來滿足自身業務實驗需求。還支持鏈路標識識別、請求數限制等能力。Golang 場景是通過編譯時在任意代碼行注入埋點邏輯來實現,目前支持修改變量值、修改參數值、修改返回值、異常、延遲、內存溢出和 Panic 場景。現在,已登記的試用或在使用的企業已經 40 家,其中包含一些深度合作共建的企業用戶。下面我們舉個例子來說明 chaosblade 故障注入的執行流程。

8.png

以雲原生 Dubbo 應用調用下游 PetQueryService 服務延遲三秒故障場景為例,我們可以通過 chaosblade 自帶的 blade 工具或 kubectl 以及通過編碼的方式來執行。此處列舉了使用 kubectl 和自身的 blade 工具執行。先看使用 kubectl 執行,通過配置 ChaosBlade 類型的 YAML 文件,使用 kubectl apply 命令來創建實驗,Kubernetes 會創建一條 chaosblade 資源,後續通過 kubectl delete 命令刪除此諮詢即可恢復實驗。創建好 chaosblade 資源後,chaosblade operator 監聽 chaosblade 資源創建,查詢目標容器,按需透傳場景相關的實驗工具,調用 blade 工具在容器內執行實驗。使用 blade 執行,命令如上圖,指定 K8s 下的 dubbo 應用注入延遲故障,通過 process 參數指定應用名、time 參數指定延遲時間、service 參數指定受影響的服務接口、names 參數和 container-names 分別指定 Pod 和 Container 名稱,如果不清楚參數可以添加 -h 來查看命令幫助。

通過以上案例可以看出 chaosblade 工具使用簡單,而且支持豐富的實驗場景,我們在此工具的基礎上做了 ChaosBlade 品牌升級。

9.png

我們開源了 chaosblade-box 混沌工程控制檯,可實現混沌實驗平臺化操作,而且支持更多混沌工程實驗工具的託管,比如 litmuschaos 等。品牌升級後,我們更進一步地解決了用戶落地混沌工程的困難度,讓用戶將更多的精力放到推進系統韌性提升上,旨在通過混沌工程幫助企業解決系統雲原生化過程中高可用問題。

10.png

Chaosblade-box 是一個面向多集群、多環境、多語言的雲原生混沌工程平臺。關鍵功能如下所示:

  • 實現了實驗工具自動化部署,無需用戶登錄到每臺機器部署實驗工具,簡化用戶部署成本。
  • 支持實驗工具託管,現在已支持 litmuschaos ,後續會支持更多優秀的實驗工具來滿足各種實驗場景需求。
  • 通過提供統一的混沌實驗用戶界面,屏蔽底層故障注入方式,讓用戶在同一個平臺上實現不同工具的實驗。
  • 支持實驗目標自動獲取、實驗場景管理等等。
  • 支持多個實驗維度,比如主機、Kubernetes、應用,其中 Kubernetes 又包含 Container、Pod、Node 實驗維度。
  • 後續會更進一步支持混沌工程閉環,實現穩態定義、實驗執行、穩態評估等,協助用戶構建高可用的雲原生系統。

下面通過頁面截圖來了解一下 chaosblade-box 平臺能力。

11.png

12.png

13.png

14.png

15.png

16.png

17.png

通過上述圖片可以看出 chaosblade-box 平臺整體功能,在託管更多工具場景的基礎上,標準化實驗場景和實驗管控界面,簡化用戶操作,降低使用門檻,提供詳細的白屏化日誌,便於問題跟蹤和排查。接下來我們看下平臺技術架構圖。

18.png

通過控制檯頁面可實現 chaosblade、litmus 等已託管的工具部署,按照社區的建立的混沌實驗模型統一實驗場景,根據主機、Kubernetes、應用來劃分目標資源,通過目標管理器來控制,在實驗創建頁面,可以實現白屏化的目標資源選擇。平臺通過調用混沌實驗執行來執行不同工具的實驗場景,配合接入 prometheus 監控,可以觀察實驗 metric 指標,後續會提供豐富的實驗報告。
_
_Chaosblade-box 的部署也非常簡單,具體可以查看:https://github.com/chaosblade-io/chaosblade-box/releases_。

下面我們通過一個殺 Pod 實驗場景來介紹平臺的使用。

19.png

首先是部署 chaosblade-box,部署完成後,在實驗列表頁面創建實驗,選擇 Kubernetes Pod 實驗維度,實驗創建共分為四步,前兩步資源選擇和場景選擇是必填項,後兩步監控接入和實驗名稱是非必填項。在 Pods 列表中選擇多個目標 Pods,然後選擇殺 Pods 實驗場景,對接 Prometheus Pod 監控,完成實驗創建。在實驗詳情頁面可以點擊執行實驗進入實驗任務詳情頁面,查看實驗詳細信息。

20.png

Chaosblade-box 後續規劃重點在託管更多的實驗工具,實現更多工具自動化部署,同時支持更多的語言應用,添加更加複雜的調度策略和流程編排,生成實驗報告,實驗報告分三個階段,一是實驗基礎報告,包含實驗和監控的基本信息,二是實驗缺陷報告,包含實驗中發現的問題,三是實驗高可用建設報告,根據實驗中發現的問題提出解決方案建議。

具體的 Roadmap 可詳見:https://github.com/chaosblade-io/chaosblade-box/wiki/Roadmap

ChaosBlade 品牌升級後,項目才剛剛開始,還有很多不完善的地方,歡迎大家下載使用,參與到項目建設中,也可登記企業使用情況到 issue 中,我們線下交流,登記地址:_https://github.com/chaosblade-io/chaosblade/issues/32_。

  • chaosblade 項目地址

https://github.com/chaosblade-io/chaosblade

  • chaosblade-box 項目地址

https://github.com/chaosblade-io/chaosblade-box

Leave a Reply

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