超时、重试、熔断、幂等——这四个词你面试背熟了，但你的系统在依赖抖动时真的扛得住吗？一份故障注入稳定性报告

超时、重试、熔断、幂等——这四个词你面试背熟了，但你的系统在依赖抖动时真的扛得住吗？一份故障注入稳定性报告

审计里复现出两个反常场景。第一个：下游依赖偶发抖动，响应从平时的 30ms 变成 500ms，上游没设超时，请求全卡在那等着，线程池被一点点拖满，最后连带健康的请求也排不上队——一个下游的慢，雪崩成了整个上游的挂。第二个：上游设了重试，抖动时自动重发，可下游的扣款接口没做幂等，重试的那一次又被当成新请求处理，一笔订单扣了两次款。

超时、重试、熔断、幂等——这套「稳定性老四样」，面试人人背得滚瓜烂熟。但背熟不等于测过。它们几乎从没被系统性地验证过，原因很简单：功能测试默认依赖是健康的。依赖一健康，超时永远不会触发，重试永远不会发生，熔断永远不开，幂等永远用不上。这四个机制的代码可能压根就是错的，你却一路绿灯到线上。这篇讲怎么用故障注入，把这四种异常主动打进测试环境，逼系统的容错假设当场兑现。

一、审计结论摘要

审计对象是这套系统对依赖故障的容错能力，三条发现按风险从高到低。

第一，容错机制「有代码、无验证」。超时、重试、熔断、幂等都写了，但没有一条测试用例主动触发过它们。写了不等于对了——重试的退避算法、熔断的阈值、幂等键的取值，全都可能悄悄写错，直到线上第一次抖动才暴露。属阻断级。

第二，测试环境从不注入故障，功能测试默认依赖健康。这意味着系统在最脆弱的时刻（依赖抖动）恰恰是最没被测过的时刻。发现时机被推到了生产。

第三，重试与幂等没有成对验证。只测「重试能重发」或只测「幂等能去重」都没用，二者必须放在一起测——重试触发时，幂等是否真的挡住了重复副作用。这次的重复扣款正是二者脱节的结果。

建议动作三条：引入 toxiproxy 在测试环境给依赖注入 latency/超时/断连、为四个机制各写一组故障注入断言、把稳定性冒烟挂进 CI 每次跑。第六节给可运行实现，第七节给审计清单。

二、四个机制到底在解决什么，怎么注入验证

老四样不是四个孤立的知识点，是四道针对「依赖不健康」的防线，各自堵一个不同的失控。要把它们测出来，先得说清每个机制解决什么、不做会怎样、怎么注入、断言什么。

这张表的关键在「怎么注入验证」那一列：四个机制没有一个能靠「依赖健康」的功能测试触发。你必须主动把依赖弄坏——弄慢（验超时）、弄抖（验重试）、弄挂（验熔断）、弄重复（验幂等）——才能让这四道防线当场现身。这就是故障注入的意义：不是等故障发生，而是把故障请进测试环境。

三、功能测试为什么永远测不到这四个机制

功能测试和故障注入测试，覆盖的失败面根本不在一个维度。前者验的是「依赖正常时，业务通不通」；后者验的是「依赖不正常时，系统扛不扛得住」。用前者去保证后者，就是这次两个事故的共同根因。

一句话：功能测试全绿，只能证明「依赖健康时你是对的」；而稳定性事故几乎都发生在「依赖不健康」的那一刻——恰恰是你从没测过的那一面。故障注入就是把这一刻提前搬到测试环境。

四、用 toxiproxy 把故障精确注入

注入工具选 Shopify 开源的 toxiproxy：它是一个 TCP 代理，横在测试环境和下游依赖之间，你能通过它给流经的流量精确加「毒」——latency（延迟）、timeout（超时）、reset_peer（断连）、slow_close 等。它的好处是故障可控、可复现、可组合：想验超时就把 latency 调到超过阈值，想验熔断就持续断连，想验重试就间歇性 timeout。

这里有个方法论上的锚点：混沌工程（chaos engineering）的公开代表性实践是 Netflix 的 Chaos Monkey，思路是在受控环境主动制造故障来验证系统的容错假设。toxiproxy 就是把这个思路落到测试环境的一个具体工具——你不需要在生产随机杀实例，只需要在测试里给依赖注入一个可精确控制的抖动，就能验证「超时/重试/熔断/幂等」这四个假设到底成不成立。

五、断言点：验的是「行为」不是「没报错」

故障注入测试最容易写错的还是断言。四个机制各有各的行为断言，且都不能只断「没抛异常」。

超时的断言是「上游在 X 秒内失败返回」——注意是「快速失败」，不是「成功」，也不是「挂死」。你要测的恰恰是它有没有在阈值内主动放弃。重试的断言是「有限次重试后成功，且重试次数不放大流量」——无限重试比不重试更糟。熔断的断言是「熔断打开后走降级、不再穿透调用已挂的依赖」——要验的是它「不再打」，不是「打成功」。幂等的断言是「触发重试后，净副作用次数等于一」——这是重复扣款唯一的检测点。第六节的代码把这四条断言都落进去了。

六、可运行实现：toxiproxy 注入 + pytest 断言 + CI 冒烟

实现分两段。第一段用 toxiproxy 的 HTTP API 给依赖注入故障、并用 pytest 断言四个机制的行为；为了可直接读懂，注入部分封装成 helper，断言部分是真实可跑的 pytest。第二段是 CI 里跑的稳定性冒烟脚本。

"""
test_resilience.py —— 故障注入验证超时/重试/熔断/幂等（pytest + toxiproxy HTTP API）
前置：本地起 toxiproxy（默认 8474 端口），下游依赖经它代理。
    toxiproxy-server &
    toxiproxy-cli create downstream -l 127.0.0.1:15001 -u 127.0.0.1:5001
运行：pytest -q test_resilience.py
把 call_upstream 换成你真实的上游调用即可。
"""
import time
import requests
import pytest

TOXI = "http://127.0.0.1:8474"
PROXY = f"{TOXI}/proxies/downstream"


def add_toxic(toxic_type, attributes):
    """给 downstream 代理注入一个 toxic（latency / timeout / reset_peer 等）。"""
    r = requests.post(f"{PROXY}/toxics", json={
        "name": f"{toxic_type}_{int(time.time()*1000)}",
        "type": toxic_type, "stream": "downstream",
        "attributes": attributes,
    })
    r.raise_for_status()
    return r.json()["name"]


def remove_all_toxics():
    """清空所有 toxic，恢复依赖健康——每个用例后必须复位，否则污染下一个。"""
    toxics = requests.get(f"{PROXY}/toxics").json()
    for t in toxics:
        requests.delete(f"{PROXY}/toxics/{t['name']}")


def call_upstream():
    """真实项目里换成对上游服务的调用；这里返回 (耗时秒, 状态)。"""
    t0 = time.time()
    try:
        resp = requests.get("http://127.0.0.1:8000/checkout", timeout=5)
        return time.time() - t0, resp.status_code, resp.json()
    except requests.exceptions.RequestException:
        return time.time() - t0, None, {}


@pytest.fixture(autouse=True)
def clean():
    yield
    remove_all_toxics()


def test_timeout_fails_fast_not_hang():
    """注入 800ms 延迟，上游设了 300ms 超时 → 应在阈值附近快速失败，而非挂死。"""
    add_toxic("latency", {"latency": 800})
    elapsed, status, _ = call_upstream()
    assert status != 200, "依赖超时，上游不该成功"
    assert elapsed < 1.0, f"上游未在超时阈值内失败，疑似挂死: {elapsed:.2f}s"


def test_retry_succeeds_on_transient_jitter():
    """注入间歇性抖动，上游有限次重试后应成功。"""
    add_toxic("timeout", {"timeout": 100})   # 部分请求超时，模拟瞬时抖动
    elapsed, status, body = call_upstream()
    assert status == 200, "瞬时抖动下重试未拿回成功"
    assert body.get("retry_count", 0) <= 3, "重试次数放大，可能压垮下游"


def test_idempotent_on_retry_deduct_once():
    """触发重试后，扣款副作用只应生效一次（幂等键兜底）。"""
    add_toxic("reset_peer", {"timeout": 50})  # 强制断连触发上游重试
    _, status, body = call_upstream()
    assert body.get("deduct_count", -1) == 1, \
        f"重试导致重复扣款: deduct_count={body.get('deduct_count')}"


def test_circuit_breaker_opens_and_degrades():
    """持续断连触发熔断打开 → 后续请求走降级，不再穿透调用依赖。"""
    add_toxic("reset_peer", {"timeout": 0})   # 持续断连
    for _ in range(10):                        # 打足够多次触发熔断阈值
        call_upstream()
    _, status, body = call_upstream()
    assert body.get("degraded") is True, "熔断未打开或未走降级，仍在穿透调用"

#!/usr/bin/env bash
# ci_stability_smoke.sh —— CI 里跑的稳定性冒烟：确保四个容错机制没被改坏
set -euo pipefail

echo "[1/3] 启动 toxiproxy 并创建 downstream 代理..."
toxiproxy-server >/tmp/toxi.log 2>&1 &
sleep 2
toxiproxy-cli create downstream -l 127.0.0.1:15001 -u 127.0.0.1:5001 >/dev/null

echo "[2/3] 起被测上游服务（测试桩）..."
python -m app.run_test_stub >/tmp/upstream.log 2>&1 &
sleep 3

echo "[3/3] 跑故障注入稳定性冒烟..."
# 只跑标了 stability 的用例，快；失败即拦下这次合并
pytest -q -m stability test_resilience.py
RC=$?

# 复位：清空 toxic、关掉后台进程，避免污染环境
toxiproxy-cli delete downstream >/dev/null 2>&1 || true
pkill -f toxiproxy-server || true
pkill -f app.run_test_stub || true

if [ $RC -ne 0 ]; then
  echo "::error::稳定性冒烟失败：某个容错机制被改坏了"
  exit 1
fi
echo "稳定性冒烟通过：超时/重试/熔断/幂等四道防线均在位。"

为什么这么写：注入部分用 toxiproxy 的 HTTP API 而不是命令行，是为了能在 pytest 用例里精确地「注入—断言—复位」，每个用例自己控制故障，互不干扰。autouse 的 clean fixture 是命门——每个用例跑完必须 remove_all_toxics() 复位，否则上一个用例注入的 latency 会污染下一个，你会看到一堆莫名其妙的失败，还以为是代码坏了。四条断言各咬一个行为：超时断 elapsed < 1.0（快速失败而非挂死）、重试断 retry_count <= 3（不放大流量）、幂等断 deduct_count == 1（重试不重复扣）、熔断断 degraded is True（走降级不穿透）。CI 脚本用 -m stability 只跑稳定性用例，是因为故障注入用例偏慢，全量跑会拖垮每次 PR 的反馈速度，冒烟只挑这四条关键的守门。踩过的坑有三个：一是 reset_peer 的 timeout 语义容易搞反——timeout: 0 是立即断连（持续故障，用来触发熔断），timeout: 50 是先连上一会儿再断（间歇抖动，用来触发重试），选错了熔断和重试两个用例就测串了；二是幂等那条用例，被测上游必须真的把幂等键透传给下游，否则你测的是「假后端自己去了重」，跟真实链路的幂等没关系；三是 CI 脚本结尾的 pkill 复位不能省，toxiproxy 和测试桩留在后台会占住端口，下一次 job 起不来还报「address already in use」，排查半天发现是上一个 job 没清干净。

七、审计清单：对着报告逐条勾

这六项没有一项需要额外预算，只是在测试环境加一个 toxiproxy、为四个机制各写一组故障注入断言，再把稳定性冒烟挂进 CI。反过来说，一份从没主动打坏过依赖、四个容错机制一条都没触发过的稳定性测试报告，它的「全绿」不该被当作系统扛得住抖动的依据。

稳定性测试最贵的绿灯，是超时、重试、熔断、幂等四段代码都在，却从没被一次真实的依赖抖动叫醒过。

你系统里的超时和重试，是被故障注入测过，还是只在面试里背过？评论区聊聊。