时间戳

首页 > 解决方案 > Webflux WebClient 重试和Spring Cloud Circuit Breaker Resilience4J 重试模式走进一家吧

spring-webflux - Webflux WebClient 重试和Spring Cloud Circuit Breaker Resilience4J 重试模式走进一家吧

问题描述

想问一个关于两种技术的问题。

我们首先从一个必须调用其他第三方 rest API 的应用程序开始，因此，我们在 SpringBoot Webflux 项目中使用了 Webflux WebClient。到目前为止一切顺利，我们有一段时间有一个成功的应用程序。

然后第三方应用程序（不是我们的）开始变得不稳定，有时会在我们的请求上失败。我们必须实现某种重试逻辑。WebClient reties等重试逻辑实现后，业务流程正常。我们主要是直接从框架中获取逻辑。例如，@simon-baslé 在最近的 SpringOne 上的一次演讲中，Cancel、Retry 和 Timeouts 给出了许多工作示例。

.retryWhen(backoff(5, Duration.ofMillis(10).maxbackOff(Duration.ofSeconds(1)).jitter(0.4)).timeout(Duration.ofSeconds(5)

另一方面，最近有越来越多的应用程序转向断路器模式。由 Resilience4J 支持的 Spring Cloud Circuit Breaker 项目是一种流行的实现，它使用 Resilience4J 实现断路器、Bulkhead 等模式，当然还有重试。

因此，我有一个问题，在重试方面使用/组合两者是否有好处？

将两者结合在一起有什么好处吗？有什么缺点吗？

或者两者中只有一个就足够了，在这种情况下，请问哪一个？为什么？

谢谢

标签： spring-webfluxspring-webclientcircuit-breakerresilience4j

解决方案

我们（Resilience4j 团队）已经为 CircuitBreaker、Retry 和 Timeout 实现了自定义 Spring Reactor 操作符。内部重试和超时使用来自 Spring Reactor 的运算符，但 Resilience4j 在其之上添加了功能：

  1. 通过配置文件对 Retry、Timeout 和 CircuitBreaker 进行外部配置
  2. Spring Cloud Config 支持动态调整配置
  3. 指标，指标，指标；）

请参阅 https://resilience4j.readme.io/docs/examples-1和https://resilience4j.readme.io/docs/getting-started-3

您甚至可以使用注释使其更简单：

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

private Mono<String> fallback(String param1, TimeoutException ex) {
    return ...;
}

请注意，我们正在提供我们自己的 Spring Boot 启动器。我不是在谈论 Spring Cloud CircuitBreaker 项目。

推荐阅读