模拟第三方 API 故障以验证客户端韧性

用 WireMock 构造延迟、500 与 429 等故障场景，把客户端指向它，验证重试、超时与降级逻辑真实生效。

目标

每个客户端都声称自己会正确重试与超时，但这些路径只在第三方出问题时才运行，而那恰恰是你无法测试的时刻。WireMock 反转局面：它扮演提供方并按指令作恶——固定延迟、错误状态码、按场景编排的序列。把客户端指向它，韧性就从设计文档里的一段话变成每次构建都能跑的测试。

步骤要点

用 Docker 启动 WireMock 3.9.1，访问 /__admin/mappings 确认返回空映射列表。
注入 30 秒固定延迟的 charges 桩：客户端若有 5 秒超时就必须主动中断而不是干等。
注入带 Retry-After 头的持久 429 桩，验证客户端退避或快速失败，而不是紧循环重试。
用 scenario 编排“先 500 后恢复”的序列，验证客户端对瞬时错误的重试能拿到第二次成功。
把 PAYMENT_BASE_URL 指到 WireMock 跑韧性测试集，断言慢调用被中断、429 被退避、瞬时 500 被重试。

排错提示

客户端无视注入的 429，多半是重试策略只认 503，应扩大可重试状态码集合并读取 Retry-After；测试套件整体挂起说明超时配错了层，比如只配了连接超时，需加端到端请求截止时间；桩返回 404 时先查 __admin/requests 请求日志，对比真实请求与映射的差异（常是尾斜杠或方法不符）。

适用边界

桩的延迟是合成的，缺少真实网络的抖动与丢包，配置超时要留余量；场景状态在重启后会重置，依赖序列的测试必须显式初始化场景状态。

代码示例

# One-off 429 with Retry-After
curl -s -X POST http://localhost:8080/__admin/mappings -d \
  '{"request":{"method":"GET","url":"/v1/rates"},"response":{"status":429,"headers":{"Retry-After":"2"}}'