去哪儿网基于ChaosBlade的混沌工程实践
共 3287字,需浏览 7分钟
·
2021-08-25 16:36
1
1
前言
2
2
选型
当时基础资源以 KVM 为主,同时也在探索容器化,所以两个平台都需要支持。
公司内部主要的技术栈为 Java。
3
3
架构
服务治理,Portal(提供应用画像,CICD的平台)提供了应用的依赖关系,应用的属性,运行时资源等信息,通过混沌工程UI可以创建出故障演练(故障演练包含了应用信息,应用资源,待注入故障等);
混沌工程控制台(Chaos控制台),提供了多个应用多个故障的任务流程编排,故障演练流程的控制的功能;
Saltstack,chaosblade-operator 提供了 chaosblade 的安装和卸载能力;
应用的资源分为 KVM 和 K8S 承载的容器,故障演练编排系统通过 Restful API 和 chaosblade 启动的 HTTP 服务进行通信,来进行故障的注入和恢复。
自动化测试平台主要提供演练时线上 case 的回归能力,以及用来做强弱依赖的标记断言;
演练开始时,Chaos控制台会监听相关应用的核心指标告警,如果有告警信息会通知给相关负责人并终止和恢复演练,这样可以及时止损。
4
4
系统演进
4.1 故障演练
4.1.1 演练流程
4.1.2 难点
开源故障策略不足
容器化改造
方案 | 说明 | 优势 | 劣势 |
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的安装和卸载 策略的注入和恢复 控制端的改造成本
4.2 强弱依赖自动闭环
4.2.1 背景
应用间依赖信息展示,依赖关系标注 根据依赖信息,反填故障策略参数
4.2.2 方案
4.2.3 难点
两个agent不能同时生效?jvm-sandbox 在1.3.0版本增加 namespace 功能,也就是说可以同时启用多个基于 jvm-sandbox 的 java agent,但是前提条件是 namespace 不同。chaosblade 中默认使用的 default namespace, 通过修改 chaosblade 的中的 namespce 来解决。 AOP同时切一个Libary的时候,如果mock先生效,故障注入就无效了?在录制回放的agent增加了黑名单的功能来规避这个问题。
5
5
开源贡献
6
6