在基于 Spring WebFlux 的响应式服务中，无论下游依赖（如 Service A）是否为同步 REST 接口，都应统一使用 WebClient 发起非阻塞调用，并始终返回 Mono 或 Flux，以保持整个调用链的响应式一致性。
在基于 spring webflux 的响应式服务中，无论下游依赖（如 service a）是否为同步 rest 接口，都应统一使用 `webclient` 发起非阻塞调用，并始终返回 `mono` 或 `flux`，以保持整个调用链的响应式一致性。
在构建响应式微服务（如 Service C）时，一个常见误区是认为“调用同步接口就必须用阻塞方式”，从而混用 RestTemplate 或手动线程池包装同步调用。这是错误的——响应式的本质不在于被调用方是否响应式，而在于调用方是否以非阻塞、事件驱动的方式管理 I/O。
WebClient 作为 Spring 官方推荐的响应式 HTTP 客户端，其底层基于 Netty，所有 I/O 操作天然异步且无阻塞。即使 Service A 是传统 Spring MVC 同步服务（返回 String/JSON 而非 Mono<string></string>），WebClient.get().uri(...).retrieve().bodyToMono(String.class) 仍会以完全非阻塞方式发起请求、等待响应、解析结果，并最终发布为 Mono。整个过程不占用 Tomcat 线程或阻塞事件循环线程。
✅ 正确做法：统一使用 WebClient，所有外部调用均返回 Mono
@Service
public class DependencyService {
private final WebClient webClient;
public DependencyService(WebClient.Builder builder) {
this.webClient = builder.build();
}
// 即使 Service A 是同步 Spring MVC 服务，也用 WebClient 封装为 Mono
public Mono<string> callServiceA() {
return webClient.get()
.uri("http://service-a/api/data")
.retrieve()
.bodyToMono(String.class);
}
// Service B 原生返回 Mono？同样用 WebClient 调用，语义一致
public Mono<string> callServiceB() {
return webClient.get()
.uri("http://service-b/api/data")
.retrieve()
.bodyToMono(String.class);
}
// 组合调用：自然支持响应式编排
public Mono<string> combinedResult() {
return Mono.zip(
callServiceA(),
callServiceB(),
(a, b) -> "A: " + a + " | B: " + b
);
}
}</string></string></string>
⚠️ 注意事项：
-
切勿在响应式服务中混用
RestTemplate：它会强制阻塞当前线程（如 Netty EventLoop 线程），导致吞吐量骤降、背压失效，甚至引发线程饥饿； -
无需为同步服务额外“转响应式”：不要用
Mono.fromCallable(() -> restTemplate.getForObject(...)).subscribeOn(Schedulers.boundedElastic())—— 这只是伪响应式，增加了调度开销且违背设计初衷； -
异常处理需统一：使用
.onStatus()或.bodyToMono(ErrorResponse.class)配合onErrorResume实现声明式错误恢复； -
超时与重试必须显式配置：
WebClient默认无超时，建议通过ExchangeStrategies和RetrySpec加强健壮性。
总结：响应式编程的边界在调用方。只要 Service C 是 WebFlux 应用，就应坚持“全链路响应式”原则——所有外部 HTTP 调用均由 WebClient 承载，统一建模为 Mono/Flux。这不仅保障了资源高效利用和高并发能力，更让组合、缓存、熔断等响应式操作成为可能。服务 A 的同步实现细节，对 Service C 的响应式契约而言，完全透明且无关紧要。
