4、熔断器核心状态机详解：Closed、Open 与 Half-Open

熔断器的核心是一个三态状态机：Closed（关闭）、Open（打开） 和 Half-Open（半开）。这三个状态之间的转换逻辑直接决定了 API 熔断的灵敏度和恢复效率。本章将逐一拆解每个状态下的工作机制、关键参数与实现细节。

4.1 Closed 状态：请求计数与阈值

Closed 是熔断器的初始状态，此时 API 网关正常转发所有请求。熔断器内部维护一个滑动窗口计数器，用于统计最近一个时间窗口内的请求成功/失败情况。

4.1.1 滑动窗口计数机制

滑动窗口将时间划分为多个小桶（bucket），每个桶记录该时间段内的请求结果。窗口随时间向前滑动，自动丢弃过期数据。

4.1.2 计数与阈值判断逻辑

每次请求完成时，熔断器执行以下判断流程：

1. 记录结果：将请求结果（成功/失败/超时）写入当前时间桶。
2. 聚合统计：计算滑动窗口内的总请求数、失败请求数、失败率。
3. 前置检查：若总请求数 < 最小请求数，跳过熔断判断。
4. 阈值比较：若失败数 ≥ 失败阈值 或 失败率 ≥ 失败率阈值，触发状态转换至 Open。
5. 重置桶：若未触发熔断，继续累积下一个桶的数据。

// 伪代码：Closed 状态下的请求计数与阈值判断
class ClosedState {
    slidingWindow: SlidingWindow
    failureThreshold: int = 10
    minRequestThreshold: int = 20
    failureRateThreshold: float = 0.5

    function onRequestComplete(result: RequestResult) {
        // 1. 记录结果到当前时间桶
        slidingWindow.record(result)

        // 2. 聚合统计
        totalRequests = slidingWindow.getTotalRequests()
        failureCount = slidingWindow.getFailureCount()
        failureRate = failureCount / totalRequests

        // 3. 前置检查：低流量保护
        if (totalRequests < minRequestThreshold) {
            return  // 不触发熔断
        }

        // 4. 阈值比较
        if (failureCount >= failureThreshold ||
            failureRate >= failureRateThreshold) {
            transitionTo(State.OPEN)
        }
    }
}

4.2 Open 状态：快速失败

当熔断器进入 Open 状态后，所有发往该服务的请求将立即被拒绝，不再进行实际调用。这是熔断器保护下游服务最直接的手段。

4.2.1 快速失败机制

• 直接返回降级响应：网关拦截请求，返回预设的降级数据（如空列表、缓存数据、错误码 503）。
• 零网络开销：不建立 TCP 连接，不发送 HTTP 请求，避免占用连接池和线程资源。
• 冷却计时器：进入 Open 状态时启动冷却计时器，计时结束后自动转换至 Half-Open。

4.2.2 冷却时间配置

4.3 Half-Open 状态：试探性恢复

Half-Open 是熔断器的恢复探测状态。在此状态下，熔断器允许有限数量的试探请求通过，用于验证下游服务是否已恢复正常。

4.3.1 试探请求策略

• 试探请求数：通常设置为 1 ~ 3 个并发请求，避免试探流量过大。
• 成功判定：所有试探请求成功 → 转换至 Closed，重置计数器。
• 失败判定：任意试探请求失败 → 立即回到 Open，重置冷却计时器。
• 超时处理：试探请求超时视为失败，防止慢调用影响判断。

4.3.2 试探请求的隔离性

试探请求应使用独立的超时配置和独立的连接池，避免与正常请求混用导致资源竞争。

4.4 状态转换参数配置清单

以下清单汇总了熔断器三个状态的核心配置参数，供 MRM 模型验证时参考：