spring cloud Resilience4j - 熔断器 CircuitBreaker

本文介绍了微服务架构中服务依赖可能导致的雪崩效应,并详细阐述了熔断器模式的状态机及其作用。重点讲解了Resilience4j的熔断器配置,包括参数设置、滑动窗口算法以及如何通过注解和代码实现熔断。同时,提供了示例代码展示如何在Spring Cloud Resilience4j中应用熔断、重试、限流等策略。

在微服务架构中,一般我们的独立服务是比较多的,每个独立服务之间划分责任边界,并通过约定协议接口来进行通信。当我们的调用链路复杂依赖多时,很可能会发生雪崩效应。

假设有这么一个场景,有A, B, C, D四个独立服务,A会依赖B,C,D;当D发生负载过高或网络异常等导致响应过慢或超时时,很可能A会因此堆积过多的等待链接,从而导致A的状态也转为异常,后面依赖到A的其他服务跟着发生链式反应,这将会导致大面积的服务不可用,即使本来是一些没有依赖到B,C,D的服务。

状态说明

熔断器有如下状态:

  • CLOSED: 熔断器关闭,表示接口状态正常。
  • OPEN:熔断器打开,表示接口状态异常,直接抛出CallNotPermittedException。如果有failback则调用failback函数。
  • HALF_OPEN:半开状态,允许指定数量的请求通过,以查看后端服务是否正常。超过指定数量的请求,抛出CallNotPermittedException
  • DISABLED:停用熔断器,所有请求允许通过。
  • FORCED_OPEN:强制开启熔断器,所有请求不允许通过。

状态机:

在这里插入图片描述

滑动窗口

Resilience4j 支持两种滑动窗口算法:

  • 基于数量的滑动窗口:
    统计指定数量的请求数,请求先进先出,计算失败比例。查询失败比例的时间复杂度为O(1),与窗口大小无关;空间复杂度为O(n)
  • 基于时间的滑动窗口:
    窗口包含N个桶,N为时间秒数。分别计算每个桶的失败比例,然后计算一个总数。桶也是先进先出。查询失败比例的时间复杂度为O(1),与窗口大小无关;空间复杂度为O(n)

参数说明

参数默认值说明
failureRateThreshold50失败比例,如果超过该值,熔断器打开
slowCallDurationThreshold60000[ms]超过设置的时间,则是慢请求
slowCallRateThreshold100慢请求比例,超过该比例,熔断器打开
permittedNumberOfCallsInHalfOpenState10半开状态下,允许通过的调用数量
maxWaitDurationInHalfOpenState0熔断器处理半开状态的最大时长,超过该时间,转为打开状态。0 表示不限
slidingWindowTypeCOUNT_BASED滑动窗口类型,COUNT_BASED、TIME_BASED
slidingWindowSize100滑动窗口大小
minimumNumberOfCalls100在计算失败率或慢调用率时,窗口中至少要有多少个调用。当窗口中只有99个调用,即使都失败了,熔断器也不会打开
waitDurationInOpenState60000 [ms]熔断器从打开状态变为半开状态等待的时间
automaticTransitionFromOpenToHalfOpenEnabledfalse等待了waitDurationInOpenState时间后,是否自动变为半开状态。true:需要另起一个线程监控状态;false:只有有调用到来时,才会触发状态的转变
recordExceptions异常列表,只有指定的异常和其子类,才会认为调用失败;其它异常会被认为是调用成功,除非指定了ignoreExceptions
ignoreExceptions异常列表,忽略指定的异常,不计入成功和失败数
recordExceptionthrowable -> true, 所有异常都认为是失败表达式返回true表示计入调用失败,false计入调用成功。除非指定了ignoreExceptions
ignoreExceptionthrowable -> false,没有异常被忽略表达式返回true表示忽略该异常,false算入调用失败。

实例

配置文件

application.properties

resilience4j.circuitbreaker:
    instances:
        backendA:
            registerHealthIndicator: true
            slidingWindowSize: 100
        backendB:
            registerHealthIndicator: true
            slidingWindowSize: 10
            permittedNumberOfCallsInHalfOpenState: 3
            slidingWindowType: TIME_BASED
            minimumNumberOfCalls: 20
            waitDurationInOpenState: 50s
            failureRateThreshold: 50
            eventConsumerBufferSize: 10
            recordFailurePredicate: io.github.robwin.exception.RecordFailurePredicate

规则取名为-order

使用注解方式实现熔断

    @GetMapping("/getCoffee1")
    @io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker(name = "order",fallbackMethod = "fallback")
    public Coffee getCoffee1() {
        Coffee list = coffeeService.getById(1l);
        log.info("Read coffee: {} coffee", list);
        return list;
    }
    private Coffee fallback(IllegalArgumentException e){
        return new Coffee();
    }
    private Coffee fallback(RuntimeException e){
        return new Coffee();
    }

使用代码注册的方式实现

  private CircuitBreaker circuitBreaker;
    public CustomerController(CircuitBreakerRegistry registry) {
        circuitBreaker = registry.circuitBreaker("order");
    }
    @GetMapping("/getCoffee2")
    public List<Coffee> getCoffee2() {
        return Try.ofSupplier(
                CircuitBreaker.decorateSupplier(circuitBreaker,
                        () -> coffeeService.getAll()))
                .recover(CircuitBreakerOpenException.class, Collections.emptyList())
                .get();
    }

响应式:

@CircuitBreaker(name = BACKEND, fallbackMethod = "fallback")
@RateLimiter(name = BACKEND)
@Bulkhead(name = BACKEND)
@Retry(name = BACKEND, fallbackMethod = "fallback")
@TimeLimiter(name = BACKEND)
public Mono<String> method(String param1) {
    return Mono.error(new NumberFormatException());
}

private Mono<String> fallback(String param1, IllegalArgumentException e) {
    return Mono.just("test");
}

private Mono<String> fallback(String param1, RuntimeException e) {
    return Mono.just("test");
}

更多

spring cloud resilience4j-retry 重试
spring cloud resilience4j - Bulkhead 线程隔离 并发控制
spring cloud Resilience4j - 熔断器 CircuitBreaker
spring cloud resilience4j - RateLimiter 流控
参考:
https://resilience4j.readme.io/docs/getting-started-3

<think>好的,我现在需要回答用户关于Resilience4jSpring CloudCircuitBreaker的关系及集成方式的问题。首先,我需要回顾之前的对话和提供的引用内容,确保准确理解用户的需求。用户之前的提问是关于Resilience4j的功能和使用,现在他们进一步询问Resilience4jSpringCloud CircuitBreaker的关系。我需要先明确这两个组件的定位。根据引用[3],Resilience4j是一个轻量级的容错库,提供断路器、限流等功能。而引用[4]提到SpringCloud CircuitBreaker是一个抽象层,支持不同的断路器实现,比如Resilience4j和Hystrix。因此,两者的关系应该是Resilience4j作为具体的实现,而SpringCloud CircuitBreaker提供了统一的API,方便集成到Spring Cloud应用中。接下来,我需要确认集成方式。引用[5]展示了Feign整合Resilience4j的例子,用户通过控制器调用Feign接口,而Feign使用了Spring CloudCircuit Breaker的抽象。引用[1]中的依赖项spring-cloud-starter-circuitbreaker-resilience4j也说明了如何将Resilience4j集成到Spring Cloud项目中。此外,引用[2]中的配置示例显示了如何在application.yml中配置熔断器参数,这也属于集成的一部分。需要详细说明两者的关系,可能分为层次关系和功能定位。然后,集成方式包括添加依赖、配置参数、使用注解或编程式API等。同时,要引用正确的文献,比如引用[3]和[4]说明Resilience4j作为实现,SpringCloud CircuitBreaker作为抽象层。还要注意用户可能存在的混淆点,比如为什么需要抽象层,直接使用Resilience4j和通过Spring CloudCircuit Breaker使用有何不同。需要解释统一API的好处,比如切换不同实现更方便,与Spring生态集成更紧密等。最后,生成相关问题时要围绕两者的关系、集成方法、与其他组件的对比等,比如可能的问题包括如何选择不同的断路器实现,或者如何自定义配置等。总结步骤: 1.解释SpringCloud CircuitBreaker的作用和定位。 2.说明Resilience4j作为其一种实现。3.描述两者的层次关系:抽象层与具体实现。4.集成方式:依赖、配置、注解使用。 5.引用提供的文献支持每个部分。6.生成相关问题,如监控、配置优化、与其他库对比等。</think>### Resilience4jSpring Cloud CircuitBreaker 的关系解析 #### 一、架构定位关系 1. **Spring Cloud Circuit Breaker** 是 Spring Cloud 提供的**断路器抽象层**,定义了统一的断路器接口规范,支持多种实现方案(如 Resilience4j、Hystrix 等),其核心价值在于提供**标准化接入方式**[^4]。 2. **Resilience4j** 是 Spring Cloud Circuit Breaker 的**官方推荐实现**之一,专注于通过函数式编程实现轻量级容错控制。提供断路器、限流器等六大核心功能模块[^3]。 $$系统架构关系:应用层 → Spring\ Cloud\ CircuitBreaker\ API → Resilience4j\ 实现$$ #### 二、核心集成方式 ##### 1. 依赖注入 ```xml <!-- 引入抽象层与具体实现 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-circuitbreaker-resilience4j</artifactId> </dependency> [^1] ``` ##### 2. 编程模式对比 | 使用方式 | 代码示例 | |----------------------|--------------------------------------------------------------------------| | **注解驱动** | `@CircuitBreaker(name="serviceA", fallbackMethod="fallback")` | | **编程式API** | `CircuitBreakerFactory.create("serviceB").run(() -> businessLogic())` | ##### 3. 配置联动 ```yaml # 统一配置入口 spring: cloud: circuitbreaker: resilience4j: instances: backendService: failureRateThreshold: 60 ringBufferSizeInClosedState: 100 ``` #### 三、功能实现差异 1. **扩展能力差异** - Resilience4j 支持**装饰器模式**叠加多个容错策略(如重试+熔断组合)[^3] - Spring Cloud Circuit Breaker 提供**统一状态管理**,可通过 `CircuitBreakerRegistry` 集中监控所有实例[^4] 2. **执行流程对比** ``` 请求 → Spring Cloud 断路器接口 → Resilience4j 熔断判断 → 业务逻辑执行 ↑监控数据反馈 ↑熔断规则动态配置 ``` #### 四、生产级集成示例 ```java // 通过工厂模式创建断路器 @Service public class PaymentService { private final CircuitBreaker circuitBreaker; @Autowired public PaymentService(CircuitBreakerFactory cbFactory) { this.circuitBreaker = cbFactory.create("paymentCircuit"); } public String processPayment() { return circuitBreaker.run(() -> { // 调用支付网关 return paymentGateway.execute(); }, throwable -> "Fallback payment processed"); } } [^4] ``` ### 核心集成优势 - **标准化治理**:通过抽象层实现配置与代码解耦 - **动态切换能力**:可无缝替换为其他断路器实现(如 Sentinel) - **监控统一**:通过 Actuator 端点 `/actuator/circuitbreakers` 集中查看状态[^2]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

xiegwei

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值