这篇文章是根据我在上家公司搭建混搭工程以及完成一个演练的过程的分享，我将会从调研选型->环境搭建->开始第一个演练这三个节点和大家分享。（大家可以先看下目录）
写这篇文章的背景也是因为之前想搭建的时候发现网上的资料也确实比较少，尽管这几年混沌工程的概念已经比较火，但是相关的资料也是比较偏理论性的报告和解读，各种大会的 PPT 都是在展示我们做哪些，我们发现了哪些问题等等，其实这个也是极其依赖公司的基建（基础能力建设），也是因为这个原因导致我在实施过程中比较艰难
带来的价值，主要分为 3 个方面，对 QA：能够提早暴露线上问题，降低故障复发率；对架构师：能够演练故障发生时，系统架构的容错能力；对 RD：能够验证 RD 的故障 SOP(标准化操作) 的可用性，以及故障发生后的问题修复的流程与效率
另外本人技术也比较菜，如果有错误还请帮忙指出，感谢
调研这块我就不细说了，直接看结果吧，调研方向主要是分两块，内部系统的架构与混沌工程的软件选择，软件前期我选择的是阿里开源的Chaos Blade（混沌之刃），这个也是目前国内一些厂商用的比较多的，后来开始用了Chaos Mesh，至于为什么后来会选择这个，我后面回答。
ChaosBlade 中文名混沌之刃，是一款混沌实验实施工具，支持丰富的实验场景，比如应用、容器、基础资源等。工具使用简单，扩展方便，通过对演练平台底层的故障注入能力进行抽象，定义了一套故障模型。配合用户友好的 CLI 工具进行开源，帮助云原生用户进行混沌工程测试
* 列举了部分功能
通过架构我们也可以看到，这套设计将监控、报告、以及部署都完善了，是一套比较完整的项目
2.2.1、ChaosBlade-Box 的部署
tips：我这边是在网上找了相关的部署文档，让运维帮忙执行，大家可以参考官网的安装方式
大概步骤就是：1、wget 下载包；2、安装 MySQL 数据库（修改账号密码这些）；3、创建数据库（参照文档）；4、nohup 命令启动服务（后台保持运行）5、验证运行状态，这里会有 2 个 pod，一个是 box 服务本身一个是 mysql 的 pod，例如![官方示意图]
2.2.2、部署效果如下
![实验过程的截图]
2.2.3、操作手册
见官方
2.2.4、我最终为什么放弃了 ChaosBlade？
因为我们这边大概有 900 多个服务，pod 加载了 3000 多个，因为没有分配很好的服务器部署 box，基本上执行实验的时候，会直接卡死，实验进行不下去
2.2.1、功能介绍
chaos mesh 也支持可视化的 web 页面进行操作，减少了很大的操作成本，并且有着不同的角色权限控制
Chaos Mesh 简介 | Chaos Mesh
![官方图]
2.2.2、部署
这边是直接将官方文档给到运维，直接使用 helm 就安装好了，不得不说，chaos mesh 的官方文档是比较全面
使用 Helm 安装 Chaos Mesh | Chaos Mesh
2.2.3 、实验
例如 JVM 的故障，支持的异常类型比较多 ，例如常见的异常抛出、jvm 的 gc、修改 return 等等
![实验过程图]
tip：这个端口如果没有和其他服务冲突是不用改的
| 参数 | 类型 | 说明 | 是否必填 |
|---|---|---|---|
| class | string 类型 | Java 类的名称 | 是 |
| method | string 类型 | 方法名称 | 是 |
| exception | string 类型 | 抛出的自定义异常，例如：'java.io.IOException("BOOM")' | 是 |
| port | int 类型 | 附加到 Java 进程 agent 的端口号，通过该端口号将故障注入到 Java 进程 | 否 |
我们使用了单独的泳道环境，部署了全链路的服务，将需要注入故障的服务安装工具，
可以直接使用 wget 或 tar 下载
wget https://github.com/chaosblade-io/chaosblade/releases/download/v1.7.2/chaosblade-1.7.2-linux-amd64.tar.gz
tar -xvf chaosblade-1.7.2-linux-amd64.tar.gz && cd chaosblade-1.7.2/
如不挂着代理，无法进行 Java 相关的故障实验，jvm 的故障注入底层用的也是 jvm-sandbox
./blade v
出行版本信息
./blade h
看帮助信息，这里列举了全部的功能
一下是链路依赖流畅图
![image.png]
举个🌰：我要模拟服务 B 的依赖服务 C 故障
找到接口类的实现类 (一般在 impl 目录下) 包路径，将 package 后面复制，找到需要注入故障的方法
classname=com.xxx.xxx.类名 --methodname=方法名
触发一个包含这个服务的链路的业务操作，就可以看到对应的效果，看下是否符合预期，例如我们这可能给用户展示了 rpc timeout，这个其实是不可行，对业务来说，没有做好对应的降级处理，另外对用户的文案不够友好，另一方面需要验证下，我们系统的告警是否正常，我们能否第一时间感知到故障的发生
例如：
写这篇文章的时候，时间已经过的比较久了，后续记起来会慢慢补充
6.1 执行 chaosBlade 的网络故障实验的时候，我们的服务镜像并没有 tc 工具，不知道 tc 的可以搜下，是 Linux 的一个网络流量控制的工具，这个问题比较简单，让运维重新打个镜像文件把 tc 工具带入即可
6.2 销毁实验可能失败，这个按照官方解决即可
6.3 chaosblade 的时候，我同事执行好像部分命令没有生效，我后续补充，也不知道是不是操作问题
6.4 使用 chaosmesh 的内存溢出时，将公司整个集群打挂了，针对这个事件还进行复盘了😭
7.1 ChaosBlade-Box 用户手册Chaosblade-Box 用户手册
7.2 官方实践 (基于 Kubernetes)chaosblade
7.3 chaosblade 官方文档 ChaosBlade · Help
