Webflux WebClient重试和Spring Cloud Circuit Breaker Resilience4J Retry模式走进了一个酒吧

问题描述

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

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

然后，第三方应用程序（不是我们的）开始变得不稳定，有时会因我们的请求而失败。我们必须实现某种重试逻辑。在执行重试逻辑（例如WebClient关联）之后，业务流程现在可以正常工作。 我们主要直接从框架中获取逻辑。例如，最近的SpringOne上来自@simon-baslé，“取消”，“重试”和“超时”的演讲提供了许多可行的示例。

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

另一方面，最近，越来越多的应用程序朝着Circuit Breaker模式发展。由Resilience4J支持的Spring Cloud Circuit Breaker项目是使用Resilience4J的流行实现，用于诸如Circuit Breaker，Bulkhead以及当然Retry的模式。

因此，我有一个问题，就重试而言，使用/组合这两种方法是否有好处？

将两者结合在一起会有所收获吗？有什么缺点吗？

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

谢谢

解决方法

我们（Resilience4j小组）已为CircuitBreaker，Retry和Timeout实现了自定义的Spring Reactor运算符。内部Retry和Timeout使用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项目。