本文详解如何在 Spring WebFlux 中并行调用两个下游服务，即使其中任一调用失败（如网络超时、4xx/5xx 响应），仍能安全组合有效响应，生成包含 null 或空值字段的 CombinedResponse，避免因单点错误导致整体结果丢失。
本文详解如何在 Spring WebFlux 中并行调用两个下游服务，即使其中任一调用失败（如网络超时、4xx/5xx 响应），仍能安全组合有效响应，生成包含 `null` 或空值字段的 `CombinedResponse`，避免因单点错误导致整体结果丢失。
在响应式编程中，Mono.zip() 是组合多个 Mono 的常用操作符。但其默认行为是短路式容错：一旦任一源 Mono 发生错误或完成为空（Mono.empty()），zip 会立即取消其余源，并使整个组合流以错误或空完成——这与需求中“允许部分成功”的目标相悖。
根本原因在于：Reactor 明确禁止 null 值（Mono.just(null) 会抛出 NullPointerException），而 RxJava 1 中 Single.just(null) 的惯用模式在此不可直接迁移。
✅ 推荐方案：使用 Optional 封装可空结果
通过将每个服务返回的 Mono
1. 改造服务层（返回 Mono>）
class FirstService {
private final WebClient webClient;
Mono<Optional<FirstResponse>> get() {
return webClient.get()
.uri("https://api.example.com/first")
.retrieve()
.bodyToMono(FirstResponse.class)
.map(Optional::of) // 成功时包装为 Optional.of(result)
.onErrorReturn(Optional.empty()); // 失败时返回 Optional.empty()
}
}
class SecondService {
private final WebClient webClient;
Mono<Optional<SecondResponse>> get() {
return webClient.get()
.uri("https://api.example.com/second")
.retrieve()
.bodyToMono(SecondResponse.class)
.map(Optional::of)
.onErrorReturn(Optional.empty());
}
}⚠️ 注意：onErrorReturn(Optional.empty()) 比 onErrorResume(e -> Mono.just(Optional.empty())) 更简洁高效；若需区分错误类型（如仅忽略 WebClientException），可配合 onErrorResume(Class, fallback) 使用。
2. 组合控制器逻辑
@RestController
@RequestMapping("/api")
class CombinationController {
private final FirstService firstService;
private final SecondService secondService;
@GetMapping("/combined")
Mono<CombinedResponse> getCombined() {
return Mono.zip(
firstService.get(),
secondService.get()
)
.map(tuple -> {
Optional<FirstResponse> firstOpt = tuple.getT1();
Optional<SecondResponse> secondOpt = tuple.getT2();
return new CombinedResponse(
firstOpt.orElse(null), // 若为空则设为 null，符合 CombinedResponse 字段语义
secondOpt.orElse(null)
);
});
}
}3. 数据模型保持简洁
class CombinedResponse {
private final FirstResponse first;
private final SecondResponse second;
public CombinedResponse(FirstResponse first, SecondResponse second) {
this.first = first;
this.second = second;
}
// getters...
}✅ 此设计下：
- 若 firstService.get() 失败 → first = null，second 仍取自成功响应；
- 若两者均失败 → CombinedResponse{first=null, second=null}；
- 若两者均成功 → 完整填充；
- 所有调用始终并发执行，无阻塞、无顺序依赖。
? 替代方案对比（不推荐但需了解）
- Mono.when() + 手动收集：需额外状态管理，代码冗长且易出错；
- Flux.concat() 后 collectList()：失去结构化配对关系，需手动索引还原；
- 自定义 Mono.zipDelayError() 变体：Reactor 5.3+ 提供 zipDelayError，但仅延迟错误传播，仍无法解决 null 限制问题，最终仍需 Optional 或默认对象兜底。
✅ 最佳实践总结
| 场景 | 推荐做法 |
|---|---|
| 服务调用可能失败，且结果非必需 | 统一返回 Mono |
| 需保留原始异常信息用于日志/监控 | 在 onErrorReturn 前添加 .doOnError(log::warn) |
| 下游返回 404 等业务性“空响应” | 用 onStatus(HttpStatus::is4xxClientError, resp -> Mono.empty()) 过滤后再 map/optional |
| 未来扩展为 N 个服务组合 | 使用 Mono.zip(...) 重载方法或 Flux.zip(...) 配合 toList() |
通过 Optional 封装，你既遵守了 Reactor 的设计契约，又实现了与 RxJava 语义一致的“宽松组合”能力——这是 WebFlux 响应式服务编排中处理弱依赖场景的标准范式。
