熔断器模式原理：三种状态与状态转换

好，咱们今天聊聊熔断器模式。说实话，这个模式是我在分布式系统里最常用的几个模式之一。你想想看，微服务之间互相调用，一个挂了，搞不好整个系统都跟着崩。熔断器就是用来解决这个问题的。

熔断器的核心思想其实特别简单——就像你家电路里的保险丝。电流太大了，保险丝熔断，保护整个电路。在分布式系统里，当某个服务出现故障或者响应太慢，熔断器就会“断开”，避免调用方一直傻等，浪费资源。

熔断器的三种状态

熔断器一共有三种状态：Closed（关闭）、Open（打开） 和 Half-Open（半开）。这三种状态构成了熔断器的整个生命周期。

1. Closed 状态（关闭状态）

这是熔断器的默认状态。说白了，就是一切正常，请求照常通过。系统会统计最近一段时间内的失败次数或者失败率。

我记得有一次，我负责的一个电商系统，订单服务调用库存服务。平时一切正常，熔断器一直处于 Closed 状态。但有一天，库存服务突然变慢了，响应时间从 50ms 飙升到 5s。这时候熔断器就开始记录失败请求了。

2. Open 状态（打开状态）

当失败率达到阈值，熔断器就会切换到 Open 状态。这时候，所有请求都会被直接拒绝，不会真正去调用下游服务。调用方会立刻收到一个错误响应，比如返回一个降级结果或者抛出一个异常。

嗯，这里要注意：Open 状态不是永久性的。熔断器会设置一个超时时间，比如 30 秒。超时之后，熔断器会尝试切换到 Half-Open 状态。

3. Half-Open 状态（半开状态）

Half-Open 状态是一个过渡状态。熔断器会放行少量请求，去试探下游服务是否已经恢复。

如果这些试探请求成功了，熔断器就认为服务已经恢复，切换回 Closed 状态。如果失败了，熔断器就认为服务还没好，重新回到 Open 状态，并且重置超时计时器。

我个人习惯把 Half-Open 状态叫做“试探期”。这个阶段放行的请求数量很关键。放太多，下游服务扛不住；放太少，又试不出真实情况。

状态转换机制

三种状态之间的转换，其实就是一个有限状态机。咱们用一张表来总结一下：

当前状态	触发条件	下一状态
Closed	失败率达到阈值	Open
Open	超时时间到达	Half-Open
Half-Open	试探请求成功	Closed
Half-Open	试探请求失败	Open

这个转换机制看起来简单，但实际实现时有很多细节。比如，失败率的计算方式、滑动窗口的大小、超时时间的动态调整等等。

咱们来看一段伪代码，感受一下状态转换的逻辑：

class CircuitBreaker {
    State state = State.CLOSED;
    int failureCount = 0;
    int failureThreshold = 5;
    long lastFailureTime = 0;
    long timeout = 30000; // 30秒

    public Response call(Service service) {
        if (state == State.OPEN) {
            if (System.currentTimeMillis() - lastFailureTime > timeout) {
                state = State.HALF_OPEN;
            } else {
                return fallback(); // 直接降级
            }
        }

        try {
            Response response = service.invoke();
            if (state == State.HALF_OPEN) {
                state = State.CLOSED; // 试探成功
                failureCount = 0;
            }
            return response;
        } catch (Exception e) {
            failureCount++;
            lastFailureTime = System.currentTimeMillis();
            if (failureCount >= failureThreshold) {
                state = State.OPEN;
            }
            return fallback();
        }
    }
}

这段代码虽然简单，但已经包含了熔断器的核心逻辑。你想想看，实际生产环境里，我们还会加入滑动窗口、并发控制、动态阈值等机制。但万变不离其宗，核心就是这三种状态的转换。

熔断器在分布式系统中的作用

熔断器在分布式系统里到底有什么用？我总结了三个核心作用：

• 快速失败：当下游服务出问题时，熔断器能让你立刻知道，而不是一直等超时。这能节省大量线程和连接资源。
• 防止级联故障：一个服务挂了，如果不熔断，调用方也会被拖垮，然后调用方的调用方也会被拖垮……这就是所谓的“雪崩效应”。熔断器能切断这个链条。
• 自动恢复：熔断器不是永久断开的。它会在适当的时候尝试恢复，实现了系统的自愈能力。

说白了，熔断器就是分布式系统的“安全气囊”。平时你可能感觉不到它的存在，但关键时刻，它能救你一命。

好，这一章就到这里。下一章咱们聊聊熔断器的实现细节，包括滑动窗口、动态阈值、以及如何与 Hystrix、Resilience4j 等框架结合使用。