本文介绍如何在 Spring WebFlux 中根据 HTTP 响应（如 Retry-After 头或自定义状态码 106 及其携带的 retryTime）动态调整重试间隔，替代固定退避策略，提升对服务端限流/降级策略的适应性。
本文介绍如何在 spring webflux 中根据 http 响应（如 `retry-after` 头或自定义状态码 106 及其携带的 `retrytime`）动态调整重试间隔，替代固定退避策略，提升对服务端限流/降级策略的适应性。
在 Spring WebFlux 的响应式编程模型中，RetryBackoffSpec 提供了简洁的指数退避重试能力，但其退避时长（如 backoff(5, ofSeconds(10))）是静态预设的，无法感知上游服务返回的动态重试建议（例如 HTTP 429 Too Many Requests 响应中的 Retry-After 头，或自定义错误码 106 中附带的 retryTime: 37 秒）。为实现真正“服务端驱动”的弹性重试，需绕过 RetryBackoffSpec，转而使用底层 Retry 抽象并自定义 generateCompanion 逻辑。
核心思路是：基于 RetrySignal 中的异常信息（如 WebClientResponseException），解析响应头或响应体，提取服务端指定的重试延迟值，并据此动态生成 Mono.delay(...) 作为下一次重试的触发时机。
以下是一个生产就绪的 DynamicRetrySpec 实现，支持两种常见场景：
- ✅ 标准 429 Too Many Requests + Retry-After（秒级整数）
- ✅ 自定义业务错误码（如 106）+ 自定义响应体字段（如 { "code": 106, "retryTime": 45 }）
private static class DynamicRetrySpec extends Retry {
private final int maxRetries;
private final Duration defaultBackoff;
private final ObjectMapper objectMapper; // 用于解析 JSON 响应体（可选）
public DynamicRetrySpec(int maxRetries, Duration defaultBackoff) {
this(maxRetries, defaultBackoff, new ObjectMapper());
}
public DynamicRetrySpec(int maxRetries, Duration defaultBackoff, ObjectMapper objectMapper) {
this.maxRetries = maxRetries;
this.defaultBackoff = defaultBackoff;
this.objectMapper = objectMapper;
}
@Override
public Publisher> generateCompanion(Flux<retrysignal> retrySignals) {
return retrySignals.flatMap(this::getRetry);
}
private Mono<long> getRetry(Retry.RetrySignal rs) {
Throwable failure = rs.failure();
int currentRetry = rs.totalRetries();
if (currentRetry >= maxRetries) {
log.warn("Max retries ({}) exhausted for error: {}", maxRetries, failure.getMessage());
throw Exceptions.propagate(failure);
}
Duration delay = Duration.ZERO;
if (failure instanceof WebClientResponseException webEx) {
// 场景1：检查 Retry-After 头（标准 429）
String retryAfter = webEx.getHeaders().getFirst("Retry-After");
if (retryAfter != null && !retryAfter.trim().isEmpty()) {
try {
delay = Duration.ofSeconds(Long.parseLong(retryAfter.trim()));
log.debug("Using Retry-After header: {}s", delay.getSeconds());
} catch (NumberFormatException ignored) {
// 若非数字，忽略，走默认回退
}
}
// 场景2：自定义错误码 106，解析响应体中的 retryTime
if (delay.isZero() && webEx.getRawStatusCode() == 106) {
delay = parseRetryTimeFromBody(webEx.getResponseBodyAsString());
}
}
// 若未从响应中提取到有效 delay，则使用默认退避
if (delay.isZero()) {
delay = defaultBackoff;
}
log.info("Retry #{} scheduled in {}ms (status: {}, reason: {})",
currentRetry + 1, delay.toMillis(),
failure instanceof WebClientResponseException ?
((WebClientResponseException) failure).getRawStatusCode() : "N/A",
failure.getClass().getSimpleName());
return Mono.delay(delay).thenReturn((long) currentRetry);
}
private Duration parseRetryTimeFromBody(String body) {
if (body == null || body.trim().isEmpty()) return Duration.ZERO;
try {
JsonNode node = objectMapper.readTree(body);
int retryTime = node.path("retryTime").asInt(-1);
if (retryTime > 0) {
return Duration.ofSeconds(retryTime);
}
} catch (Exception e) {
log.warn("Failed to parse retryTime from response body", e);
}
return Duration.ZERO;
}
}</long></retrysignal>
使用方式（集成到 WebClient 链路）：
webClient.post()
.uri("/v1/device/grant")
.bodyValue(params)
.retrieve()
.onStatus(status -> status.value() == 106, clientResponse ->
clientResponse.bodyToMono(String.class)
.map(body -> new WebClientResponseException(106, "Custom Retry Required",
clientResponse.headers().asHttpHeaders(), body.getBytes(), StandardCharsets.UTF_8)))
.bodyToMono(MyResponse.class)
.retryWhen(new DynamicRetrySpec(3, Duration.ofSeconds(5)))
.doOnSuccess(result -> handleResponse(result, grantMapEntry, deviceInfo))
.onErrorResume(throwable -> {
log.error("All retries failed for device request", throwable);
return Mono.empty(); // 或发布失败事件
})
.subscribe();
⚠️ 关键注意事项：
- RetrySignal.failure() 必须是 WebClientResponseException 类型才能获取响应头/体；确保你的错误传播路径未被意外包装（如避免 Mono.error(new RuntimeException(ex))）。
- 对于非 4xx/5xx 状态码（如 106），需显式调用 onStatus 将其转换为 WebClientResponseException，否则 retryWhen 不会触发。
- Mono.delay() 返回的是 Mono
，仅作计时用途，其发射值不影响后续流程；真正的重试由 Reactor 内部调度器驱动。 - 动态延迟不参与 jitter 计算（因 jitter() 是 RetryBackoffSpec 特有 API），如需抖动，需手动在 parseRetryTimeFromBody 或 getBackOffDelayFromHeaders 中添加随机偏移（例如 delay.plusMillis(ThreadLocalRandom.current().nextLong(0, delay.toMillis() / 10))）。
通过该方案，客户端重试行为完全与服务端治理策略对齐，既避免盲目轮询加重服务压力，又保障了请求最终可达性，是构建高韧性响应式微服务的关键实践之一。
