Spring-Cloud-CircuitBreaker-Resilience4j （3.1.1）

介绍

Resilience4j 是一个专为函数式编程而设计的轻量级容错库。Resilience4j 提供高阶函数（装饰器），以增强任何功能接口、lambda 表达式或方法引用，包括断路器、速率限制器、重试或隔板。您可以在任何函数接口、lambda 表达式或方法引用上堆叠多个装饰器。优点是您可以选择所需的装饰器，而没有别的。
注意：Resilience4j 2 需要 Java 17。

Resilience4j 提供高阶函数（装饰器），以增强任何功能接口、lambda 表达式或方法引用，包括断路器、速率限制器、重试或隔板。您可以在任何函数接口、lambda 表达式或方法引用上堆叠多个装饰器。优点是您可以选择所需的装饰器，而没有别的。

使用 Resilience4j，可不全部使用，可以选择您需要的东西。

示例

以下示例演示如何使用 CircuitBreaker 和 Retry 修饰 lambda 表达式，以便在发生异常时重试调用 3 次。

您可以配置重试之间的等待间隔，也可以配置自定义回退算法。

该示例使用 Vavr 的 Try monad 从异常中恢复，并在所有重试都失败时调用另一个 lambda 表达式作为回退。

// 创建一个默认配置的CircuitBreaker 
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("backendService");// 创建一个默认配置的Retry
// 3次重试，每次间隔500ms
Retry retry = Retry.ofDefaults("backendService");// Create a Bulkhead with default configuration
Bulkhead bulkhead = Bulkhead.ofDefaults("backendService");Supplier<String> supplier = () -> backendService.doSomething(param1, param2)// Decorate your call to backendService.doSomething() 
// with a Bulkhead, CircuitBreaker and Retry
// **note: you will need the resilience4j-all dependency for this
Supplier<String> decoratedSupplier = Decorators.ofSupplier(supplier).withCircuitBreaker(circuitBreaker).withBulkhead(bulkhead).withRetry(retry)  .decorate();// When you don't want to decorate your lambda expression,
// but just execute it and protect the call by a CircuitBreaker.
String result = circuitBreaker.executeSupplier(backendService::doSomething);// You can also run the supplier asynchronously in a ThreadPoolBulkheadThreadPoolBulkhead threadPoolBulkhead = ThreadPoolBulkhead.ofDefaults("backendService");// The Scheduler is needed to schedule a timeout 
// on a non-blocking CompletableFuture
ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(3);
TimeLimiter timeLimiter = TimeLimiter.of(Duration.ofSeconds(1));CompletableFuture<String> future = Decorators.ofSupplier(supplier).withThreadPoolBulkhead(threadPoolBulkhead).withTimeLimiter(timeLimiter, scheduledExecutorService).withCircuitBreaker(circuitBreaker).withFallback(asList(TimeoutException.class, CallNotPermittedException.class, BulkheadFullException.class),  throwable -> "Hello from Recovery").get().toCompletableFuture();

所有核心模块和 Decorators 类

• resilience4j-all 弹性4J-全部

Core modules 核心模块

• resilience4j-circuitbreaker：熔断
• resilience4j-ratelimiter：速率限制
• resilience4j-bulkhead： 舱壁
• resilience4j-retry：自动重试（同步和异步）
• resilience4j-cache：结果缓存
• resilience4j-timelimiter：超时处理

Add-on modules 附加模块

• resilience4j-feign：假装适配器
• resilience4j-consumer：循环缓冲区事件消费者
• resilience4j-kotlin：Kotlin 协程支持
• resilience4j-vavr：Vavr 支持

Frameworks modules 框架模块

• resilience4j-spring-boot3: Spring Boot 3 Starter
• resilience4j-spring-boot2: Spring Boot 2 Starter
• resilience4j-micronaut: Micronaut Starter

Reactive modules 电抗模块

• resilience4j-rxjava2：自定义 RxJava2 运算符
• resilience4j-rxjava3：自定义 RxJava3 运算符
• resilience4j-reactor：定制弹簧反应器操作器

Metrics modules 指标模块

• resilience4j-micrometer： 微米度量导出器
• resilience4j-metrics：Dropwizard 指标导出器

与 Netflix Hystrix 的比较

1. 在 Hystrix 中，对外部系统的调用必须包装在 HystrixCommand 中。相比之下，resilience4j提供高阶函数（装饰器），以增强任何功能接口、lambda 表达式或带有断路器、限速器或隔板的方法引用。此外，resilience4j还提供装饰器来重试失败的调用或缓存调用结果。您可以在任何函数接口、lambda 表达式或方法引用上堆叠多个装饰器。这意味着，您可以将 Bulkhead、RateLimiter 和 Retry 装饰器与 CircuitBreaker 装饰器组合在一起。优点是您可以选择所需的装饰器，而没有其他选择。任何修饰的函数都可以使用 CompletableFuture 或 RxJava 同步或异步执行。
2. Hystrix 仅在半开状态下执行一次执行，以确定是否关闭 CircuitBreaker。resilience4j允许执行可配置的执行次数，并将结果与可配置的阈值进行比较，以确定是否关闭断路器。
3. resilience4j提供自定义 Reactor 或 RxJava 运算符，以使用断路器、隔板或速率限制器装饰任何反应类型。
4. Hystrix 和此库发出事件流，这些事件流对系统操作员监控有关执行结果和延迟的指标很有用。

核心模块

CircuitBreaker 断路器

介绍

断路器通过有限状态机实现，该状态机具有三种正常状态：CLOSED、OPEN 和 HALF_OPEN 以及两种特殊状态 DISABLED 和 FORCED_OPEN。

CircuitBreaker 使用滑动窗口来存储和聚合调用结果。您可以在基于计数的滑动窗口和基于时间的滑动窗口之间进行选择。基于计数的滑动窗口聚合了最后 N 次调用的结果。基于时间的滑动窗口聚合了最后 N 秒的调用结果。

基于计数的滑动窗口

基于计数的滑动窗口是通过 N 个测量值的圆形阵列实现的。

如果计数窗口大小为 10，则圆形数组始终具有 10 个测量值。

滑动窗口以增量方式更新总聚合。记录新的呼叫结果时，总聚合将更新。当驱逐最早的测量值时，将从总聚合中减去该测量值，并重置存储桶。（逐出时减法）

检索 Snapshot 的时间是常量 O（1），因为 Snapshot 是预先聚合的，并且与窗口大小无关。

此实现的空间要求（内存消耗）应为 O（n）。

基于时间的滑动窗口

基于时间的滑动窗口是通过 N 个部分聚合（桶）的循环数组实现的。

如果时间窗口大小为 10 秒，则圆形数组始终具有 10 个部分聚合（存储桶）。每个存储桶聚合在特定纪元秒内发生的所有调用的结果。（部分聚合）。圆形数组的 head 桶存储当前 epoch 秒的调用结果。其他部分聚合存储前几秒的调用结果。

滑动窗口不会单独存储调用结果（元组），而是以增量方式更新部分聚合（存储桶）和总聚合。

当记录新的呼叫结果时，总聚合将以增量方式更新。当最旧的存储桶被逐出时，将从总聚合中减去该存储桶的部分总聚合，并重置该存储桶。（逐出时减法）

检索 Snapshot 的时间是常数 O（1），因为 Snapshot 是预先聚合的，并且与时间窗口大小无关。

此实现的空间要求（内存消耗）应几乎为常量 O（n），因为调用结果（元组）不是单独存储的。仅创建 N 个部分聚合和 1 个总聚合。

部分聚合由 3 个整数组成，用于计算失败呼叫数、慢速呼叫数和呼叫总数。一个长，用于存储所有调用的总持续时间。

故障率和慢速请求率阈值

情况一：当故障率等于或大于可配置阈值时，断路器的状态将从 CLOSED 更改为 OPEN。例如，当超过 50% 的请求失败时。

默认情况下，所有异常都算作失败。可以定义应计为失败的异常列表。然后，所有其他异常都算作成功，除非它们被忽略。也可以忽略异常，这样它们既不算作失败也不算成功。

情况二：当慢速调用的百分比等于或大于可配置的阈值时，断路器也会从 CLOSED 更改为 OPEN。例如，当超过 50% 的请求时间超过 5 秒时。这有助于在外部系统实际无响应之前减少外部系统的负载。

只有在记录了最小呼叫数的情况下，才能计算故障率和慢速呼叫率。例如，如果所需的最小呼叫数为 10，则必须至少记录 10 个呼叫，然后才能计算故障率。如果仅评估了 9 个呼叫，即使所有 9 个呼叫都失败，断路器也不会跳闸打开。

CircuitBreaker 在 OPEN 时拒绝带有 的 CallNotPermittedException 请求。等待时间过后，断路器状态将从 OPEN 更改为 HALF_OPEN，并允许可配置的调用次数，以查看后端是否仍然不可用或已再次可用。进一步的请求将被拒绝， CallNotPermittedException 直到 所有允许的呼叫都完成。

如果故障率或慢速调用率等于或大于配置的阈值，则状态将变回 OPEN。如果故障率和慢速调用率低于阈值，则状态将变回 CLOSED。

断路器支持另外两种特殊状态，即 DISABLED（始终允许访问）和 FORCED_OPEN（始终拒绝访问）。在这两种状态下，不会生成断路器事件（状态转换除外），也不会记录任何指标。退出这些状态的唯一方法是触发状态转换或重置断路器。

CircuitBreaker 是线程安全的，如下所示：

• CircuitBreaker 的状态存储在 AtomicReference 中
• CircuitBreaker 使用原子操作通过无副作用功能更新状态。
• 从滑动窗口录制通话和读取快照是同步的

这意味着应该保证原子性，并且只有一个线程能够在某个时间点更新状态或滑动窗口。

但 CircuitBreaker 不会同步函数调用。这意味着函数调用本身不是关键部分的一部分。否则，断路器将引入巨大的性能损失和瓶颈。缓慢的函数调用将对整体性能/吞吐量产生巨大的负面影响。

如果 20 个并发线程请求执行函数的权限，并且 CircuitBreaker 的状态为关闭，则允许所有线程调用该函数。即使滑动窗口大小为 15。滑动窗口并不意味着只允许同时运行 15 个调用。如果要限制并发线程数，请使用 Bulkhead。可以组合使用隔板和断路器。

创建 CircuitBreakerRegistry

Resilience4j 带有一个基于 ConcurrentHashMap 的内存 CircuitBreakerRegistry ，它提供线程安全性和原子性保证。您可以使用 CircuitBreakerRegistry 管理（创建和检索）CircuitBreaker 实例。您可以为所有 CircuitBreaker 实例创建具有全局默认值 CircuitBreakerConfig 的 CircuitBreakerRegistry，如下所示。

CircuitBreakerRegistry circuitBreakerRegistry = CircuitBreakerRegistry.ofDefaults();

创建和配置断路器

您可以提供自己的自定义全局 CircuitBreakerConfig .要创建自定义全局 CircuitBreakerConfig，可以使用 CircuitBreakerConfig 构建器。您可以使用构建器配置以下属性。

Config property Config	Default Value	Description
failureRateThreshold	50	以百分比为单位配置故障率阈值。 当故障率等于或大于阈值时，断路器将转换为打开并开始短路呼叫。
slowCallRateThreshold	100	以百分比为单位配置阈值。当呼叫持续时间大于 slowCallDurationThreshold 当慢速呼叫的百分比等于或大于阈值时，断路器将转换为打开并开始短路呼叫。
slowCallDurationThreshold	60000 [ms]	Configures the duration threshold above which calls are considered as slow and increase the rate of slow calls. 配置持续时间阈值，超过该阈值的呼叫将被视为慢速呼叫，并提高慢速呼叫的速率。
permittedNumberOfCalls InHalfOpenState	10	配置断路器半开时允许的呼叫次数。
maxWaitDurationInHalfOpenState	0 [ms]	配置最大等待持续时间，该持续时间控制断路器在切换为打开之前可以保持半开状态的最长时间。 值 0 表示断路器将在半开状态下无限等待，直到完成所有允许的调用。
slidingWindowType	COUNT_BASED	配置滑动窗口的类型，该滑动窗口用于在断路器关闭时记录呼叫结果。 滑动窗口可以是基于计数的，也可以是基于时间的。 如果滑动窗口为COUNT_BASED，则记录并汇总最后的 slidingWindowSize 呼叫。 如果滑动窗口TIME_BASED，则记录并汇总最后 slidingWindowSize 几秒的呼叫。
slidingWindowSize	100	配置滑动窗口的大小，该滑动窗口用于记录断路器关闭时的呼叫结果。
minimumNumberOfCalls	100	配置断路器计算错误率或慢速呼叫率之前所需的最小呼叫数（每个滑动窗口周期）。 例如，如果 minimumNumberOfCalls 为 10，则必须至少记录 10 个调用，然后才能计算失败率。 如果只记录了 9 个请求，即使所有 9 个请求都失败，断路器也不会转换为打开。
waitDurationInOpenState	60000 [ms]	断路器在从打开状态转换到半打开状态之前应等待的时间。
automaticTransition FromOpenToHalfOpenEnabled	false	如果设置为 true，则表示 CircuitBreaker 将自动从打开状态转换为半打开状态，无需调用即可触发转换。创建一个线程来监视 CircuitBreakers 的所有实例，以便在 waitDurationInOpenState 通过后将它们转换为HALF_OPEN。然而，如果设置为 false，则仅在进行调用时才会转换为 HALF_OPEN，即使在传递 waitDurationInOpenState 之后也是如此。这样做的好处是没有线程监控所有断路器的状态。
recordExceptions	empty	记录为失败并因此增加失败率的异常列表。 任何匹配或从其中一个列表继承的异常都算作失败，除非通过 ignoreExceptions 显式忽略 . 如果指定异常列表，则所有其他异常都算作成功，除非 ignoreExceptions 显式忽略它们。
ignoreExceptions	empty	被忽略且既不算作失败也不算成功的异常列表。 任何匹配或从其中一个列表继承的异常都不会算作失败或成功，即使异常是 recordExceptions 的一部分。
recordFailurePredicate	throwable -> true  默认情况下，所有异常都作为失败进行重构。	一个自定义谓词，用于评估是否应将异常记录为失败。 如果异常应计为失败，则谓词必须返回 true。如果异常，则谓词必须返回 false 应算作成功，除非 ignoreExceptions 显式忽略异常。
ignoreExceptionPredicate	throwable -> false  默认情况下，不会忽略任何异常。	一个自定义谓词，用于评估是否应忽略异常，并且既不算作失败也不算成功。 如果应忽略异常，则 Predicate 必须返回 true。 如果异常应计为失败，则谓词必须返回 false。

// Create a custom configuration for a CircuitBreaker
CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom().failureRateThreshold(50).slowCallRateThreshold(50).waitDurationInOpenState(Duration.ofMillis(1000)).slowCallDurationThreshold(Duration.ofSeconds(2)).permittedNumberOfCallsInHalfOpenState(3).minimumNumberOfCalls(10).slidingWindowType(SlidingWindowType.TIME_BASED).slidingWindowSize(5).recordException(e -> INTERNAL_SERVER_ERROR.equals(getResponse().getStatus())).recordExceptions(IOException.class, TimeoutException.class).ignoreExceptions(BusinessException.class, OtherBusinessException.class).build();// Create a CircuitBreakerRegistry with a custom global configuration
CircuitBreakerRegistry circuitBreakerRegistry = CircuitBreakerRegistry.of(circuitBreakerConfig);// Get or create a CircuitBreaker from the CircuitBreakerRegistry 
// with the global default configuration
CircuitBreaker circuitBreakerWithDefaultConfig = circuitBreakerRegistry.circuitBreaker("name1");// Get or create a CircuitBreaker from the CircuitBreakerRegistry 
// with a custom configuration
CircuitBreaker circuitBreakerWithCustomConfig = circuitBreakerRegistry.circuitBreaker("name2", circuitBreakerConfig);

您可以添加可由多个 CircuitBreaker 实例共享的配置。

CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom().failureRateThreshold(70).build();circuitBreakerRegistry.addConfiguration("someSharedConfig", config);CircuitBreaker circuitBreaker = circuitBreakerRegistry.circuitBreaker("name", "someSharedConfig");

您可以覆盖配置。

CircuitBreakerConfig defaultConfig = circuitBreakerRegistry.getDefaultConfig();CircuitBreakerConfig overwrittenConfig = CircuitBreakerConfig.from(defaultConfig).waitDurationInOpenState(Duration.ofSeconds(20)).build();

如果您不想使用 CircuitBreakerRegistry 管理 CircuitBreaker 实例，也可以直接创建实例。

// Create a custom configuration for a CircuitBreaker
CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom().recordExceptions(IOException.class, TimeoutException.class).ignoreExceptions(BusinessException.class, OtherBusinessException.class).build();CircuitBreaker customCircuitBreaker = CircuitBreaker.of("testName", circuitBreakerConfig);

CircuitBreaker 使用案例

pom文件

<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文件配置

spring:cloud:circuitbreaker:enabled: truegroup:enabled: true #没开分组永远不用分组的配置。精确优先、分组次之(开了分组)、默认最后# Resilience4j CircuitBreaker 按照次数：COUNT_BASED 的例子
#  6次访问中当执行方法的失败率达到50%时CircuitBreaker将进入开启OPEN状态(保险丝跳闸断电)拒绝所有请求。
#  等待5秒后，CircuitBreaker 将自动从开启OPEN状态过渡到半开HALF_OPEN状态，允许一些请求通过以测试服务是否恢复正常。
#  如还是异常CircuitBreaker 将重新进入开启OPEN状态；如正常将进入关闭CLOSE闭合状态恢复正常处理请求。
# 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.Exceptioninstances:cloud-payment-service:baseConfig: default

Controller层

package com.atguigu.cloud.controller;import com.atguigu.cloud.apis.PayFeignApi;
import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import jakarta.annotation.Resource;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;/*** @auther zzyy* @create 2023-11-13 14:54* Resilience4j CircuitBreaker 的例子*/
@RestController
public class OrderCircuitController
{@Resourceprivate 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ㄒ)/~~";}
}

Bulkhead（隔离）

介绍

Resilience4j 提供了两种隔离模式的实现，可用于限制并发执行的数量：

• a SemaphoreBulkhead 使用信号量
• a FixedThreadPoolBulkhead 使用有界队列和固定线程池。

它应该 SemaphoreBulkhead 在各种线程和 I/O 模型中都能很好地工作。它基于信号量，与 Hystrix 不同，它不提供“影子”线程池选项。客户端需要确保正确的线程池大小，该大小将与隔板配置一致。

创建 BulkheadRegistry

就像 CircuitBreaker 模块一样，此模块提供了一个内存 BulkheadRegistry 中和一个 ThreadPoolBulkheadRegistry 可用于管理（创建和检索）Bulkhead 实例的内存。

BulkheadRegistry bulkheadRegistry = BulkheadRegistry.ofDefaults();ThreadPoolBulkheadRegistry threadPoolBulkheadRegistry = ThreadPoolBulkheadRegistry.ofDefaults();

创建和配置隔板

Config property	Default value	Description
maxConcurrentCalls	25	隔离允许的最大并行执行量
maxWaitDuration	0	尝试进入饱和隔板时应阻塞并发的最大时间。

// Create a custom configuration for a Bulkhead
BulkheadConfig config = BulkheadConfig.custom().maxConcurrentCalls(150).maxWaitDuration(Duration.ofMillis(500)).build();// Create a BulkheadRegistry with a custom global configuration
BulkheadRegistry registry = BulkheadRegistry.of(config);// Get or create a Bulkhead from the registry - 
// bulkhead will be backed by the default config
Bulkhead bulkheadWithDefaultConfig = registry.bulkhead("name1");// Get or create a Bulkhead from the registry, 
// use a custom configuration when creating the bulkhead
Bulkhead bulkheadWithCustomConfig = registry.bulkhead("name2", custom);

创建和配置 ThreadPoolBulkhead

可以提供自定义全局 ThreadPoolBulkheadConfig。若要创建自定义全局 ThreadPoolBulkheadConfig，可以使用 ThreadPoolBulkheadConfig 生成器。您可以使用构建器配置以下属性。

Config property	Default value	Description
maxThreadPoolSize	Runtime.getRuntime()  .availableProcessors()	配置最大线程池大小。
coreThreadPoolSize	Runtime.getRuntime() .availableProcessors（） - 1	配置核心线程池大小
queueCapacity	100	配置队列的容量。
keepAliveDuration	20 [ms]	当线程数大于核心数时，这是多余的空闲线程在终止之前等待新任务的最长时间。
writableStackTraceEnabled	true	引发隔板异常时输出堆栈跟踪错误。 如果为 false，则输出带有隔板异常的单行。

ThreadPoolBulkheadConfig config = ThreadPoolBulkheadConfig.custom().maxThreadPoolSize(10).coreThreadPoolSize(2).queueCapacity(20).build();// Create a BulkheadRegistry with a custom global configuration
ThreadPoolBulkheadRegistry registry = ThreadPoolBulkheadRegistry.of(config);// Get or create a ThreadPoolBulkhead from the registry - 
// bulkhead will be backed by the default config
ThreadPoolBulkhead bulkheadWithDefaultConfig = registry.bulkhead("name1");// Get or create a Bulkhead from the registry, 
// use a custom configuration when creating the bulkhead
ThreadPoolBulkheadConfig custom = ThreadPoolBulkheadConfig.custom().maxThreadPoolSize(5).build();ThreadPoolBulkhead bulkheadWithCustomConfig = registry.bulkhead("name2", custom);

Bulihead使用案例

pom文件

<!--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秒，过时不候进舱壁兜底fallbackinstances:cloud-payment-service:baseConfig: defaulttimelimiter:configs:default:timeout-duration: 20s

Controller层

@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ㄒ)/~~";
}

RateLimiter限流

限流是准备 API 以进行扩展并建立服务的高可用性和可靠性的必要技术。而且，这种技术还带有一大堆不同的选项，用于如何处理检测到的限制盈余，或者您要限制哪种类型的请求。您可以简单地拒绝此超限请求，或者构建一个队列以稍后执行它们，或者以某种方式组合这两种方法。

内部

Resilience4j 提供了一个 RateLimiter，它将从纪元开始的所有纳秒拆分为多个周期。每个周期的持续时间由 配置。 RateLimiterConfig.limitRefreshPeriod 在每个周期开始时，RateLimiter 将活动权限数设置为 RateLimiterConfig.limitForPeriod 。

对于 RateLimiter 调用者来说，它看起来确实是这样的，但对于 AtomicRateLimiter 实现来说，如果未主动使用 RateLimiter，则在后台进行了一些优化，这些优化将跳过此刷新。

限流使用

pom文件

<!--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刷新一次，将允许处理的最大请求数量重置为limitForPeriodtimeout-duration: 1 # 线程等待权限的默认等待时间instances:cloud-payment-service:baseConfig: default

controller层

@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ㄒ)/~~";
}