下面的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>
修复方案:添加全链路日志记录,便于排查和追溯问题。

 

来源:

借助混沌工程工具 ChaosBlade 构建高可用的分布式系统