如何在Spring Boot中自行构建断路器，并真正理解“弹性机制”的含义——4j教程

本文介绍了如何使用明确的故障跟踪机制、由调度器驱动的恢复模型以及清晰的状态转换逻辑，在Spring Boot中设计并实现自己的断路器。

我们不会仅仅依赖Resilience4j，而是会详细剖析其内部工作原理，帮助您真正理解断路器的运作方式。

我们将涵盖的内容

1. 先决条件与技术背景

2. 分布式系统中的断路器是什么

   • 为什么在Spring Boot中需要使用断路器

   • 为何断路器具有基础性作用

   • 断路器能解决哪些超时和重试机制无法解决的问题

   • 断路器的状态模型

   • 为什么不要直接使用Resilience4j

3. 自定义断路器的设计目标

4. 如何构建一个最基本的断路器类

   • 并发性与状态转换的保障机制

   • 类中的状态模型实现方式

   • 类内的故障跟踪功能

   • 从关闭状态如何转换到开启状态

   • 类中处于开启状态时的行为表现

   • 调度器驱动的恢复机制：进入半开启状态

5. Spring Boot调度器的使用示例

   • 这一机制如何与执行流程相结合

   • 调度器的设计原理与线程安全性

   • 为何在这种设计中避免使用@Scheduled注解

   • 整体设计思路的梳理

   • 可观测性：让断路器的运行状态更易于理解

   • 如何处理不同类型的故障

6. 自定义断路器与Resilience4j的对比

7. 在什么情况下不应该自行开发断路器

8. 如何扩展这一设计

9. 常见的错误与注意事项

10. 结论

先决条件与技术背景

本文假设您已经熟悉Spring Boot的核心概念以及Java的相关知识。我们不会深入探讨框架的基础原理或基本的并发处理机制。以下是您需要了解的内容：

Spring Boot基础

您应该了解Spring中的依赖注入机制，知道如何定义〈code>@Configuration〉类和〈code>@Bean〉注解，以及Spring应用程序的基本服务层结构。在本教程中，我们将断路器视为一个普通的Java组件，并通过配置类而非注解将其集成到Spring系统中。

Java并发基础

您不需要成为并发处理方面的专家，但应该熟悉Java提供的基本并发工具。本实现会使用〈code>AtomicInteger〉、volatile字段、〈code>ScheduledExecutorService〉以及简单的同步机制，因此您需要理解为什么共享的可变状态是危险的，原子操作与同步代码块有何不同，以及为什么在共享状态机中状态转换必须进行序列化处理。

函数式接口

断路器提供了〈code>execute(Supplier)方法，因此您应该能够熟练使用〈code>Supplier，编写简单的Lambda表达式，并将外部服务调用封装成可以传递给断路器的函数。

Resilience4j基础

您不需要具备实际使用Resilience4j的经验，但应该知道它是一个轻量级的Java容错库，提供了断路器、重试机制、速率限制功能等组件，通常通过注解或配置文件在Spring Boot项目中使用。在本文中，我们仅会提及Resilience4j作为参考，并不会实际进行配置或使用它的示例。

分布式系统中的断路器是什么？

断路器是一种容错机制，它的作用是阻止系统反复尝试那些很可能失败的操作。

这一名称源于电气工程领域。在物理电路中，当电流过大时，断路器会自动“切断”电路，从而防止设备受损；经过一段时间后，断路器会重新允许电流通过，以检查问题是否已经得到解决。

在软件系统中，这一原理同样适用。当服务A依赖于服务B，而服务B运行缓慢或无法正常工作时，如果盲目地重复发送请求，可能会导致以下后果：

• 耗尽线程池资源

• 使连接池达到饱和状态

• 增加整个系统的延迟

• 引发连锁故障

• 导致原本正常运行的服务也出现故障

相比之下，断路器的作用是：当检测到某个依赖组件出现故障时，它会立即停止向该组件发送请求，从而避免进一步的错误发生。

• 能够检测到重复出现的故障。

• 会切断相关电路并阻止请求被发送。

• 在尝试执行操作之前就会立即失败。

• 会定期检查该依赖项是否已经恢复正常。

这样，原本无法控制的故障就被转化成了可以被有效管理的异常情况。

为什么在Spring Boot中电路断路器如此重要

因为电路断路器是分布式系统中一种基础性的容错机制，所以大多数使用Spring Boot的开发团队都会优先选择Resilience4j或传统的Hystrix这类工具来实现容错功能——这是有充分理由的。这些库已经经过了充分的测试，并且在实际生产环境中也被证明是非常可靠的。

然而，如果将电路断路器视为“黑箱”来使用，往往会导致以下问题：

• 配置错误的阈值设置。

• 对故障处理机制存在误解。

• 难以扩展这些库提供的默认功能。

• 在遇到故障时，会陷入“断路器已经启动了，但我们不知道原因何在”的调试困境。

即使你最终并没有将自开发的电路断路器投入生产环境，那么开发这个工具的过程也会迫使你深入了解那些真正能够保护你的系统的机制。在某些情况下，自定义实现的电路断路器还能提供通用库所无法提供的灵活性。

为什么电路断路器具有基础性意义

电路断路器之所以是重要的容错机制，是因为它们能够保护系统中最为宝贵的资源——比如线程、网络连接、数据库连接以及CPU时间——免受那些出现故障的依赖项的影响而被耗尽。

如果没有电路断路器的保护，一个性能缓慢的服务就有可能逐渐消耗掉所有这些资源，从而将原本只是局部的问题演变成整个系统的崩溃。

电路断路器与超时机制、重试机制、隔离屏障以及速率限制器等机制共同构成了系统的容错框架，但它们做出了一个关键的区别：当系统出现故障时，它们会暂时停止尝试继续执行相关操作。正是这个决定才防止了故障的连锁反应导致整个系统的崩溃。

电路断路器能解决哪些超时和重试机制无法解决的问题

超时机制和重试机制属于被动响应类型的容错措施：超时机制规定了等待的时间长度，而重试机制则会再次尝试执行相同的操作，希望这次能够成功。

但电路断路器是一种主动型的容错机制。它会持续监控故障的发生模式，一旦某个阈值被超过，就会立即停止与出现故障的依赖项之间的交互，这样新的请求就会被立即拒绝，而不会等到超时才发生反应。这种机制大大减少了资源浪费，并有助于在系统面临压力时保持其稳定性。

电路断路器的状态模型

无论是基于库实现的电路断路器，还是自定义开发的电路断路器，它们都遵循相同的概念状态模型。

1. 关闭状态：在关闭状态下，所有请求都会被允许通过，系统只会对出现的故障进行监控。

2. 开启状态：当故障次数超过预设的阈值时，电路断路器会进入开启状态，此时新的请求会被立即拒绝，相关操作也会失败。

3. 半开状态：在经过一段时间的冷却后，电路断路器会进入半开状态。在这种状态下，系统会允许少量测试请求通过，以检查该依赖项是否已经恢复正常；根据这些测试结果，系统会决定是重新回到关闭状态，还是继续保持开启状态。

复杂性并不在于这些状态本身，而在于转换发生的时机与方式。

为什么不直接使用Resilience4j呢？

Resilience4j确实非常优秀，但仍有充分的理由让人选择自行开发类似的系统：

• 如果你需要非标准的故障处理逻辑（例如与具体业务领域相关的错误处理机制）。

• 如果你需要定制化的恢复策略。

• 如果你希望以不同的方式来保存或共享状态信息。

• 如果你需要将系统设计与业务指标紧密结合起来。

• 如果你想深入了解系统的内部机制，以便进行调优和调试。

更重要的是，了解系统的内部原理能够有效防止误用。许多生产环境中的问题其实都是由于配置错误的“断路器”导致的，而不是因为根本没有这些“断路器”。

定制化“断路器”的设计目标

在开始编写任何代码之前，我们首先需要明确什么是“正确的”行为。从理论上讲，“断路器”这个机制看起来很简单，但细微的设计错误就可能导致竞态条件、错误的开启状态，甚至使它完全失去保护系统的功能。

以下设计目标能够确保系统实现的可预测性及安全性。

线程安全且开销低

“断路器”位于所有出站请求的路径上，因此每一个受保护的请求都会经过它。如果它的实现导致了锁竞争或复杂的同步操作，那么它很快就会变成系统性能的瓶颈。

在实现过程中，必须避免使用粗粒度的锁定机制，要谨慎地使用原子操作，并且在进行状态转换时不要不必要的阻塞程序的执行。线程安全性是绝对必要的：一个在并发环境下表现不良的“断路器”，其效果甚至比根本没有“断路器”还要糟糕。

可预测的状态转换

“断路器”本质上就是一种状态机。如果它的状态转换机制不一致，或者容易引发竞态条件，那么系统就会出现混乱——一个线程可能认为“断路器”是开启状态的，而另一个线程却认为它是关闭状态的，这样一来，系统的保护机制也就失去了意义。

为了避免这种情况，所有的状态转换（如CLOSED → OPEN → HALF_OPEN → CLOSED）都必须是明确、原子性的，并且结果必须是可预测的。在这种设计中，可预测性远比复杂的实现方式更为重要。

明确的故障跟踪机制

并不是所有的故障都应该导致“断路器”被开启。如果盲目地记录所有的异常情况，就可能会导致在客户端验证错误时也触发“断路器”，将业务规则违规错误视为基础设施故障，甚至会将真正的业务逻辑缺陷掩盖起来。

对故障进行分类是非常必要的：“断路器”只应该对那些属于基础设施层面的问题做出反应，比如超时、连接错误或5xx响应码之类的问题，而不应该对业务逻辑错误作出反应。保持这种区分能够确保系统的恢复机制始终与实际的故障类型相匹配。

基于时间的恢复机制与调度器的应用

某些实现方式会在每个请求中检查时间戳，以此来决定何时将状态从“开放”切换到“半开放”，这种做法会为处理流程增加额外的分支结构。

而这种设计则采用调度器：当断路器被触发时，它会安排一次恢复尝试，确保“开放”状态仅用于快速失败处理机制，并避免基于请求的轮询操作。这样的方式能够在负载较大时减少分支逻辑和竞争现象。恢复机制应当是可控且可预测的，而不是随机执行的。

与特定框架无关的核心逻辑

断路器本身应该使用纯Java代码实现——不使用Spring注解、不采用AOP技术，也不应与任何特定框架紧密耦合。这样的设计有助于简化单元测试，提高组件的可移植性，并确保各个功能模块之间的分离更加清晰，避免出现隐藏的复杂性。Spring应当用于封装断路器的功能，而不是定义它本身，这样你的弹性恢复策略才不会受限于某个特定框架的结构。

轻松集成到Spring Boot中

尽管核心逻辑与具体框架无关，但它仍然需要能够顺利地融入Spring应用程序中。这意味着需要通过`@Configuration`注解进行配置设置，支持依赖注入机制，并能在服务层中的明确位置调用相关方法。弹性恢复机制的功能应该在代码审查过程中一目了然；如果将其隐藏在注解后面，那么在调试生产环境出现的问题时往往会引发混淆。

如何构建一个最基本的断路器类

现在，让我们将这些概念性的组件整合成一个完整的Java类。虽然这仍然是一个最基础的实现，但它已经足以完整地展示状态管理、故障跟踪、调度机制以及执行逻辑等功能。

一个最基本的断路器由以下部分组成：

1. 状态存储模块

2. 故障记录模块

3. 状态转换规则

4. 恢复任务调度模块

5. 执行控制逻辑

public final class CircuitBreaker {

enum State {
CLOSED,
OPEN,
HALF_OPEN
}

private final ScheduledExecutorService scheduler;
private final int failureThreshold;
private final int halfOpenTrialLimit;
private final Duration openCooldown;

private final AtomicInteger failureCount = new AtomicInteger(0;
private final AtomicInteger halfOpenTrials = new AtomicInteger(0);

// 所有状态转换操作都通过这个字段完成，且这些操作由`synchronized`块保护。
private volatile State state = State.CLOSED;

public CircuitBreaker(
ScheduledExecutorService scheduler,
int failureThreshold,
int halfOpenTrialLimit,
Duration openCooldown
) {
this.scheduler = scheduler;
this.failureThreshold = failureThreshold;
this.halfOpenTrialLimit = halfOpenTrialLimit;
this.openCooldown = openCooldown;
}

public T execute(Supplier action) {
// 1. 根据当前状态来控制功能的执行。
为保证线程安全，我们使用了`synchronized`块。
防止其他线程修改当前的状态。
State current;
synchronized (this) {
current = state;

if (current == State.OPEN) {
直接返回，进入关闭状态。
return;
} else if (current == State.HALF_OPEN) {
一旦在半开放状态下发生故障，就会立即返回到开放状态。
return;
}
}

private void transitionToOpen() {
state = State.OPEN;
将所有计数器重置为0，以便下一个关闭阶段能够从初始状态开始。
failureCount.set(00;
scheduleHalfOpen();
}

private void transitionToHalfOpen() {
synchronized (this) {
state = State.HALF_OPEN;
halfOpenTrials.set(0private void transitionToClosed() {
state = State.CLOSED;
failureCount.set(0;
halfOpenTrials.set(0private void scheduleHalfOpen() {
scheduler.schedule(
this::transitionToHalfOpen,
openCooldown.toMillis(),
TimeUnit.MILLISECONDS
);
}
}


现在，我们将逐一探讨这个类中的每一项功能：这些字段存在的意义、状态转换的机制、在哪些情况下并发性保障措施会发挥作用、执行过程是如何被保护的，以及调度器是如何推动系统恢复的。

每个小节都直接对应于这个类中的某个具体部分——我们并不会引入新的概念，只是对上述代码中实现的具体行为进行解释而已。

并发性与状态转换保障机制

虽然断路器在计数器的实现上使用了原子操作原语，并且也使用了一个易变的状态字段，但这一切之所以能够正常工作，是因为所有的状态转换都得到了严格的同步保护。

实际上，任何一次状态转换——无论是从“关闭”变为“打开”，还是从“打开”变为“半开”，又或是从“半开”变为“关闭”——都必须通过相同的同步机制来完成。例如，要么使用单一锁机制，要么采用基于CAS操作的原语来实现状态机的控制。如果将未进行同步的状态更新与原子计数器的操作混合在一起，就可能会导致系统出现混乱的行为（比如，一个线程正在尝试重新打开断路器，而另一个线程却试图将其关闭）。

synchronized (this) {
            current = state;

            throw “断路器处于打开状态，请求被拒绝。”");
            }

            int trials = halfOpenTrials.incrementAndGet();
                “尝试次数过多，系统将立即停止尝试。”
                    halfOpenTrials.decrementAndGet();
                    new IllegalStateException(“断路器处于半开状态，尝试次数已超过限制。”");
                }
            }
        }

这条规则非常简单：读取操作可以是非阻塞的，但写入操作和状态转换必须被序列化处理。

解释类中的状态模型

该实现的核心是一个简单而严格的状态机，这个状态机由`State`枚举类型来表示：`CLOSED`、`OPEN`和`HALF_OPEN`。

`state`字段被声明为`volatile`类型，因此任何对该字段的修改都会立即在所有线程中得到体现。当一个线程将断路器的状态改变时，其他线程会立刻看到这一变化。

除了状态信息外，该类还使用`AtomicInteger`来维护`failureCount`和`halfOpenTrials`这两个计数器。具体实现细节请参见上文中的代码示例。这些计数器用于记录故障发生的次数以及我们进行了多少次恢复尝试，而整个过程并不需要依赖任何粒度较粗的锁机制。

核心设计理念在于职责的分离：`enum`用于表示当前的操作模式，而原子计数器则用来记录那些会影响状态转换的指标。然而，仅依靠原子递增操作并不能保证状态转换的安全性，因此所有对状态的更新仍然需要遵循统一的序列化策略，以避免竞态条件的发生。
enum State {
CLOSED,
OPEN,
HALF_OPEN
}
这种结构为我们提供了一个清晰的基础：一个结构简洁、状态转换边界明确的状态机。

类内部的故障跟踪机制

private onFailure(Throwable t) {
// 示例：仅统计“服务器端”发生的故障。
true; // 用于后续进行特定领域相关的检查

return;
}

this) {
if (state == State.CLOSED && failures >= failureThreshold) {
transitionToOpen();
} if (state == State.HALF_OPEN) {
// 当处于HALF/Open状态时，只要发生任何故障，系统都会恢复到OPEN状态。
transitionToOpen();
}
}
}
在这种实现方式中，故障跟踪机制被设计得相当简单：我们只统计连续发生的故障。每当一个受保护的调用方法抛出异常时，这些异常就会被视为与“断路器”的工作原理相关的故障，此时`failureCount`的值就会增加；而当调用成功时，这个计数器的值就会重置。
我选择使用连续故障这一指标，是为了让逻辑更加清晰明了，而非追求复杂的算法。像滑动时间窗口或故障比率这类更高级的统计方法，会引入额外的状态管理和计时复杂性。在学习断路器的工作原理时，简单的计数机制能够使状态转换规则更容易理解，也便于进行测试。
同样重要的是，断路器不应该对所有异常一视同仁。领域验证错误、客户端的误操作或业务规则的违反，都不应该影响断路器的状态。只有基础设施层面出现的问题（比如超时、连接失败或5xx响应），才应该促使断路器进入“OPEN”状态。这种区分机制能让断路器专注于处理依赖关系中的不稳定因素，而不是应用程序的错误或输入数据的问题。

关闭状态如何转换为开放状态

当断路器处于关闭状态时，所有请求都能正常通过。在这一阶段，断路器仅起到监控作用：每当发生与断路器相关的异常时，它就会记录这一事件并增加failureCount的值。

在onFailure方法中（如上节所述），一旦failureCount超过预设的阈值，断路器就会转换为开放状态。这种状态的转换必须是原子性的且有序进行的——否则，多个线程可能会同时尝试打开断路器，从而导致调度混乱或恢复任务重复执行。

private void transitionToOpen() {
        state = State.OPEN;
        // 重置计数器，以便下一个关闭阶段能够从初始状态开始。
        failureCount.set(00

一旦断路器进入开放状态，系统的行为就会立即发生变化。从这一刻起，新的请求将会被直接拒绝，而不会尝试执行受保护的操作——这样就可以保护下游服务，并节约线程和连接池等本地资源。

类中处于开放状态时的行为

开放状态代表着“快速失败”的机制。当断路器处于开放状态时，任何受保护的调用都不会被执行。execute()方法会立即抛出异常，表明电路当前处于开放状态。

public  T execute(Supplier action) {
        // 1. 根据当前状态来决定是否执行相应操作。
        为确保线程安全，我们使用了同步块。
        防止其他线程更改我们的当前状态。
        State current;
        synchronized (this) {
            current = state;

            throw “断路器处于开放状态，请求被拒绝。”

这种行为的目的并不是为了提高系统响应速度，而是为了保护资源。如果让调用继续执行并让它们“等待超时”，仍然会占用线程和连接资源。因此，开放状态的真正价值在于：它完全拒绝参与故障的传播过程。

在这种状态下，断路器的唯一职责就是等待预定的恢复尝试时间。它不会检查每个请求的时间戳，也不会在关键路径上执行轮询操作。它的行为是确定性的：会立即拒绝所有请求，然后由调度器来决定何时再次尝试恢复。

调度器驱动的恢复机制：进入“半开启”状态

当断路器的状态转变为“开启”时，它会立即使用注入的`ScheduledExecutorService`来安排一个延迟执行的任务。在配置好的冷却时间结束后，该任务会使得断路器的状态变为“半开启”。

请参考主代码中的以下方法

void () {
        state = State.OPEN;
        重置相关计数器，以便下一个“关闭”状态能够从初始状态开始。
        failureCount.set(00在状态变为“开启”后，安排一个延迟任务
    }

void () {
        scheduler.schedule(
                Spring Boot调度器示例
在Spring Boot中，你可以使用专门的`ScheduledExecutorService` bean来驱动状态转换，而无需使用普通的Java线程。
@Configuration
CircuitBreakerConfig {

    第一个Bean配置
    @Bean
    ScheduledExecutorService () {
        第二个Bean配置
    @Bean
    CircuitBreaker (ScheduledExecutorService circuitBreakerScheduler) {
        new CircuitBreaker(
                circuitBreakerScheduler,
                5,                     失败次数阈值
                2,                     30) 这种配置如何与执行流程相结合
一旦被注册为Bean，断路器就会成为应用程序依赖关系图的一部分。一个典型的服务可能会将断路器注入到自己的代码中，并在对外发起请求时使用它：
@Service

class ExternalApiService {

    private final CircuitBreaker circuitBreaker;

    private final RestTemplate restTemplate;
    ExternalApiService(CircuitBreaker circuitBreaker, RestTemplate restTemplate) {

        this.circuitBreaker = circuitBreaker;

        this.restTemplate = restTemplate;

    }
    public String callExternal() {

        return circuitBreaker.execute(() -> {

            restTemplate.getForObject("http://external/api", String.class);

        });

    }

}


任何对外部系统的调用都会先通过断路器的`execute()`方法，该方法会在允许请求继续执行之前，检查当前的状态是否符合规则。这样一来，在集成层就能清楚地看到系统的弹性保护机制：任何查看该服务代码的人都能立即了解到这些保护措施的存在。不存在任何隐藏的拦截层，也没有AOP代理在运行时悄悄改变程序的行为。
调度器的设计与线程安全性
调度器唯一的职责是负责控制状态的转换。它并不执行业务逻辑，也不会评估请求的结果。它的功能非常有限：在经过冷却期后，将断路器的状态从“打开”切换到“半开”。
由于执行器是单线程的，因此被调度的任务不能同时执行。但这并不能完全消除并发带来的问题。当调度器开始执行操作时，请求线程仍可能尝试同时进行状态转换。因此，像transitionToHalfOpen()和transitionToOpen()这样的状态转换方法必须具备序列化特性，并且要保证其操作的幂等性。
换句话说，尽管调度器简化了基于时间的恢复机制，但它并不能替代对状态进行仔细管理这一需求。
这种架构分工如下：


请求线程 → 执行规则并记录结果


调度器线程 → 负责控制状态的转换操作


将这些职责分开处理，可以降低系统中的复杂性，并提高系统在负载较高时的可预测性。
为何在此设计中避免使用@Scheduled
Spring提供了@Scheduled作为处理基于时间任务的另一种机制。虽然这种方式使用起来很方便，但它会引入全局性的调度行为，从而降低系统的隔离性。
通过专门使用ScheduledExecutorService来处理断路器的状态转换，我们可以避免其他被调度的任务对断路器造成干扰，同时也能明确地控制其生命周期，并将调度逻辑直接与断路器的状态变化联系起来。
这种设计体现了这样一个原则：容错组件应当具备隔离性，并且其行为必须具有可预测性。
整体架构梳理
在这个设计中，各个组件的交互过程如下：


某个服务会使用circuitBreaker.execute()来封装其对依赖项的调用。


如果断路器的状态是“关闭”的，那么该调用就会正常执行，同时系统也会记录下所有发生的失败次数。


当失败次数超过预设阈值时，断路器的状态会变为“打开”，系统会自动安排一次恢复尝试。


在断路器处于“打开”状态时，任何调用都会立即失败，而不会影响到下游系统。


经过冷却期后，调度器会将断路器的状态切换回“半开”。


随后会进行少量的测试性调用，以确定断路器最终是应该恢复到“关闭”状态，还是继续保持“打开”状态。


整个流程中没有任何隐藏的部分：所有的状态转换都在代码中明确体现出来，每一个配置参数也都一清二楚，而且每个参与执行的线程都只负责一项具体的任务。正是这种清晰性，使得这种自定义实现的方案既便于学习，而且在设计得当的情况下也会保证其安全性。
可观测性：让断路器的行为变得易于理解
如果一个断路器不具备可观测性，那么使用它就会带来风险。至少，你应该公开显示断路器的当前状态、失败次数、上次状态转换的时间，以及断路器已经保持“打开”状态的具体时长。
在指标方面，需要记录断路器被触发的频率、每秒有多少请求被拒绝，以及恢复尝试的成功率。
你的日志应该以INFO级别记录状态变化，以DEBUG级别记录故障分类决策。有了这样的可见性，你自定义开发的断路器往往比许多现成的库更容易理解和使用。
处理不同类型的故障
并非所有的故障都是相同的。


API响应超时 → 与断路器相关


API 5xx响应 → 与断路器相关


API 4xx响应 → 通常无关


任何数据或业务验证错误 → 绝对无关


自定义开发的断路器允许你进行这种基于业务逻辑的分类，而这种分类用通用的库往往很难实现。
自定义断路器与Resilience4j的对比




方面
自定义断路器
Resilience4j




学习成本
高
低


灵活性
高
中等


实施时间
中等
低


运行成熟度
视具体情况而定
高


自定义故障处理逻辑
容易实现
受限


工具/指标支持
需要手动配置指标、日志和观测功能
内置指标、日志记录及集成功能



这个选择并非非黑即白。许多团队会先使用自定义断路器进行原型开发，之后再将其替换为配置正确的Resilience4j。
何时不应自行开发自定义断路器
在以下情况下，不要自行开发自定义断路器：


如果你缺乏必要的观测能力。


如果你不理解并发处理的原理。


如果你迫切需要高级功能。


如果你的系统属于安全关键型系统。


例如，如果你正在开发一个具有严格SLA要求的支付平台，且无法承担对自定义断路器进行测试的风险，那么使用像Resilience4j这样的成熟库会更为稳妥。在生产环境中，出现并发错误、故障分类错误或调度配置问题带来的风险实在太大，不适合进行实验。
扩展设计功能
一旦掌握了核心原理，你还可以添加以下功能：


滑动窗口指标


自适应阈值设置


断路器的持久状态管理


针对不同依赖关系的分布式断路器配置


与功能开关的集成


当你能够控制系统的内部机制时，这些扩展功能会变得容易实现得多。
常见错误
在使用断路器时，人们常常会犯以下错误：


在第一次出现故障时就立即断开连接。


当断路器处于“开启”状态时，会阻止相关线程的运行。


允许无限次发送“半开启”状态的请求。


对所有异常情况都采取相同的处理方式。


完全忽略可观测性方面的考虑。


这些情况大多发生在人们在不了解相关库的原理的情况下使用它们时。
结论
弹性恢复机制相关的库确实非常强大，但它们并非万能工具。从根本上来说，断路器其实就是一种具有故障检测功能、并能根据预设时间规则进行状态切换的状态机。即使只构建一次这样的断路器，也能迫使你真正理解这一原理。



明确故障处理的相关规则。


帮助提高调试效率。


实现针对特定业务场景的弹性恢复机制。


让你能更熟练地使用Resilience4j这个库。


你可能永远不会将自己构建的断路器部署到生产环境中，但一旦体验过这个过程，以后再配置断路器时就再也不会盲目操作了。