阿里ChaosBlade介绍与具体实践:
课堂笔记：
打不倒我的必使我强大。减少故障的最好方法就是让问题经常性的发生。在可控范围或环境下，通过不断重复失败过程，指线提升系统的稳定性和容错能力。
小结：提高分布式系统的容错能力，构建对系统的信心。
混沌工程的五个原则：
1、建立一个围绕稳定状态行为的假说
2、多样化真实世界的事件
3、在生产环境中运行实验
4、持续自动化运行实验
5、最小化爆炸半径
混沌工程的应用场景：
1、提升系统的容错能力，提高稳定性.
2、评估系统容灾红线 杀实列杀多少数量不会对业务造成影响。
3、验证云服务、云资源的动态扩容能力
4、验证监控、告警的有效性和问题处理流程是否完善
5、故障突袭，提升相关人员定位、恢复问题的能力、测试网络基础资源故障。
为什么要实施混沌工程？
核心收益价值：减少故障，降低业务的止损。提高系统的弹性和容错能力。
混沌实验模型：
混沌实验前要明确的问题：
你对什么做实验？目标
混沌实验实施的范围是是什么？控制最小爆炸半径是什么
实验生效的匹配条件有哪些？
最后一个action具体实施什么实验
你要对调用dubbo服务延迟 需要知服务接口、服务版本号等
答：举例:一个运行在10.0.0.1机器上的应用，调用com.example.HelloService@1.0.0dubbo 服务延迟3s
对照字面模型如下：
Target->实验靶点实验组件->指的是dubbo组件
Scope->实验范围：集群、机器等。->指的是10.0.0.1机器
Matcher->规则匹配器，实验匹配条件。->HelloService是指匹配器、及版本1.0.0。
Action->实验行为：具体执行的实验规则。->延迟
对应到ChaosBlade命令
blade create dubbo delay --time 3000 --consumer --service comexample.HelloService --version
工具特点&支持的实验
场景丰富度高.
使用简洁，易于理解
动态加载，无入侵
场景扩展方便
支持运行时长设置
CPU 满载
网络延迟、丢包、屏蔽
域名屏蔽
磁盘填充，磁盘I0 读写负载
杀进程
删容器、Pod
Java 应用或组件内延迟、抛异常、指定返回值
常用命令
blade create cpu fullload cpu满载
blade destroy 7c1f7afc281482c8 销毁这一次演练
blade status 7c1f7afc281482c8 状态
blade prepare jvm --process dubbo.consumer 挂载准备工作
blade status --type prepare
JVM的异常处理和错误处理机制是保证程序稳定性和可靠性的重要组成部分。异常处理通过使用try-catch语句捕获和处理异常，保证程序在出现异常时能够进行适当的处理，避免程序的中断选择合适的异常处理和错误处理方式，提高程序的健壮性和可维护性。
docker run -it registry.cn-hangzhou.aliyuncs.com/chaosblade/chaosblade-demo:latest
启动成功查看README.TXT 信息。
dubbo例子说明：
比如演练 Java 应用，则需要挂载 java agent。例如要演练的应用名是 business，则在目标主机上执行 blade p jvm --process business business。如果挂载成功，返回挂载的 uid，用于状态查询或者撤销挂载。
实验之前先观察curl http://localhost:8080/dubbo/hello?name=dubbo 查看是否成功。
返回值：Hello dubbo, response from provider: 172.17.0.3:20880
# 创建一个实验是调用sayHello service时延迟3秒，
blade create dubbo delay --time 3000 --service com.example.service.DemoService --methodname sayHello --consumer
返回值：{"code":200,"success":true,"result":"bd98f9dc3a6cfbbb"}
如果uid找不到可以使用命令：blade status --type c
刚才调用延迟3秒现在检查结果：
执行： curl http://localhost:8080/dubbo/hello?name=dubbo 返回：chaosblade-mock-TimeoutException,timeout=1000 超时异常，dubbo调用是1秒。
指定类方法抛自定义异常，命令可以简写为 blade c jvm tce
案例抛Exception
类名：com.example.controller.DubboController，业务代码如下：
private String sayHello(String name) throws BeansException {
demoService = (DemoService)SpringContextUtil.getBean("demoService");
StringBuilder result = new StringBuilder();
result.append(demoService.sayHello(name));
return result.toString();
}
blade c jvm throwCustomException --exception java.lang.Exception --classname com.example.controller.DubboController --methodname sayHello --process tomcat --effect-count 2
{"code":200,"success":true,"result":"3abbe6fe97d6bc75"}
做这些实验的用处是啥？具体价值
场景价值？
场景一:验证服务隔离能力
演练场景:
对 Dubbo 服务提供方 Provider A 注入延迟，验证问题实例隔离能力
演练目标:
下线 Provider A，所有请求都访问 Provider B，减少对上层服务的影响
容灾方案:
检测 PorivderA 服务质量，自动下线 Provider A 实例，Dubbo 将所有请求发送给 Provider B
2个Porivder 提供相同的服务。
Consumer->Readis注册中心->PorivderA OR PorivderB
验证Provider A 实例是否被隔离，杀掉或者下线。减少对上层服务的影响。
检测中心检测A服务质量，自动隔离or下线，Dubbo框架主动发往B,涉及负载均衡随机。
如果不杀掉进程会影响QPS.
隔离或者下线。
总结场景1：如果系统高可用的时候，等一个服务出现问题时。我们要对这个服务隔离或下线。这样才能确保正常的流量请求到正确的服务。但是我们当前测试的这个系统没有做到这一点。接下来对这个系统进行完善，之后再进行测试。来观察还是否出现问题这就是混沌工程。
场景二:验证熔断降级
演练场景:对 Dubbo 服务提供方 Provider A和 Provider B 注入延迟，模拟服务提供方访问慢的场景，验证上层服务熔断降级的能力
演练目标:
Consumer 访问服务超时，触发 Consumer 系统熔断，下游服务故障不会导致 Consumer 服务不可用。
容灾方案:
给Consumer 配置降级规则，当调用下游服务超过2s 时，触发熔断，不会继续等待下游的响应。
大白话描述：对2个Provider制造故障，造成下游服务不可用的情况。我们来看上游服务的影响，如果是高可用的话下游服务不可用，它会有降级的策略。如果持续调下游服务的话，那么它的响应时间、RT、QPS会大幅度降低。导致它的资源耗尽自身的服务就不可用。这就不符合高可用架构的规则。
目的：当下游不可用的时候，上游服务策略问题。否保证上游不受冲击。
