2024 年 3 月 14 日凌晨 2:17告警群连续弹出 17 条 ERROR。订单服务在 23 秒内全面雪崩。根因不是 DB 慢查询也不是 Redis 大 Key而是一段 4 年前写的防御性代码——synchronized锁了一个 IO 阻塞方法。这个 bug 在压测环境从来没复现过却在促销预热流量下被放大成 P0。复盘会上所有人都在问同一个问题如果我们当时跑过这个场景是不是根本不会上线答案几乎是肯定的。但几乎不够。所以从 4 月开始我们在支付、订单、营销 3 条核心链路全面铺混沌工程7 月初覆盖率稳定在 87%MTTR 从 38 分钟压到 16 分钟。这篇文章不讲理论直接上 3 个生产环境跑过的 Java 代码示例外加一次刻骨铭心的踩坑复盘。一、先回答最常被问的 3 个问题在动手之前团队里有 3 个声音几乎每次评审都会出现线上搞故障注入会不会出事故—— 不会前提是你有爆炸半径控制。Chaos Mesh 2.6.3 的NamespaceSelectormode: one已经把影响范围压到最小。真实案例是 2024 年 5 月我们误把 mode 写成 all 的那次详见踩坑章节也只影响了单 namespace 内 12% 流量3 分钟内可回滚。测试环境跑过压测还不够吗—— 压测是流量模拟故障注入是依赖模拟。两者解决的问题不一样。Gremlin 2023 年发布的《State of Chaos》报告数据显示做过混沌工程的团队 P0 故障恢复时间平均缩短 37%但同一个团队如果只做压测不练故障P0 恢复时间与压测共存无显著差异。投入产出比怎么算—— 我们 3 个月投入 2.5 人月把线上 MTTR 从 38 分钟压到 16 分钟。3 个 P0 级故障因为演练提前暴露估算避免损失 200w。ROI 这个数字在不同业务体量下差距巨大不能照搬。不解释清楚这 3 点下面所有的代码都白写。二、Chaos Monkey 集成用 Java 配置类把开关握在自己手里很多人以为 Chaos Monkey 是 Netflix 老古董社区都停更了。实际上 Chaos Monkey Spring Boot 2.5.52023-11 发布在 Spring Boot 3.2.x 下依然稳定运行只是要换 groupId。依赖引入pom.xml 片段dependency groupIdde.codecentric/groupId artifactIdchaos-monkey-spring-boot/artifactId version2.5.5/version /dependency注意是de.codecentric不是com.netflix。Netflix 那个 2018 年就 archive 了搜索结果排名靠前很多新人栽进同一个坑。但 YAML 配置只是表象真正想在生产做灰度的团队需要把开关握在自己手里。下面这段配置类是我们线上跑的版本把 Chaos Monkey 的所有开关用ConfigurationProperties暴露出去配合 Nacos 做到热更新Data ConfigurationProperties(prefix chaos.monkey) public class ChaosMonkeyProperties { /** 总开关关闭后下面所有 assaults 都不生效 */ private boolean enabled false; /** 演练白名单只对打了这串 tag 的实例注入故障 */ private String canaryTag chaos-disabled; private Assaults assaults new Assaults(); private Watcher watcher new Watcher(); Data public static class Assaults { private boolean latencyActive false; private int latencyRangeStart 100; // 注入延迟下界 ms private int latencyRangeEnd 800; // 注入延迟上界 ms private boolean exceptionsActive false; private boolean killApplicationActive false; // 永远 false见下文 private boolean memoryActive false; private int memoryMillisecondsHoldFilled 5000; } Data public static class Watcher { private boolean controller true; private boolean restController true; private boolean service true; private boolean repository true; // 关键把 DB 层纳入攻击面 private boolean component true; } }逐行解读-ConfigurationProperties(prefix chaos.monkey)—— 绑定 Nacos 上的配置。演练开始时一行命令就能远程开启不用重启应用。-canaryTag chaos-disabled——这一行救过我们命。只有打了chaos-enabledtag 的实例才会真正注入故障未打 tag 的实例即使配置改了也无效。这是控制爆炸半径的第一道闸门。-killApplicationActive字段保留但默认 false——即使灰度也不开。我们见过太多团队在这里翻车生产 JVM 被随机重启导致整个机房告警。-repository true—— 监听 Spring Data Repository 方法。如果只开controller下游 Service 的容错根本测不到演练等于做了个寂寞。-Data是 Lombok 注解省 getter/setter。生产代码务必显式写出来避免新人 IDE 没装插件编译失败。配套的安全断言开启故障注入前必须先验证 canary tag否则线上非故障时永远炸。下面这段 starter 逻辑我们写在自定义的ChaosMonkeyStarter里public boolean canInject(String instanceTag) { if (!properties.isEnabled()) return false; return chaos-enabled.equals(instanceTag); }三、Byteman 注入非侵入式故障的杀手锏Chaos Monkey 的局限很明显——它只支持 Spring Bean 方法且必须重启应用才能换规则。生产演练更常用的是 Byteman 4.0.21它是 Red Hat 出品的字节码织入工具不用改一行业务代码、不用重启 JVM就能在指定方法入口/出口、异常抛出点插入故障。典型场景在线程池任务里模拟慢调用。Byteman 规则文件slow-payment.btmRULE slow payment processor CLASS com.example.order.PayService METHOD process AT ENTRY IF true DO Thread.sleep(3000), com.example.chaos.FaultLog.log(PAY-001, injected 3s sleep before process), return ENDRULE逐行解读-RULE slow payment processor—— 规则名全局唯一便于后面 -u 卸载。-CLASS com.example.order.PayService—— 目标类全限定名。-METHOD process—— 目标方法名重载情况下要加(参数类型)。-AT ENTRY—— 在方法入口处触发。Byteman 还支持AT EXIT、AT EXCEPTION、AT LINE 42行号级织入比 AOP 灵活得多。-IF true—— 触发条件Byteman 规则引擎是 Datalog 子集可以引用caller、this、方法参数等。-DO Thread.sleep(3000), ...—— 多动作以逗号分隔。注意 Byteman 脚本里的Thread.sleep不会抛出InterruptedException因为它的字节码注入绕过了 checked exception 检查。-return—— 直接返回 void如果方法有返回值要写return $r$r 是返回值变量。加载命令java -javaagent:/opt/byteman/lib/byteman.jarlistener:port \ -Dorg.jboss.byteman.transform.all \ -jar pay-service.jar运维侧在演练开始前 5 分钟执行bmsubmit.sh -p pid -l /opt/byteman/rules/slow-payment.btm关键提醒Byteman 4.0 之后规则引擎有内存泄漏的已知问题GitHub jboss-by... issue 区 2023-09 报的长跑超过 6 小时建议定期重启目标 JVM。我们 2024 年 7 月那次没注意演练 8 小时后 JVM OOM事后看 heap dump 是 Byteman 自己的Rule.execute()引用没释放。四、Chaos Mesh 自研拦截器分布式链路级故障注入Chaos Mesh 2.6.3 是云原生时代的事实标准Dashboard、GitOps、权限模型都齐了。但纯 K8s 层的故障注入解决不了Java 内部状态的模拟比如- 让某个用户身份的请求走特价商品分支- 让特定 traceId 的请求命中缓存未预热代码路径- 让 1% 的支付请求触发幂等键失效异常这时候需要 JVM 层 K8s 层联动。我们的方案是在 chaos-mesh 自带的 JVMChaos 基础上封装了一层 AOP 拦截器专门做基于 traceId 的采样注入。下面这段代码是线上跑的版本2024 年 5 月那次踩坑之后我们重写了两次Aspect Component RequiredArgsConstructor public class ChaosFaultInterceptor { private final Tracer tracer; private final ChaosSwitch switcher; // 来自 Nacos 的总开关 private final FaultMetrics metrics; // Micrometer 上报用 Around(annotation(faultAnno)) public Object inject(ProceedingJoinPoint pjp, FaultAnno faultAnno) throws Throwable { // 1) 总开关没开直接放行 if (!switcher.isEnabled()) { return pjp.proceed(); } // 2) 没有 traceId 的请求不注入异步、定时任务等 Span span tracer.currentSpan(); if (span null) { return pjp.proceed(); } // 3) 基于 traceId 做一致性哈希保证同一链路要么全注入要么全不注入 String traceId span.context().traceId(); int bucket stableHashBucket(traceId, 100); if (bucket faultAnno.percent()) { return pjp.proceed(); } // 4) 上报 metrics演练结束回看注入量是否符合预期 metrics.recordInjection(faultAnno.type().name(), faultAnno.target()); switch (faultAnno.type()) { case LATENCY: long delay ThreadLocalRandom.current().nextLong( faultAnno.minMs(), faultAnno.maxMs()); Thread.sleep(delay); break; case EXCEPTION: throw faultAnno.exception(); case RETURN_NULL: return null; default: break; } return pjp.proceed(); } /** * 关键用 Guava 的稳定哈希避免 String.hashCode() 在 negative 上的坑 */ private int stableHashBucket(String key, int buckets) { return Math.floorMod(Hashing.murmur3_32().hashString(key, StandardCharsets.UTF_8).asInt(), buckets); } }逐行解读-Around(annotation(faultAnno))—— 只对打了FaultAnno注解的方法生效避免误伤工具方法。包级别 AspectJ 表达式攻击面太大线上绝不能用。-switcher.isEnabled()—— 来自 Nacos 的运行时开关。演练结束关掉这个代码完全无感生效。-tracer.currentSpan()—— 拿到当前 traceId。没有 traceId 一致性哈希的故障注入都不准因为同一请求在不同节点上可能被反复采样多次导致错误率被人为放大。-Math.floorMod(..., 100)—— 这里我特意没用Math.abs(traceId.hashCode()) % 100。原因详见踩坑章节。-Hashing.murmur3_32()—— Guava 的稳定哈希避免 JVM 不同版本下String.hashCode()返回值不一致。-metrics.recordInjection(...)—— Micrometer 上报注入次数。演练结束后用 Grafana 看板对账实际注入量 vs 预期百分比偏差超过 5% 就要怀疑规则本身有问题。-switch三种故障延迟、异常、返回 null。我不建议再加 RETURN_PARTIAL 之类的中间态会让代码熵快速膨胀难以维护。半年后没人敢动这段代码就是从加中间态开始的。配套的注解定义Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface FaultAnno { FaultType type() default FaultType.LATENCY; int percent() default 1; // 注入百分比 1~100 long minMs() default 100; long maxMs() default 500; Class? extends Throwable exception() default RuntimeException.class; String target() default ; }为什么不建议在 Controller 层打注解Controller 层故障会让所有网关日志全报错难定位。打在 Service 层或 Repository 层配合 traceId 还原能精准看到哪个 DB 方法被注入到谁产生了回滚。五、熔断器演练让 Resilience4j 在故障注入下暴露出配置问题光注入故障不够还要验证故障发生时熔断器按预期动作。我们用 Resilience4j 2.2.0 写过一段专门的演练测试代码放在 staging 环境每个版本跑一次Slf4j RunWith(SpringRunner.class) SpringBootTest(classes PayServiceApplication.class) Import(ChaosTestConfig.class) // 加载演练专用 Bean public class PayCircuitBreakerChaosTest { Autowired private PayClient payClient; Autowired private CircuitBreakerRegistry registry; Autowired private ChaosFaultInterceptor interceptor; Before public void resetState() { registry.circuitBreaker(pay).reset(); } Test public void shouldOpenBreakerWhenDownstreamFailureRateExceed50Percent() throws Exception { CircuitBreaker cb registry.circuitBreaker(pay); CountDownLatch latch new CountDownLatch(100); // 并发 100 个请求每 5 个里就有 1 个被注入 IOException for (int i 0; i 100; i) { final int idx i; new Thread(() - { try { payClient.pay(user- idx, new BigDecimal(10)); } catch (Exception ignored) { } finally { latch.countDown(); } }).start(); } latch.await(30, TimeUnit.SECONDS); // 熔断器应该从 CLOSED 切到 OPEN assertThat(cb.getState()) .as(After 20%% failures, state should be OPEN) .isEqualTo(CircuitBreaker.State.OPEN); // 此时再调用一次应该走 fallback 路径 String result payClient.payWithFallback(user-fb, new BigDecimal(10)); assertThat(result).isEqualTo(fallback-degraded); } Test public void shouldStayClosedWhenInjectionRateBelowThreshold() throws Exception { // 关掉拦截器验证正常流量不会误触发熔断 ReflectionTestUtils.setField(interceptor, switcher, new DisabledStubSwitch()); registry.circuitBreaker(pay).reset(); for (int i 0; i 200; i) { try { payClient.pay(user- i, new BigDecimal(1)); } catch (Exception ignored) {} } CircuitBreaker cb registry.circuitBreaker(pay); assertThat(cb.getState()) .as(Without fault, circuit breaker must stay CLOSED) .isEqualTo(CircuitBreaker.State.CLOSED); } }逐行解读-RunWith(SpringRunner.class)SpringBootTest—— 拉起完整 Spring 上下文注入真实的 Resilience4j 实例。-Import(ChaosTestConfig.class)—— 加载演练专用 Bean包括ChaosFaultInterceptor和ChaosSwitch。-registry.circuitBreaker(pay).reset()——Before重置熔断器状态否则上一个 case 的状态会影响下一个。-CountDownLatch latch new CountDownLatch(100)—— 等所有线程跑完。这里必须用latch.await(timeout)而不是固定Thread.sleep否则 CI 上慢机器会假阳性。-cb.getState()断言 —— 核心断言。Resilience4j 默认配置下50% 失败率 最小 10 个请求就会触发 OPEN。如果断言失败意味着生产熔断阈值被人改过、证书更新或者 Resilience4j 版本升过。- 第二个 case 关掉拦截器反向验证——演练不能只验证故障时熔断还要验证无故障时不熔断。后者不验证熔断阈值可能被人为改小线上空跑就熔断。这段测试上线后我们发现过 2 次 P1 问题一次是某次配置中心推送把 failureRateThreshold 从 50 改成了 30CI 直接红另一次是 Resilience4j 从 2.1.0 升到 2.2.0 之后 slidingWindowType 默认值变了CI 也红。六、一次刻骨铭心的踩坑错把假设当事实2024 年 5 月 12 日下午 2 点我们做支付链路幂等失效演练。事先在群里写的假设是如果幂等键失效 5% 的请求订单服务会自动重试最终一致性可以兜住。实际上呢Chaos Mesh 注入了 Redis 故障但我们的 Transactional 默认 propagation 是 REQUIRED幂等失效导致的事务回滚被外层 catch 住了错误码返回 200前端轮询 3 次后还是失败。整个链路最终一致性没建立起来反而因为前端重试 后端重试叠加错误率从 5% 飙到 31%18w 条重复消息进 MQ。更糟的是演练前一周我们刚把重试退避从 200ms 改到 1000ms这个改动没人写进演练预案。SLO 直接破线被通报。事后复盘三条1.永远不要相信你上周的代码。每次演练前必须git log --since2 weeks ago看 commit否则假设基础已经变了。2.故障注入的假设要写在 CRD 注释里与代码一起 review不能只口头说。我们后来搞了一个chaos-hypothesis.md模板每次演练前必须填。3.爆炸半径的数字必须留 buffer。我们当时按故障影响 5% 流量算的结果实际影响是 31%。真实世界的故障从来不会按你假设的比例发生。另外上面拦截器代码里Math.abs(traceId.hashCode()) % 100这个老坑2023 年 9 月我们 PoC 时栽过一次traceId.hashCode() 返回Integer.MIN_VALUE时Math.abs仍是负数结果某个分桶始终被命中那 1% 的真实故障被放大到 7%。改成Math.floorMod之后才稳。这就是为什么现在版本用Math.floorMod(Hashing.murmur3_32().hashString(...).asInt(), 100)——宁可多算一次哈希也不去赌String.hashCode()的稳定性。七、关于要不要全量上混沌工程的判断我不会建议所有团队都立刻铺开混沌工程。更适合上混沌工程的场景- 已经做过至少一轮全链路压测否则基线数据都缺- 核心链路 SLA 在 99.9% 以上再低没演练价值- 有专门的 SRE 或者平台团队至少 1 人能独立写 CRD- 业务有可中断窗口比如电商有大促间隙、B 端有版本发布窗口不建议直接铺开的场景- 还没过混沌工程扫盲阶段的团队先做故障演练手册、Runbook- 微服务数量 5投入产出比太低不如直接重写- 没有可观测性基建chaos 注入后找不到影响范围等于盲人摸象- 业务方对 SLA 没承诺推不动改进演练完没人改代码我个人更倾向于先用 Chaos Monkey Byteman 做 3 个月 POC期间不考核覆盖率只考核通过演练发现 P0/P1 故障数。一旦这个数字稳定每月 2 个再考虑上 Chaos Mesh 分布式编排。直接上 Chaos Mesh 的团队我没见过不踩坑的。更激进一点业务方不支持做就坚决不做。混沌工程的本质是主动暴露问题如果业务方抱着演练就是作秀的心态做了也是浪费运维时间。见过太多团队 ROI 算不清就上到头来沦为定期开关的玩具。八、思考题与下期预告留 3 个问题供读者思考你的业务里哪 3 个故障场景如果线上发生能立刻 P0这 3 个场景有没有被演练覆盖如果让你给老板一句话解释混沌工程的 ROI你会怎么写我们当时汇报的那句话被否决了 4 次最终版只有 16 个字但每个字都是被数据撑起来的。你愿意为故障注入投入多少人力成本10%30%为什么这个比例和你们的故障频次是不是成正比下期我会写一篇《从 SRE 视角看可观测性OpenTelemetry 2.4 在 Java 21 上的落地细节》里面会有 4 个真实的 trace 截图分析敬请关注。参考资料- Chaos Monkey Spring Boot 2.5.5 官方文档- Byteman 4.0.21 Reference Guide- Chaos Mesh 2.6.3 CRD 文档- Resilience4j 2.2.0 CircuitBreaker 模块- Gremlin《State of Chaos 2023》报告- 团队内部 Wiki: 2024Q2 混沌工程落地复盘
