下面的blade命令时阿里开源的ChaosBlade

 

分布式系统高可用原则

高可用的分布式系统一般需要满足以下原则：

• 失败重试
• 实例隔离
• 请求限流
• 服务降级
• 服务熔断
• 流量调度
• 开关&预案
• 监控告警
• 日志跟踪

混沌实验场景实践

我们以 A 调用 B，B 调用 C，A 同时也调用 D 举例，A1、A2 是 A 服务的多个实例，依次类推。

失败重试

实验场景：调用下游服务实例异常。

容错方案：会再次请求另外一个服务实例进行重试。

场景模拟：对 B1 注入异常故障，A 服务调用到 B1 时会出现调用失败。

预期方案：系统会将 A 服务的请求路由到 B2 进行重试。

blade 命令：blade c dubbo throwCustomException --exception <EXCEPTION CLASS> --service <SERVICE NAME> --provider

修复方案：添加失败检测和请求重试能力。

实例隔离

演练场景：多次调用下游一个服务实例超时。

容错方案：会隔离或者下线此服务实例，防止请求路由到此服务实例。

场景模拟：对 B1 注入延迟故障，A 服务调用到 B1 时，出现调用超时。

预期方案：系统会自动隔离或下线 B1 实例。

blade 命令：blade c dubbo delay --time <DELAY TIME> --service <SERVICE NAME> --provider

修复方案：添加服务质量检查，下线不可用的服务实例。

请求限流

演练场景：服务线程池满。

容错方案：会对入口流量进行限流，防止请求堆积，资源耗尽导致服务不可用。

场景模拟：对 A 注入线程池满故障。

预期方案：线程池满时，触发限流，新请求快速失败。

blade 命令：blade c dubbo threadpoolfull --consumer

修复方案：添加限流能力。

服务降级

演练场景：A 对 B 是强依赖，对 D 是弱依赖，A 调用 D 线程数多，争抢调用 B 服务的资源。

容错方案：对弱依赖 B 进行降级，减少资源分配。

场景模拟：对 A 注入调用 D 线程数满故障。

blade 命令：blade c dubbo threadpoolfull --service <D SERVICE NAME> --consumer

修复方案：梳理服务依赖，添加服务降级能力。

调用熔断

演练场景：下游服务不可用

容错方案：触发熔断，快速失败返回

场景模拟：对 B 服务所有的实例注入延迟超时故障。

blade 命令：blade c dubbo delay --time <DELAY TIME> --service <SERVICE NAME> --provider

修复方案：当下游服务不可用时，能立即熔断，快速失败。

流量调度

演练场景：上游高并发下，扩容下游服务，在服务实例初始化时，CPU 负载高，导致上游服务受影响

容错方案：当服务实例机器负载高时，自动切流到正常机器

场景模拟：对 B1 做 CPU 满载操作。

blade 命令：blade c cpu fullload

修复方案：添加系统、应用资源监控和流量调度能力。

系统预案

演练场景：杀掉服务实例。

容错方案：快速拉起或扩容

场景模拟：杀掉 B 大部分实例。

blade 命令： blade create process kill --process <PROCESS NAME>

修复方案：添加相关系统预案。

监控告警

注入任意故障，验证监控告警的有效性

日志跟踪

演练场景：修改应用中具体方法返回值。

容错方案：全链路调用日志记录。

场景模拟：修改 B 服务的一个业务方法的返回值。

blade 命令：blade c jvm return --classname <CLASS NAME> --methodname <METHOD NAME> --value <RETURN VALUE>

修复方案：添加全链路日志记录，便于排查和追溯问题。

 

来源：