混沌工程入门：用Chaos Mesh验证微服务容错能力

为什么需要混沌工程？

你的微服务真的能容错吗？重试机制在真实网络抖动下会触发吗？熔断器在依赖服务超时的那一刻真的会打开吗？这些都是无法通过单元测试验证的假设。

混沌工程的定义：在生产（或类生产）环境中进行实验，通过主动注入故障来验证系统应对湍流条件的能力。

Chaos Mesh 简介

Chaos Mesh 是一个云原生混沌工程平台，原生支持 Kubernetes。它提供了丰富的故障类型：

• PodChaos：Pod 级别的故障注入（杀 Pod、Pod 不可用）
• NetworkChaos：网络故障（延迟、丢包、分区）
• StressChaos：资源压力（CPU、内存）
• IOChaos：文件系统 I/O 故障（延迟、错误）
• HTTPChaos：HTTP 请求注入

快速部署

# 安装 Chaos Mesh
curl -sSL https://mirrors.chaos-mesh.org/v2.7.2/install.sh | bash

# 验证安装
kubectl get pods -n chaos-mesh

第一个实验：网络延迟注入

场景：验证支付服务的超时重试

假设你的订单服务依赖支付服务，配置了 3 秒超时和最多 2 次重试。我们通过注入网络延迟来验证重试逻辑：

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-delay
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  delay:
    latency: "5s"
    jitter: "1s"
  duration: "5m"
  scheduler:
    cron: "@every 30m"

观测指标

实验期间需要监控以下指标：

1. 业务指标：订单成功率是否下降？重试是否生效？
2. 系统指标：CPU、内存使用率是否异常？线程池是否耗尽？
3. 告警：告警是否正确触发？是否有噪音告警？

混沌实验设计原则

1. 先假设后验证：每个实验必须有一个明确的稳态假设（如"支付服务 2s 延迟时订单成功率保持 99% 以上"）。
2. 最小爆炸半径：从单个 Pod 开始，逐步扩大影响范围。
3. 随时可终止：配置实验持续时间，确保故障能自动恢复。
4. 生产优先：Staging 环境的流量模式和生产完全不同，尽可能在生产环境实验。

总结

混沌工程不是为了制造混乱，而是为了发现未知的未知。一个从未出过故障的系统，不等于一个可靠的系统——它可能只是还没遇到足够多的边缘情况。从最小的网络延迟实验开始，让你的系统韧性在一次次的"攻击"中成长。