SpringCloud CircuitBreaker断路器详解_Java

hystrix简介

hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性
已进入停更运维阶段，后续采用resilience4j

circuit breaker介绍

服务雪崩

多个微服务之间调用的时候，假设微服务a调用微服务b和微服务c，微服务b和微服务c又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务a的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

circuit breaker的目的是保护分布式系统免受故障和异常，提高系统的可用性和健壮性
当一个组件或服务出现故障时，circuitbreaker会迅速切换到开放open状态(保险丝跳闸断电)，阻止请求发送到该组件或服务从而避免更多的请求发送到该组件或服务。
这可以减少对该组件或服务的负载，防止该组件或服务进一步崩溃，并使整个系统能够继续正常运行。同时，circuitbreaker还可以提高系统的可用性和健壮性，因为它可以在分布式系统的各个组件之间自动切换，从而避免单点故障的问题。
circuit breaker只是一套规范和接口，落地实现者是resilience4j

resilience4j介绍

官网地址：
- https://github.com/resilience4j/resilience4j
- https://resilience4j.readme.io/docs/circuitbreaker
说明

主要作用

熔断(circuit breaker)案例

断路器状态

断路器常用参数配置

按照count_based(计数的滑动窗口)

在客户端微服务引入依赖

<!--resilience4j-circuitbreaker-->
<dependency>
    <groupid>org.springframework.cloud</groupid>
    <artifactid>spring-cloud-starter-circuitbreaker-resilience4j</artifactid>
</dependency>
<!-- 由于断路保护等需要aop实现，所以必须导入aop包 -->
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-aop</artifactid>
</dependency>

客户端的yml配置开启circuit breaker

spring:
  application:
    name: cloud-consumer-openfeign-order
  ####spring cloud consul for service discovery
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        prefer-ip-address: true #优先使用服务ip进行注册
        service-name: ${spring.application.name}
    openfeign:
      # 开启circuitbreaker和分组激活 spring.cloud.openfeign.circuitbreaker.enabled
      circuitbreaker:
        enabled: true
        group:
          enabled: true #没开分组永远不用分组的配置。精确优先、分组次之(开了分组)、默认最后
# resilience4j circuitbreaker 按照次数：count_based 的例子
#  6次访问中当执行方法的失败率达到50%时circuitbreaker将进入开启open状态(保险丝跳闸断电)拒绝所有请求。
#  等待5秒后，circuitbreaker 将自动从开启open状态过渡到半开half_open状态，允许一些请求通过以测试服务是否恢复正常。
#  如还是异常circuitbreaker 将重新进入开启open状态；如正常将进入关闭close闭合状态恢复正常处理请求。
resilience4j:
  circuitbreaker:
    configs:
      default:
        failureratethreshold: 50 #设置50%的调用失败时打开断路器，超过失败请求百分⽐circuitbreaker变为open状态。
		slidingwindowtype: count_based # 滑动窗口的类型
		slidingwindowsize: 6 #滑动窗⼝的⼤⼩配置count_based表示6个请求，配置time_based表示6秒
		minimumnumberofcalls: 6 #断路器计算失败率或慢调用率之前所需的最小样本(每个滑动窗口周期)。如果minimumnumberofcalls为10，则必须最少记录10个样本，然后才能计算失败率。如果只记录了9次调用，即使所有9次调用都失败，断路器也不会开启。
		automatictransitionfromopentohalfopenenabled: true # 是否启用自动从开启状态过渡到半开状态，默认值为true。如果启用，circuitbreaker将自动从开启状态过渡到半开状态，并允许一些请求通过以测试服务是否恢复正常
		waitdurationinopenstate: 5s #从open到half_open状态需要等待的时间
		permittednumberofcallsinhalfopenstate: 2 #半开状态允许的最大请求数，默认值为10。在半开状态下，circuitbreaker将允许最多permittednumberofcallsinhalfopenstate个请求通过，如果其中有任何一个请求失败，circuitbreaker将重新进入开启状态。
		recordexceptions:
          - java.lang.exception
    instances:
      cloud-payment-service:
        baseconfig: default

客户端的controller类方法使用注解@circuitbreaker

@restcontroller
public class ordercircuitcontroller{
    @resource
    private payfeignapi payfeignapi;
    @getmapping(value = "/feign/pay/circuit/{id}")
    @circuitbreaker(name = "cloud-payment-service", fallbackmethod = "mycircuitfallback")
    public string mycircuitbreaker(@pathvariable("id") integer id){
        return payfeignapi.mycircuit(id);
    }
    //mycircuitfallback就是服务降级后的兜底处理方法
    public string mycircuitfallback(integer id,throwable t) {
        // 这里是容错处理逻辑，返回备用结果
        return "mycircuitfallback，系统繁忙，请稍后再试-----/(ㄒoㄒ)/~~";
    }
}

按照time_based(时间的滑动窗囗)

客户端的yml配置开启circuit breaker

spring:
  application:
    name: cloud-consumer-openfeign-order
  ####spring cloud consul for service discovery
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        prefer-ip-address: true #优先使用服务ip进行注册
        service-name: ${spring.application.name}
    openfeign:
      # 开启circuitbreaker和分组激活 spring.cloud.openfeign.circuitbreaker.enabled
      circuitbreaker:
        enabled: true
        group:
          enabled: true #没开分组永远不用分组的配置。精确优先、分组次之(开了分组)、默认最后
# resilience4j circuitbreaker 按照时间：time_based 的例子
resilience4j:
  timelimiter:
    configs:
      default:
        timeout-duration: 10s #神坑的位置，timelimiter 默认限制远程1s，超于1s就超时异常，配置了降级，就走降级逻辑
  circuitbreaker:
    configs:
      default:
        failureratethreshold: 50 #设置50%的调用失败时打开断路器，超过失败请求百分⽐circuitbreaker变为open状态。
        slowcalldurationthreshold: 2s #慢调用时间阈值，高于这个阈值的视为慢调用并增加慢调用比例。
        slowcallratethreshold: 30 #慢调用百分比峰值，断路器把调用时间⼤于slowcalldurationthreshold，视为慢调用，当慢调用比例高于阈值，断路器打开，并开启服务降级
        slidingwindowtype: time_based # 滑动窗口的类型
        slidingwindowsize: 2 #滑动窗口的大小配置，配置time_based表示2秒
        minimumnumberofcalls: 2 #断路器计算失败率或慢调用率之前所需的最小样本(每个滑动窗口周期)。
        permittednumberofcallsinhalfopenstate: 2 #半开状态允许的最大请求数，默认值为10。
        waitdurationinopenstate: 5s #从open到half_open状态需要等待的时间
        recordexceptions:
          - java.lang.exception
    instances:
      cloud-payment-service:
        baseconfig: default

隔离(bulkhead)案例

依赖隔离&负载保护：用来限制对于下游服务的最大并发数量

semaphorebulkhead(信号量舱壁)

juc信号灯内容的同样思想

当信号量有空闲时，进入系统的请求会直接获取信号量并开始业务处理。

当信号量全被占用时，接下来的请求将会进入阻塞状态，semaphorebulkhead提供了一个阻塞计时器，

如果阻塞状态的请求在阻塞计时内无法获取到信号量则系统会拒绝这些请求。

若请求在阻塞计时内获取到了信号量，那将直接获取信号量并执行相应的业务处理。

客户端引入依赖

<!--resilience4j-bulkhead-->
<dependency>
    <groupid>io.github.resilience4j</groupid>
    <artifactid>resilience4j-bulkhead</artifactid>
</dependency>

客户端yml配置文件

####resilience4j bulkhead 的例子
resilience4j:
  bulkhead:
    configs:
      default:
        maxconcurrentcalls: 2 # 隔离允许并发线程执行的最大数量
        maxwaitduration: 1s # 当达到并发调用数量时，新的线程的阻塞时间，我只愿意等待1秒，过时不候进舱壁兜底fallback
    instances:
      cloud-payment-service:
        baseconfig: default
  timelimiter:
    configs:
      default:
        timeout-duration: 20s

客户端controller类方法使用注解@bulkhead，设置类型为bulkhead.type.semaphore

@getmapping(value = "/feign/pay/bulkhead/{id}")
@bulkhead(name = "cloud-payment-service",fallbackmethod = "mybulkheadfallback",type = bulkhead.type.semaphore)
public string mybulkhead(@pathvariable("id") integer id){
    return payfeignapi.mybulkhead(id);
}
public string mybulkheadfallback(throwable t){
    return "mybulkheadfallback，隔板超出最大数量限制，系统繁忙，请稍后再试-----/(ㄒoㄒ)/~~";
}

fixedthreadpoolbulkhead(固定线程池舱壁)

juc-线程池内容的同样思想

fixedthreadpoolbulkhead的功能与semaphorebulkhead一样也是用于限制并发执行的次数的，但是二者的实现原理存在差别而且表现效果也存在细微的差别。fixedthreadpoolbulkhead使用一个固定线程池和一个等待队列来实现舱壁。

当线程池中存在空闲时，则此时进入系统的请求将直接进入线程池开启新线程或使用空闲线程来处理请求。

当线程池中无空闲时时，接下来的请求将进入等待队列，

若等待队列仍然无剩余空间时接下来的请求将直接被拒绝，

在队列中的请求等待线程池出现空闲时，将进入线程池进行业务处理。

依赖同上
客户端yml配置文件

####resilience4j bulkhead -threadpool的例子
resilience4j:
  timelimiter:
    configs:
      default:
        timeout-duration: 10s #timelimiter默认限制远程1s，超过报错不好演示效果所以加上10秒
  thread-pool-bulkhead:
    configs:
      default:
        core-thread-pool-size: 1
        max-thread-pool-size: 1
        queue-capacity: 1
    instances:
      cloud-payment-service:
        baseconfig: default
# spring.cloud.openfeign.circuitbreaker.group.enabled 请设置为false 新启线程和原来主线程脱离

客户端controller类方法使用注解@bulkhead，设置类型为bulkhead.type.threadpool
- threadpoolbulkhead只对completablefuture方法有效，所以必创建返回completablefuture类型的方法

@getmapping(value = "/feign/pay/bulkhead/{id}")
@bulkhead(name = "cloud-payment-service",fallbackmethod = "mybulkheadpoolfallback",type = bulkhead.type.threadpool)
public completablefuture<string> mybulkheadthreadpool(@pathvariable("id") integer id){
    system.out.println(thread.currentthread().getname()+"\t"+"enter the method!!!");
    try { timeunit.seconds.sleep(3); } catch (interruptedexception e) { e.printstacktrace(); }
    system.out.println(thread.currentthread().getname()+"\t"+"exist the method!!!");
    return completablefuture.supplyasync(() -> payfeignapi.mybulkhead(id) + "\t" + " bulkhead.type.threadpool");
}
public completablefuture<string> mybulkheadpoolfallback(integer id,throwable t){
    return completablefuture.supplyasync(() -> "bulkhead.type.threadpool，系统繁忙，请稍后再试-----/(ㄒoㄒ)/~~");
}

限流(ratelimiter)案例

对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速，以保护应用系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理

常见限流算法

漏斗算法(leaky bucket)

一个固定容量的漏桶，按照设定常量固定速率流出水滴，类似医院打吊针，不管你源头流量多大，我设定匀速流出。如果流入水滴超出了桶的容量，则流入的水滴将会溢出了(被丢弃)，而漏桶容量是不变的

这里有两个变量，一个是桶的大小，支持流量突发增多时可以存多少的水（burst），另一个是水桶漏洞的大小（rate）。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使流突发（burst）到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。

令牌桶算法(token bucket)

spring cloud默认使用该算法

滚动时间窗(tumbling time window)

允许固定数量的请求进入(比如1秒取4个数据相加，超过25值就over)超过数量就拒绝或者排队，等下一个时间段进入。由于是在一个时间间隔内进行限制，如果用户在上个时间间隔结束前请求（但没有超过限制），同时在当前时间间隔刚开始请求（同样没超过限制），在各自的时间间隔内，这些请求都是正常的

间隔临界的一段时间内的请求就会超过系统限制，可能导致系统被压垮。

假如设定1分钟最多可以请求100次某个接口，如12:00:00-12:00:59时间段内没有数据请求但12:00:59-12:01:00时间段内突然并发100次请求，紧接着瞬间跨入下一个计数周期计数器清零；在12:01:00-12:01:01内又有100次请求。那么也就是说在时间临界点左右可能同时有2倍的峰值进行请求，从而造成后台处理请求加倍过载的bug，导致系统运营能力不足，甚至导致系统崩溃

滑动时间窗口(sliding time window)

窗口：需要定义窗口的大小
滑动：需要定义在窗口中滑动的大小，理论上滑动的大小不能超过窗口大小
滑动窗口算法是把固定时间片进行划分并且随着时间移动，移动方式为开始时间点变为时间列表中的第2个时间点，结束时间点增加一个时间点，不断重复，通过这种方式可以巧妙的避开计数器的临界点的问题

具体实现

客户端依赖引入

<!--resilience4j-ratelimiter-->
<dependency>
    <groupid>io.github.resilience4j</groupid>
    <artifactid>resilience4j-ratelimiter</artifactid>
</dependency>

客户端yml配置文件

####resilience4j ratelimiter 限流的例子
resilience4j:
  ratelimiter:
    configs:
      default:
        limitforperiod: 2 #在一次刷新周期内，允许执行的最大请求数
        limitrefreshperiod: 1s # 限流器每隔limitrefreshperiod刷新一次，将允许处理的最大请求数量重置为limitforperiod
        timeout-duration: 1 # 线程等待权限的默认等待时间
    instances:
      cloud-payment-service:
        baseconfig: default

客户端controller类方法使用注解@ratelimite

@getmapping(value = "/feign/pay/ratelimit/{id}")
@ratelimiter(name = "cloud-payment-service",fallbackmethod = "myratelimitfallback")
public string mybulkhead(@pathvariable("id") integer id){
    return payfeignapi.myratelimit(id);
}
public string myratelimitfallback(integer id,throwable t){
    return "你被限流了，禁止访问/(ㄒoㄒ)/~~";
}

到此这篇关于springcloud circuitbreaker断路器详解的文章就介绍到这了,更多相关springcloud circuitbreaker断路器内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！

SpringCloud CircuitBreaker断路器详解

2025年11月20日 • Java •我要评论