断路器未将状态从 HALF_OPEN 更改为 CLOSED答案

【问题标题】：CircuitBreaker Not Changing State from HALF_OPEN to CLOSED断路器未将状态从 HALF_OPEN 更改为 CLOSED
【发布时间】：2020-08-31 03:47:02
【问题描述】：

我的 spring-boot 反应式应用程序中有这个断路器配置 -

CircuitBreakerConfig.custom().failureRateThreshold(5)
            .slowCallDurationThreshold(Duration.ofMillis(5000))
            .slidingWindowType(SlidingWindowType.COUNT_BASED)
            .slidingWindowSize(5)
            .permittedNumberOfCallsInHalfOpenState(5)
            .waitDurationInOpenState(Duration.ofMillis(30000))
            .slowCallRateThreshold(5)

然后我像这样调用上游 API -

return Mono.from(invokeUpstream(body, headers))
                .compose(CircuitBreakerOperator.of(circuitBreaker)).onErrorResume(this::fallback);

invokeUpstream 方法如下所示 -

Mono<ResponseEntity<String>> response = webClient.post()
                                                   .body(BodyInserters.fromValue(body))
                                                   .retrieve()
                                                   .onStatus(HttpStatus::is5xxServerError, clientResponse -> Mono.error(new BadGatewayException()))
                                                   .toEntity(String.class);

而 fallback 方法只是抛出异常 -

private Mono<ResponseEntity<String>> fallback(Throwable ex) {
    throw new BadGatewayException();
}

现在，当上游 API 返回 500 响应 5 次时，我可以看到 circuitBreaker 状态正在从 CLOSED 状态移动到 OPEN 状态，这是预期的。在 OPEN 状态下，它根据配置保持 30 秒。之后，它进入 HALF_OPEN 状态，问题从这里开始。即使上游 API 返回成功响应，它也永远不会进入 CLOSED 状态，它会永远保持在 HALF_OPEN 状态。

我在我的应用程序中使用这些依赖项 -

    <dependency>
        <groupId>io.github.resilience4j</groupId>
        <artifactId>resilience4j-circuitbreaker</artifactId>
        <version>1.3.1</version>
    </dependency>
    <dependency>
        <groupId>io.github.resilience4j</groupId>
        <artifactId>resilience4j-reactor</artifactId>
        <version>1.3.1</version>
    </dependency>

即使浏览了所有文档，我也不确定自己做错了什么。

【问题讨论】：

标签： spring-webflux project-reactor circuit-breaker resilience4j spring-reactor

【解决方案1】：

我发现了问题。我正在使用

检查断路器状态

circuitBreaker.tryAcquirePermission()

甚至在进行导致此问题的实际调用之前的方法。删除后，它可以正常工作。

【讨论】：