以下文章来源于CSDN，作者为weixin_37753227。
前段时间，我司开始实行远程办公的模式。为了保障远程办公的安全，我们使用了JumpServer堡垒机作为远程办公的入口，并搭载了高可用环境。不过，由于我们搭载的节点是部署在国内某云的海外节点上，上个月海外光缆出现问题，导致全体同事无法办公。也因为这个事件，我们开始着手研究混沌工程的相关内容。
在研究的过程中，我们发现了另一个问题，即每次操作都需要手动写命令，不能再次自动执行，这耗费了我们大量的精力。好在我们看到JumpServer的交流群中在推他们团队的另一款产品——一站式开源持续测试平台MeterSphere。出于对JumpServer的好感，我们决定试一下这个平台。
了解后我们发现，MeterSphere接口自动化能力非常强大，任务定时执行还支持Cron表达式的图形化方式，可以让我这种对Cron不是那么懂的人都能用的飞起，感觉可以通过这个平台把混沌测试中的故障注入和接口测试结合起来。
关于ChaosBlade，用我个人理解的一句话解释就是：ChaosBlade是阿里开源的一个混沌注入的工具。所谓“混沌注入”可以理解为制造各种可能发生的故障（比如CPU、存储、网络等故障），来模拟线上环境可能会发生的一些问题，通过判断注入后系统是否还能保持稳定来分析和测试出系统的健壮性，从而进一步改善系统。
下面就跟大家简单介绍下，通过MeterSphere是如何调用ChaosBlade完成一个场景自动化测试的。
准备工作
1. 准备好被测系统
我们准备的是单节点JumpServer一台，这里因为只是实验，配置不做多要求，参考JumpServer的推荐配置即可。
2. 下载MeterSphere开源持续测试平台
准备一台服务器用于安装MeterSphere开源持续测试平台，具体操作和使用可参考官网文档。
3. 下载ChaosBlade
从ChaosBlade的GitHub地址上下载基于Linux环境的最新安装包，下载完成后传到被测服务器上并解压即可，无需编译。
比如解压到了服务器的/opt目录下，进入解压后的文件夹，可以看到以下内容：
├── bin
│ ├── chaos_burncpu
│ ├── chaos_burnio
│ ├── chaos_changedns
│ ├── chaos_delaynetwork
│ ├── chaos_dropnetwork
│ ├── chaos_filldisk
│ ├── chaos_killprocess
│ ├── chaos_lossnetwork
│ ├── jvm.spec.yaml
│ └── tools.jar
├── blade
└── lib
└── sandbox其中blade是可执行文件，即ChaosBlade工具的CLI，混沌实验执行的工具。
在这里先简单介绍一下如何使用这个工具：
我们用CPU满载（CPU使用率为100%）的演练场景举例（注意，在不清楚影响面的情况下，此命令切勿直接在韧性不够的生产系统机器上执行），执行以下命令实施实验：
./blade create cpu fullload
执行结果返回：
{"code":200,"success":true,"result":"7c1f7afc281482c8"}
通过top命令查看CPU使用率：
CPU usage: 93.79% user, 6.20% sys, 0.0% idle
此时命令已经生效，停止混沌实验，执行：
./blade destroy 7c1f7afc281482c8
返回以下结果，表示停止实验成功：
{"code":200,"success":true,"result":"command: cpu fullload --debug false --help false"}再去观察CPU情况，CPU负载已回到正常状态：
CPU usage: 6.36% user, 4.74% sys, 88.88% idle
一次CPU满载演练完成。
配置相关
我们知道MeterSphere可以做到创建场景接口自动化测试，测试的流程包括：
1. 确定一个可观察的稳定指标，如JumpServer的资产列表查询；
2. 在MeterSphere上定义一个查询稳定指标的接口用例：调用JumpServer的资产列表查询的接口；
可以看到，在没有外界干扰的情况下，能够正常调用JumpServer的接口查询资产列表。
3. 定义第二个接口用例：这个用例执行的目的在于引入混沌测试发起故障注入。（这里选择提高服务器CPU负载到100%。）
4. 定义第三个接口用例：这个用例的目的在于查询上一个混沌注入测试的注入状态。参数result为上一个混沌测试所返回响应的result值。
可以通过如下命令查看CPU使用率：
iostat -c 1 1000
可以看到，这次请求的响应时间比较长，说明服务器CPU负载的提升，对系统的稳定性有一定的影响，可能会影响后续接口的正常调用。
5. 定义第四个接口用例：这个用例目的在于验证混沌注入后是否影响对JumpServer接口正常的调用，以及观察与第一次调用接口时候的差别。
可以看到对比之前请求，响应时间延长了，原先的56ms变成了192ms。但是依然还是能够正常的请求接口获取数据，说明CPU满负载还不能破坏我们预先设定的稳定指标（即正常查询资产列表）。
6. 定义第五个接口用例：这个用例的目的在于销毁此次的混沌注入测试，把之前的CPU满负载混沌注入效果销毁，即使服务器恢复为初始状态。
7. 定义第六个测试用例：该用例与第三个用例可以复用，这个用例的目的在于查询上一个混沌注入测试的注入状态。参数result 为MeterSphere在此前设定好的result值。
可以看到，当成功销毁混沌实验后，服务器的CPU负载情况已经恢复到原始状态。
8. 定义第七个测试用例：该用例也是此次接口场景自动化测试的最后一个用例，就是再次调用JumpServer的查询资产列表，观察响应结果。
可以看到，这一次请求查询中间件列表的接口，响应时间为63ms，对比在混沌注入后的接近200ms，速度又变快了。说明服务器CPU的负载对于接口响应时延还是有一定影响，到此实验结束。
结果展示
上面只是列出了每个测试用例的截图，这里将完整的场景接口自动化做一个展示：
点击执行，观察结果：
从结果来看，7个步骤均执行完成，该流程场景测试成功。并且能看出，在混沌注入前后，对接口请求的效果是有一定的影响。明显在注入之后的系统响应时间变长，但是也可以看出CPU满负载依然不能破坏稳态，系统依然能稳定运行，JumpServer也能正常访问。
实验小结及补充
1. 安装ChaosBlade之后，后台启动Blade，会暴露出Web服务，上层可通过HTTP调用。请求格式是chaosblade?cmd=具体命令，例如执行CPU满载，则请求是chaosblade?cmd=create%20cpu%20fullload（%20 相当于Unicode的一个空格）。
命令：
start 启动 server 模式, 暴露 web 服务 stop 停止 server 模式, 关闭 web 服务
start命令参数：
-p, --port string 服务端口号，默认是 9526
案例：
# 启动 server 模式，服务端口是 8080
blade server start --port 8080
success, listening on 8080
# 触发 CPU 负载 50% 场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=create%20cpu%20load%20--cpu-percent%2050"
{"code":200,"success":true,"result":"e08a64a9af02c393"}
# 销毁实验场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=destroy%20e08a64a9af02c393"
# 停止 blade server
blade server stop
{"code":200,"success":true,"result":"pid is 12619"}2.相关链接
MeterSphere GitHub地址:
https://github.com/metersphere/metersphere
ChaosBlade 地址:
https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97
ChaosBlade Web服务HTTP接口地址：
https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/blade-server
MeterSphere官网地址：
————————————————
版权声明：本文为CSDN博主「weixin_37753227」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
https://blog.csdn.net/weixin_37753227/article/details/119568691