RestClient、WebClient 与 RestTemplate 的选型

概述

在前文剖析了 Spring MVC 如何优雅地处理外部传入的 HTTP 请求后，本文将视角转向服务如何作为客户端发起 HTTP 调用。无论是传统的 RestTemplate、响应式的 WebClient，还是新兴的 RestClient，Spring 都提供了一脉相承的模板化访问与消息转换能力。理解它们的内部机制与适用边界，是在微服务架构中构建稳健通信层的基石。

随着微服务架构的普及，服务间的 HTTP 调用成为日常。Spring 生态中的 HTTP 客户端经历了从同步阻塞的 RestTemplate 到响应式全双工的 WebClient，再到重新拥抱同步但兼具现代优雅设计的 RestClient 的演变。这不仅仅是 API 的变迁，更是对系统吞吐量、资源利用率和编程模型的深度权衡。本文将深入三种客户端的内部架构，剖析其线程模型与连接池机制，结合真实的性能与资源对比，为读者提供一份明确、可落地的选型与优化指南。

核心要点

• RestTemplate：同步阻塞，基于模板方法模式，依赖可插拔的 ClientHttpRequestFactory，需谨慎管理连接池。
• WebClient：响应式非阻塞，基于 Reactor，支持背压和函数式组合，适合高并发、低延迟网关。
• RestClient：同步 API + 现代设计，底层可基于非阻塞引擎，旨在逐步替代 RestTemplate。
• 选型核心要素：IO 模型、线程模型、连接池管理、错误处理、可测试性。

文章组织架构图

flowchart 
    subgraph 1 [1. 三种客户端总览与演进脉络]
        direction LR
        1.1[发展简史]
        1.2[核心差异速览]
        1.3[与Spring生态集成]
    end

    subgraph 2 [2. RestTemplate 同步阻塞的基石]
        2.1[doExecute 源码分析]
        2.2[ClientHttpRequestFactory 扩展点]
        2.3[ClientHttpRequestInterceptor 链]
        2.4[连接池管理]
        2.5[同步阻塞模型问题]
    end

    subgraph 3 [3. WebClient 响应式非阻塞的先锋]
        3.1[构建器与核心接口]
        3.2[Reactor Netty 整合]
        3.3[ExchangeFilterFunction 链]
        3.4[超时控制与背压]
        3.5[事件循环线程模型]
    end

    subgraph 4 [4. RestClient 同步API的现代重构]
        4.1[出现背景与定位]
        4.2[内部架构分析]
        4.3[流式API优势]
        4.4[与RestTemplate对比]
    end

    1 --> 2
    1 --> 3
    1 --> 4
    
    2 --> 5[5. 深度对比 IO模型 线程与性能]
    3 --> 5
    4 --> 5

    5 --> 6[6. 选型决策框架与迁移策略]
    6 --> 7[7. 生产事故排查专题]
    6 --> 8[8. 面试高频专题]

架构图说明

• 总览说明：全文共 8 个模块。架构图清晰地展示了从客户端演进开始，逐个深入三种客户端的内部构造，再汇聚为深度对比与决策框架，最终通过生产事故与面试专题进行实战闭环的认知路径。
• 逐模块说明：
  • 模块 1 建立全局视角，梳理发展脉络。
  • 模块 2、3、4 分别对三种客户端进行“外科手术式”剖析，是全文的技术核心。每个模块都深入其内部架构、线程模型和关键扩展点。
  • 模块 5、6 将前三部分的知识进行整合对比，产出具有工业指导意义的决策框架。
  • 模块 7、8 是知识的应用与检验，确保内容从理论到实践，从实践到面试的贯通。
• 关键结论：HTTP 客户端的选择是 IO 模型与编程模型的综合权衡，不存在银弹，只有最适合场景的拼图。

1. 三种客户端总览与演进脉络

1.1 发展简史与背景

Spring 在 HTTP 客户端领域的演进，是 Java 生态从同步阻塞模型向响应式非阻塞模型迁移的一个缩影。

• Spring 3.0 (2009年)：RestTemplate 诞生。它旨在简化与 RESTful 服务的交互，通过模板方法模式封装了请求创建、执行、消息转换和响应处理的繁琐样板代码。在当时的 Servlet 容器和同步编程模型下，RestTemplate 是事实标准。
• Spring 5.0 (2017年)：WebClient 随 WebFlux 推出。为了拥抱 Reactive Streams 规范，Spring 推出了响应式的 WebClient。它基于 Project Reactor，支持非阻塞 I/O，能够以少量固定线程处理大量并发请求，成为响应式栈的标配。
• Spring 6.0 / Spring Boot 3.0 (2022年)：RestClient 应运而生。RestTemplate 由于历史包袱和同步阻塞模型，其 API 设计越来越显得繁琐，且 Spring 团队宣布将其置于“维护模式”。为了给同步开发模型提供一个更现代、更优雅的选择，并借力于 Java 11 的 HttpClient 等底层非阻塞引擎，RestClient 带着流式 API 和更佳的默认配置正式亮相。

1.2 核心差异速览表

特性	RestTemplate	WebClient	RestClient
推出版本	Spring 3.0	Spring 5.0	Spring 6.1
核心 IO 模型	同步阻塞 (Blocking I/O)	响应式非阻塞 (Reactive Non-blocking I/O)	同步 API，底层可为非阻塞实现
编程模型	命令式、模板方法	声明式、函数式组合	命令式、流式 API
线程模型	每请求一线程（或线程池线程），线程会阻塞	少量事件循环线程，线程不阻塞	与底层实现相关，通常复用调用线程
主要返回值	直接返回对象或 ResponseEntity<T>	Mono<T> 或 Flux<T>	直接返回对象或 ResponseEntity<T>
背压支持	无	天然支持	无
维护状态	维护模式（不再加新特性）	活跃开发	活跃开发（推荐同步替代品）
适用场景	遗留系统、低并发、简单任务	高并发网关、流式处理、响应式全栈	新项目同步调用首选

1.3 与 Spring 生态的集成

三者都深度集成了 Spring 的核心基础设施，这是它们作为 Spring 一等公民的优势：

• HTTP 消息转换器 (HttpMessageConverter)：三种客户端都依赖前文详解的 HttpMessageConverter 机制，完成 Java 对象与 HTTP 请求/响应体（JSON、XML等）之间的序列化和反序列化。RestTemplate 和 RestClient 是直接复用，而 WebClient 则通过其内部的编解码器进行，但原理相通。
• 拦截器机制：RestTemplate 有 ClientHttpRequestInterceptor，WebClient 有 ExchangeFilterFunction，RestClient 同时继承了 RestTemplate 的拦截器概念并支持 ClientHttpRequestInterceptor。它们都采用了责任链模式，用于关注点分离，如日志、认证、链路追踪等。
• Spring 扩展点：ClientHttpRequestFactory 和 ClientHttpConnector 等接口的设计，完美体现了策略模式和抽象工厂模式。它们允许我们在不修改客户端代码的情况下，轻松替换底层的 HTTP 引擎。

2. RestTemplate：同步阻塞的基石

RestTemplate 是理解 Spring HTTP 客户端设计的起点。其核心在于模板方法模式和职责链模式的经典应用。

2.1 模板方法模式：doExecute 源码分析

RestTemplate 的核心执行流程全部收敛在 doExecute 方法中，它定义了一个不可变的算法骨架。

// org.springframework.web.client.RestTemplate
protected <T> T doExecute(URI url, @Nullable HttpMethod method, @Nullable RequestCallback requestCallback,
                          @Nullable ResponseExtractor<T> responseExtractor) throws RestClientException {

    // 1. 创建客户端请求对象 (工厂方法)
    ClientHttpRequest request = createRequest(url, method);
    
    if (requestCallback != null) {
        // 2. 执行请求回调（主要做两件事：应用拦截器链、执行消息转换写入请求体）
        requestCallback.doWithRequest(request);
    }

    // 3. 执行真正的 HTTP 调用 (核心步骤，由子类或策略实现决定是否阻塞)
    ClientHttpResponse response = request.execute();

    // 4. 处理响应
    handleResponse(url, method, response);
    
    // 5. 提取响应体 (策略模式)
    if (responseExtractor != null) {
        return responseExtractor.extractData(response);
    }
    return null;
}

设计解读：

• createRequest(url, method)：这是模板方法模式中的原语操作。它通过内部持有的 ClientHttpRequestFactory 来创建具体的 ClientHttpRequest 实例，这是策略模式的体现。
• requestCallback.doWithRequest(request)：在执行请求前，回调会遍历所有 ClientHttpRequestInterceptor，形成拦截器链，对请求进行增强。
• request.execute()：这是阻塞点，调用线程会在此等待网络 I/O 完成。
• handleResponse(...)：处理响应状态码，判断是否有错误。
• responseExtractor.extractData(response)：另一个策略点，ResponseExtractor 负责从 ClientHttpResponse 中利用 HttpMessageConverter 提取出泛型对象。
• 关联前文：此处的 HttpMessageConverter 使用方式，与在服务端 HttpMessageConverter 解析 @RequestBody 的机制完全一致，都是 Extract 和 Write 的过程，只是应用方向相反。

2.2 核心扩展点：ClientHttpRequestFactory

ClientHttpRequestFactory 是一个策略接口，隔离了底层 HTTP 连接的创建。

• SimpleClientHttpRequestFactory (默认)：封装 JDK 的 HttpURLConnection。极其简陋，每次请求都新建连接，且无连接池，生产环境几乎不可用。
• HttpComponentsClientHttpRequestFactory：封装 Apache HttpClient，支持连接池，是生产环境同步调用的标准选择。
• Netty4ClientHttpRequestFactory：基于 Netty 4 的同步封装，同样是同步阻塞的。

2.3 拦截器链：ClientHttpRequestInterceptor

RestTemplate 的拦截器机制是经典的责任链模式，用于在请求发送前后织入通用逻辑。

// org.springframework.http.client.ClientHttpRequestInterceptor
public interface ClientHttpRequestInterceptor {
    ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) 
        throws IOException;
}

// 执行链的内部实现，在 RestTemplate 的内部类 InterceptingClientHttpRequest 中
// 核心是递归调用
public ClientHttpResponse execute(HttpRequest request, byte[] body) throws IOException {
    if (this.iterator.hasNext()) {
        ClientHttpRequestInterceptor nextInterceptor = this.iterator.next();
        return nextInterceptor.intercept(request, body, this); // 递归调用
    }
    else {
        // 所有拦截器执行完毕，开始真正的网络请求
        return delegate.execute(request, body);
    }
}

与前文拦截器篇的对比：

• 位置不同：ClientHttpRequestInterceptor 是客户端拦截器，而前文讨论的是服务端的 HandlerInterceptor。
• 粒度不同：服务端拦截器工作在 DispatcherServlet 层面，可以拿到 HttpServletRequest/Response；客户端拦截器操作的是 Spring 抽象的 HttpRequest/Response 和请求体字节数组。
• 本质相同：两者都遵循责任链模式，通过递归或迭代的方式依次执行拦截器，是面向切面编程（AOP）思想的体现。

2.4 连接池管理：PoolingHttpClientConnectionManager 配置

生产实践中，必须使用连接池来避免反复进行 TCP 握手，并控制资源。

// 典型连接池配置示例
@Bean
public RestTemplate restTemplate() {
    // 1. 创建连接管理器
    PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
    connectionManager.setMaxTotal(200);        // 总连接数上限
    connectionManager.setDefaultMaxPerRoute(50); // 每个路由（域名+端口）的上限

    // 2. 创建 Apache HttpClient
    CloseableHttpClient httpClient = HttpClientBuilder.create()
            .setConnectionManager(connectionManager)
            .setConnectionTimeToLive(30, TimeUnit.SECONDS) // 连接存活时间
            .evictIdleConnections(60, TimeUnit.SECONDS)    // 定期清理空闲连接
            .build();

    // 3. 设置给 RestTemplate
    HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(httpClient);
    factory.setConnectTimeout(5000); // 建立连接超时
    factory.setReadTimeout(10000);   // 读取数据超时

    return new RestTemplate(factory);
}

参数合理取值分析：

• maxTotal：需根据服务规模和下游承载力设定。太小会成为瓶颈，太大可能耗尽客户端资源并压垮下游。
• maxPerRoute：防止单一路由占用所有连接，导致其他路由饥饿。一个合理的经验公式是：maxPerRoute = 期望并发数 / 下游服务实例数 * 1.2。

2.5 同步阻塞模型的问题

RestTemplate 的根本缺陷在于其同步阻塞模型。

• 线程阻塞：在 request.execute() 返回前，工作线程（如 Tomcat worker 线程）会一直阻塞。
• 吞吐量限制：由于线程阻塞，服务的并发处理能力被线程池大小锁死。若线程池有 200 个线程，那么同一时刻只能处理 200 个外部 HTTP 请求。线程越多，上下文切换开销越大，导致资源利用率低下。
• 资源浪费：在高延迟场景下，线程大部分时间都处于等待网络响应的 WAITING 或 BLOCKED 状态，白白占用内存。

2.6 RestTemplate 请求执行与拦截器链序列图

sequenceDiagram
    participant Caller as 调用方业务线程
    participant RT as RestTemplate
    participant IR as InterceptingClientHttpRequest
    participant I1 as 拦截器1 (如认证)
    participant I2 as 拦截器2 (如日志)
    participant D as Delegate (底层请求)
    participant Server as 远程服务器

    Caller->>RT: getForObject(...)
    RT->>RT: doExecute(...)
    RT->>IR: createRequest(url, method)
    Note over RT: 1. 创建请求对象
    IR-->>RT: 
    RT->>RT: requestCallback.doWithRequest(request)
    Note over RT: 2. 应用拦截器链 &<br/>消息转换器写入请求体
    
    rect rgb(240, 248, 255)
        Note over Caller,Server: 拦截器责任链递归执行
        RT->>I1: intercept(request, body, execution)
        I1->>I1: 添加认证Header
        I1->>I2: execution.execute(request, body)
        I2->>I2: 记录请求日志
        I2->>D: execution.execute(request, body)
    end

    rect rgb(255, 240, 240)
        Note over Caller,Server: 同步阻塞点
        D->>Server: 发送 HTTP 请求
        Note right of Caller: 业务线程在此阻塞等待<br/>状态: RUNNABLE -> WAITING
        Server-->>D: HTTP 响应
    end
    
    D-->>I2: 返回响应
    I2->>I2: 记录响应日志
    I2-->>I1: 
    I1-->>RT: 返回响应
    
    RT->>RT: handleResponse(...)
    Note over RT: 3. 处理响应状态
    RT->>RT: responseExtractor.extractData(...)
    Note over RT: 利用HttpMessageConverter<br/>提取响应体为对象
    RT-->>Caller: 返回目标对象

• 图表主旨概括：此序列图详细展示了 RestTemplate 从调用到返回的完整内部流程，重点突出了同步阻塞的网络调用和递归执行的拦截器责任链。
• 逐层/逐元素分解：
  • 调用方业务线程：整个调用链的发起者，它会被阻塞在 RestTemplate 内。
  • RestTemplate & InterceptingClientHttpRequest：协调者，负责执行 doExecute 模板方法。
  • 拦截器 1、2：责任链上的具体处理器，通过 execution.execute() 进行递归传递。
  • Delegate：最终执行网络 I/O 的底层组件，是同步阻塞的根源。
• 设计原理映射：
  • 模板方法模式：doExecute 方法定义了算法骨架，而请求创建、拦截器调用、响应提取等步骤是具体的实现或需要填充的步骤。
  • 责任链模式：ClientHttpRequestInterceptor 链完美体现了责任链模式，每个拦截器都有机会处理请求和响应，并能选择是否将请求传递到链中的下一个环节。
• 工程联系与关键结论：
  • 从图中可以清晰地看到，业务线程阻塞的时间 = 拦截器链执行时间 + 网络往返时间(RTT)。
  • 关键结论：任何优化都必须关注如何缩短线程阻塞的时间，或者从根本上用异步方式避免线程阻塞。 这也是 WebClient 要解决的核心问题。

3. WebClient：响应式非阻塞的先锋

WebClient 是 Spring 响应式编程模型在 HTTP 客户端侧的体现。它通过事件循环和非阻塞 I/O，实现了用极少线程处理海量并发的目标。

3.1 构建器与核心接口

WebClient 的使用是声明式、不可变的。

WebClient webClient = WebClient.builder()
        .baseUrl("http://api.example.com")
        .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
        .filter(logFilter())        // 添加过滤器
        .codecs(configurer -> ...) // 配置编解码器（相当于 HttpMessageConverter）
        .build();

• WebClient.Builder：创建和配置 WebClient 实例的建造者。
• ExchangeFunction：是 WebClient 执行的顶层函数式接口，Mono<ClientResponse> exchange(ClientRequest request)。整个请求过程就是一个 ExchangeFunction 的调用链。

3.2 与 Reactor Netty 的整合：事件循环模型

WebClient 默认且推荐的底层引擎是 Reactor Netty。

• ReactorClientHttpConnector：WebClient 的策略接口 ClientHttpConnector 的实现，它内部封装了 Reactor Netty 的 HttpClient。
• 事件循环 (Event Loop)：Reactor Netty 基于 Netty 的 EventLoopGroup。一个或多个线程不断循环，在 Selector 上等待 I/O 事件（连接建立、读就绪、写就绪等），一旦事件触发，就在该线程上非阻塞地处理。这就是“非阻塞”的根本。
• Mono/Flux： 整个 HTTP 交互被建模成一个延迟执行的 Mono<ClientResponse> 管道。只有当你调用 .subscribe() 时，整个管道才会被订阅，Netty 开始发起连接，Reactor 调度器将具体 I/O 操作分配到 Netty 的 I/O 线程上。

3.3 过滤器链：ExchangeFilterFunction

WebClient 的过滤器机制比 RestTemplate 的拦截器更函数式化，它直接操作 ExchangeFunction。

public interface ExchangeFilterFunction {
    Mono<ClientResponse> filter(ClientRequest request, ExchangeFunction next);
}

// 一个简单的日志过滤器示例
ExchangeFilterFunction logFilter = (request, next) -> {
    logger.info("Request: {} {}", request.method(), request.url());
    return next.exchange(request)
               .doOnNext(response -> logger.info("Response status: {}", response.statusCode()));
};

• 设计差异：与 ClientHttpRequestInterceptor 的命令式 intercept 方法不同，filter 方法返回一个 Mono。这使得整个调用链是惰性、可组合的。每个过滤器都会返回一个新的 ExchangeFunction，最终形成一条响应式的链条。

3.4 超时控制与背压

WebClient 利用 Reactor 提供了丰富、无侵入的超时和错误处理机制。

webClient.get()
         .uri("/users/{id}", userId)
         .retrieve()
         .onStatus(HttpStatus::isError, res -> // 错误状态码处理
              Mono.error(new UserServiceException("Failed to fetch user")))
         .bodyToMono(User.class)
         .timeout(Duration.ofSeconds(3))   // 响应超时
         .retryWhen(Retry.backoff(2, Duration.ofMillis(500))) // 带退避的重试
         .onErrorResume(TimeoutException.class, e -> 
              Mono.just(fetchFromCache(userId))); // 超时后降级

• 背压支持：WebClient 本身就是 Reactive Streams 的上游或下游。当响应体很大（如文件流 Flux<DataBuffer>），但下游消费者处理缓慢时，Netty 会自动调节从 Socket 读取字节的速率，防止内存溢出，这就是背压。

3.5 线程模型：少量线程支撑高并发

这是 WebClient 与 RestTemplate 最根本的区别。

• 非阻塞：当一个请求通过 WebClient 发出时，调用线程（无论是 Netty IO 线程还是用户线程）会立即返回一个 Mono，不会等待网络响应。
• 事件驱动：当网络响应数据包到达网卡，触发中断，Netty IO 线程被唤醒，处理数据并回调到 Mono 管道的后续操作（解码、用户回调）。
• 线程占用极小：一个应用可以只使用几个 Netty IO 线程，就支撑起数千个并发的 HTTP 调用。

3.6 WebClient 响应式执行与事件循环序列图

sequenceDiagram
    autonumber
    participant Caller as 调用方
    participant WC as WebClient
    participant F1 as 过滤器1 (日志)
    participant F2 as 过滤器2 (认证)
    participant Ex as Exchange (底层Connector)
    participant NIO as Netty IO线程
    participant Server as 远程服务器

    Caller->>WC: get().retrieve().bodyToMono(...)
    WC->>WC: 构建 Mono 操作链 (惰性, 未订阅)
    Note over WC: "组装: timeout, retry,<br/>map, doOnNext等"
    Caller->>WC: .subscribe()

    rect rgb(240, 248, 255)
        Note over Caller,Server: 反应式管道执行 (惰性求值开始)
        WC->>NIO: 异步、非阻塞地发起连接
        WC->>F1: 调用 filter(request, exchange chain)
        F1->>F1: 记录请求信息
        F1->>F2: next.exchange(request)
        F2->>F2: 添加认证Header
        F2->>Ex: next.exchange(request)
        Ex->>NIO: 构建并发送 HTTP 请求
        Note right of Caller: "调用线程立即返回<br/>未被阻塞"
    end

    Note over NIO,Server: 事件循环等待响应

    Server-->>NIO: 响应数据到达 (IO事件触发)

    rect rgb(255, 245, 230)
        Note over NIO,Server: 响应式回调与处理 (仍在 NIO 线程)
        NIO->>Ex: 响应回调
        Ex-->>F2: "返回 Mono<ClientResponse>"
        F2-->>F1: 传递 ClientResponse
        F1->>F1: 记录响应信息
        F1-->>NIO: 
        NIO-->>Caller: 回调 .subscribe 中的 onNext/onComplete
    end

• 图表主旨概括：此序列图揭示了 WebClient 响应式执行的全链路，重点在于展示其在订阅后才开始惰性执行，以及请求在 Netty IO 线程上全异步、非阻塞处理的过程。
• 逐层/逐元素分解：
  • 调用方：发起调用和订阅，线程不会阻塞。
  • WebClient & Exchange：组装反应式流管道，并作为管道执行的入口。
  • 过滤器 1、2：以函数式组合的方式参与 ExchangeFunction 链。
  • Netty IO 线程：图中核心角色，负责连接和所有 I/O 处理，是事件循环的化身。
• 设计原理映射：
  • 建造者模式：WebClient.builder() 负责构建复杂的 WebClient 实例。
  • 装饰/代理模式：ExchangeFilterFunction 通过包装 ExchangeFunction 来添加新功能，是一种函数式的装饰。
  • 观察者模式：订阅 Mono/Flux 的过程，就是向发布者注册观察者的过程。HTTP 响应的到达，驱动了从下游到上游的数据流。
• 工程联系与关键结论：
  • WebClient 的性能优势来源于其“非阻塞”本质，它解放了线程。 在高并发、高延迟的 I/O 密集型场景中，优势极为显著。
  • 关键结论：在 Servlet 容器中虽然可用 WebClient，但整个请求生命周期的起点仍是阻塞的。只有当整个链路全部响应式化时，非阻塞模型的威力才能发挥到极致。

4. RestClient：同步 API 的现代重构（前瞻）

4.1 出现背景与定位

RestTemplate 虽有诸多问题但存量巨大，WebClient 虽功能强大但响应式编程门槛较高。RestClient 正是为了填补这一空白：为习惯同步编程模型的开发者，提供一个与 WebClient 同样现代、强大但更简洁的 API。它被官方定位为 RestTemplate 的长期替代品。

4.2 内部架构分析

RestClient 不是对 RestTemplate 的简单封装，而是吸收了它和 WebClient 的优点后的一次重构。

• 流式构建器：RestClient.create().get().uri(...).retrieve().body(MyClass.class)。
• 底层多样性：它通过 ClientHttpRequestFactory 与底层通信。可以适配任何 ClientHttpRequestFactory，包括同步的 HttpComponentsClientHttpRequestFactory，也包括包装了非阻塞客户端的适配器。例如，Spring 6.1 引入了 JdkClientHttpRequestFactory，它基于 JDK 11 的 java.net.http.HttpClient，后者底层是异步非阻塞的。

// RestClient 可以选择不同的底层实现
RestClient syncClient = RestClient.builder()
        .requestFactory(new HttpComponentsClientHttpRequestFactory()) // 传统同步实现
        .build();

RestClient asyncLikeClient = RestClient.builder()
        .requestFactory(new JdkClientHttpRequestFactory()) // JDK 异步实现，线程占用更优
        .build();

• 内部实现推测（基于 6.1+ 源码分析）：当 RestClient 执行 .retrieve().body(...) 时，其内部实际上也是调用 requestFactory.createRequest，然后执行 request.execute()，这是一个同步阻塞调用。关键在于，JdkClientHttpRequestFactory 的 execute() 内部运作机制。它委托给 JDK 的 HttpClient.send()，而此方法虽然是同步等待结果，但其内部 I/O 操作是基于 Selector 的非阻塞 I/O。因此，RestClient 在这个层面上实现了“API 同步，底层 IO 可能异步”的设计。这使得使用 JDK 客户端的 RestClient 在等待 I/O 时，对操作系统线程的占用优于纯 HttpURLConnection 实现，但 RestClient 的调用线程依然会阻塞。

4.3 流式 API 优势

相比 RestTemplate，RestClient 的 API 表达力极强。

// RestClient 流式处理
User user = restClient.get()
        .uri("/users/{id}", 1)
        .accept(MediaType.APPLICATION_JSON)
        .exchange((req, res) -> { // exchange 方法提供了完整的请求/响应控制
            if (res.getStatusCode().is4xxClientError()) {
                throw new UserNotFoundException();
            }
            return res.bodyTo(User.class);
        });

它通过 Builder 和 Lambda，将请求构建、状态判断、错误处理、响应转换一气呵成，代码可读性远高于 RestTemplate。

4.4 与 RestTemplate 的对比

• API 设计：RestClient 更现代，更符合 Java 8+ 的函数式风格；RestTemplate 的方法重载过多，显得臃肿。
• 默认配置：RestClient 在新版本中已经搭配更优的默认 ClientHttpRequestFactory。
• 发展方向：RestClient 是未来的同步客户端，RestTemplate 只会接收安全补丁和微小维护。

4.5 RestClient 的同步调用栈与底层非阻塞适配序列图

sequenceDiagram
    participant Caller as 业务线程
    participant RC as RestClient
    participant RF as JdkClientHttpRequestFactory
    participant JHC as java.net.http.HttpClient
    participant NIO as JDK 内部 NIO 引擎
    participant Server as 远程服务器

    Caller->>RC: .retrieve().body(User.class)
    RC->>RC: 组装请求配置
    
    rect rgb(240, 248, 255)
        Note over Caller,Server: 同步阻塞段 (业务线程视角)
        RC->>RF: requestFactory.createRequest(...).execute()
        RF->>JHC: httpClient.send(req, BodyHandlers.ofInputStream())
        Note right of Caller: ! 业务线程在此阻塞等待
    end

    rect rgb(255, 245, 230)
        Note over JHC,Server: 非阻塞 I/O 段 (底层 JDK 引擎视角)
        JHC->>NIO: 非阻塞地执行连接和发送操作
        NIO->>Server: 发送 HTTP 请求
        Note over NIO: 事件循环线程处理 I/O
        Server-->>NIO: HTTP 响应
    end

    NIO-->>JHC: 
    JHC-->>RF: 返回完整响应
    RF-->>RC: 
    RC->>RC: 使用 HttpMessageConverter 解码响应
    RC-->>Caller: 返回 User 对象，解除阻塞

• 图表主旨概括：此图旨在澄清 RestClient “同步 API 但底层可异步”的本质。业务线程在调用点阻塞，但底层的 JDK HttpClient 可能在使用非阻塞 I/O 与 Socket 交互。
• 逐层/逐元素分解：
  • 业务线程：经历了完整的同步阻塞，这是与 WebClient 的关键区别。
  • RestClient & JdkClientHttpRequestFactory：同步 API 的门面。
  • java.net.http.HttpClient 与 NIO 引擎：底层的异步执行组件。send 方法是同步的，但其内部 Selector 管理是异步的。
• 设计原理映射：
  • 门面模式：RestClient 是复杂的 HTTP 交互的同步门面，隐藏了底层连接管理、编解码的复杂性。
  • 适配器模式：JdkClientHttpRequestFactory 是一个适配器，它将 JDK 11 的 HttpClient 适配为 Spring 的 ClientHttpRequestFactory 接口，无缝集成到 RestClient 中。
• 工程联系与关键结论：
  • RestClient 相比旧版 RestTemplate，其线程模型的优势在于：通过搭配更智能的底层实现，减少了不必要的、对大量系统线程资源的占用，但它并没有改变调用者线程阻塞的事实。
  • 关键结论：RestClient 是“改良”而非“革命”。它在编码体验和底层效率上都大大优于 RestTemplate，是高版本 Spring 环境中同步调用的不二之选。

5. 深度对比：IO 模型、线程与性能

本模块将三个客户端置于同一维度下进行细致的量化与定性对比。

5.1 多维度对比详表

维度	RestTemplate (默认)	RestTemplate (优化后)	WebClient	RestClient (推荐配置)
IO 模型	同步阻塞	同步阻塞	反应式非阻塞	同步 API，底层可非阻塞
线程模型	每请求阻塞一个工作线程	每请求阻塞一个工作线程	少量事件循环线程	每请求阻塞一个工作线程
背压支持	否	否	是	否
连接池	HttpURLConnection 无连接池	PoolingHttpClientConnectionManager	reactor.netty.resources.ConnectionProvider	JdkHttpClient 自带或 PoolingHttpClientConnectionManager
典型并发能力	低	中 (受线程池限制)	极高	中 (受线程池限制)
内容消费	一次性全部读入内存	一次性全部读入内存	可流式处理，支持背压	一次性全部读入内存
编程风格	命令式	命令式	声明式/函数式	命令式+流式 (最佳)
错误处理	try-catch 或 ResponseErrorHandler	try-catch 或 ResponseErrorHandler	onStatus, onErrorResume 等操作符	Lambda-based error handler
认知成本	低	低	高 (需理解Reactor)	低 (相对WebClient)

5.2 性能对比（假设性基准测试）

模拟一个下游服务，响应时间 P99 为 200ms。

• 低并发 (50 users/s)：三者表现类似，Tomcat 200线程足够应对。WebClient 的异步优势不明显。
• 中并发 (500 users/s)：RestTemplate (优化后) 受限于 Tomcat 线程池大小，开始出现排队，TP99 增加。WebClient 和 RestClient (JDK) 吞吐稳定。
• 极高并发 (5000 users/s)：RestTemplate 在大线程池下因上下文切换，CPU 打满，响应超时剧增，无法服务。WebClient 在极少线程下维持吞吐，但 P99 延时接近下游响应时间。RestClient (JDK) 同样能处理此并发，但对工作线程（Tomcat）池要求依然巨大（如2000），消耗大量内存，非长久之计。

结论：WebClient 在极高并发的 I/O 密集型场景下具有压倒性的资源利用率和吞吐量优势。

5.3 不同客户端在不同并发场景下的线程模型对比图

flowchart LR
    subgraph S [场景设定]
        C_50[低并发]
        C_500[中高并发]
        C_5000[极高并发]
    end

    subgraph T1 [RestTemplate 线程模型]
        direction TB
        RT_ThreadPool[Tomcat 线程池]
        RT_T1[线程1: 请求A -> BLOCKED]
        RT_T2[线程2: 请求B -> BLOCKED]
        RT_TN[......]
        RT_ThreadPool --> RT_T1 & RT_T2 & RT_TN
    end

    subgraph T2 [WebClient 线程模型]
        direction TB
        WC_Caller[少量 Tomcat 线程]
        WC_NIO[极少 Netty IO 线程]
        WC_T1[线程A: 发起Req -> FREE]
        WC_T2[线程B: 发起Req -> FREE]
        WC_Caller --> WC_T1 & WC_T2
        WC_NIO -->|处理所有IO事件| WC_T1 & WC_T2
    end

    subgraph T3 [RestClient 线程模型]
        direction TB
        RC_ThreadPool[Tomcat 线程池]
        RC_T1[线程1: 请求A -> BLOCKED on send]
        RC_T2[线程2: 请求B -> BLOCKED on send]
        RC_Note[阻塞在调用点, 但底层IO可能异步]
        RC_ThreadPool --> RC_T1 & RC_T2
        RC_T1 --> RC_Note
    end

    C_50 -->|场景| T1 & T2 & T3
    C_500 -->|场景| T1 & T2 & T3
    C_5000 -->|场景| T1 & T2 & T3

• 图表主旨概括：本图通过对比三种客户端在不同并发负载下的线程状态，直观地揭示了它们的核心差异。
• 逐层/逐元素分解：
  • RestTemplate：所有业务线程在 I/O 等待期间都处于 BLOCKED 状态，并发度完全受限于此。
  • WebClient：业务线程（如 Tomcat 线程）发起请求后立即释放，可以处理其他任务。真正的 I/O 由极少的 Netty 线程驱动，这些线程几乎一直处于忙碌状态。
  • RestClient：它比 RestTemplate 好在其阻塞等待的底层 I/O 实现效率更高（若使用 JDK 客户端），但无法解决业务线程阻塞和耗用大量线程的根本问题。
• 设计原理映射：这本质上是基于线程的并发模型与事件驱动的并发模型的对比。
• 工程联系与关键结论：
  • 选择哪种客户端，本质上是在为你的系统选择一种并发模型。
  • 关键结论：如果你的应用瓶颈是 I/O 而非 CPU，并且面临高并发压力，那么响应式全链路的 WebClient 是唯一的出路。

6. 选型决策框架与迁移策略

6.1 决策流程图与决策矩阵

flowchart TD
    A["开始选择HTTP客户端"] --> B{"应用技术栈是?"}
    B -->|"WebFlux / 响应式栈"| C["WebClient"]
    
    B -->|"Servlet / MVC 栈"| D{"是否已使用 Spring Boot 3.x / Spring 6.x?"}
    
    D -->|"否 (仍为 2.x/5.x)"| E{"是否有高并发、流式处理需求?"}
    E -->|"是"| F["考虑迁移到响应式栈<br/>核心模块用 WebClient"]
    E -->|"否"| G["RestTemplate 或 RestClient"]
    
    D -->|"是"| H{"是否需要流式处理/背压?"}
    H -->|"是"| I{"能否承担响应式编程成本?"}
    I -->|"能"| C
    I -->|"不能"| J["RestClient<br/>(但不享受背压)"]
    H -->|"否"| K["RestClient (强力推荐)"]
    
    C & G & J & K --> L{"最终选择"}

    classDef decision fill:#fff4e6,stroke:#ff9800,stroke-width:2px,color:#333;
    classDef process fill:#f8f9fa,stroke:#333,stroke-width:1px,color:#333;
    class A,F,G,J,K process;
    class B,D,E,H,I,L decision;

决策矩阵

决策因素	推荐客户端	原因
响应式技术栈(WebFlux)	WebClient	天生一对，全链路非阻塞。
Spring Boot 3.x + 同步应用	RestClient	官方替代品，API现代，性能更优。
Spring Boot 2.x 遗留应用	RestTemplate (维护)	保持现状，仅在关键路径优化或迁移。
极高并发服务间调用 (如网关)	WebClient	少量线程支撑海量并发，资源利用率极高。
流式数据传输 (上传/下载大文件)	WebClient	背压支持，防止 OOM。
简单的脚本或后台任务	RestTemplate 或 RestClient	同步调用简单直观，无需引入响应式复杂性。

6.2 迁移策略

• RestTemplate → RestClient：这是最平滑的迁移。两者 API 概念相近，只需逐步将 new RestTemplate() 替换为 RestClient.create()，并调整调用方式为流式 API。连接池等配置可完全复用。
• RestTemplate → WebClient：这是编程模型的跳跃。
  • 依赖变化：需引入 spring-boot-starter-webflux。
  • 代码陷阱：
    1. 绝不能在返回的 Mono/Flux 上直接调用 .block()。这会将异步变同步，丧失所有优势，甚至可能因线程模型冲突导致死锁或性能雪崩。
    2. （详见前文异常处理篇章） 错误处理逻辑必须用 Reactor 操作符改写，try-catch 不再有效。
    3. （详见前文拦截器与过滤器篇章） 拦截器逻辑需全部用 ExchangeFilterFunction 重写。

7. 生产事故排查专题

7.1 事故一：服务突然假死，大量请求超时

• 现象：某电商订单服务在晚高峰突然开始出现大面积超时，整个服务不可用。健康检查接口也响应缓慢。
• 排查思路：
  1. 监控大盘：JVM 堆内存正常，但 CPU 使用率异常高。
  2. 线程 Dump：连续 Dump 几次线程栈，发现数以千计的线程处于 BLOCKED 状态，都在等待 Socket.connect()，堆栈顶是 java.net.PlainSocketImpl.socketConnect。
  3. 代码审查：发现该服务使用 RestTemplate 调用下游的商品库存服务，但没有显式配置 ClientHttpRequestFactory，使用了默认的 SimpleClientHttpRequestFactory。
• 根因分析： SimpleClientHttpRequestFactory 使用的是 JDK 的 HttpURLConnection。它不为连接提供池化，每次请求都会建立一个新的 TCP 连接。在晚高峰高并发下，短时间内创建了海量连接。由于HttpURLConnection依赖底层的Socket连接，大量 TIME_WAIT 状态的 socket 和操作系统级别的文件描述符耗尽，导致新的 Socket.connect() 调用被阻塞或直接失败。线程池的线程全部堵塞在这些连接创建上，服务像多米诺骨牌一样瘫痪。
• 解决方案：
  1. 立即止血：紧急重启服务，流量会瞬间降低，暂时恢复。
  2. 根本修复：将 RestTemplate 配置为使用带有连接池的 HttpComponentsClientHttpRequestFactory（配置见 2.4 节），并合理设置 maxTotal 和 maxPerRoute。
• 最佳实践：凡是生产环境使用 RestTemplate，必须在初始化时配置带连接池的 ClientHttpRequestFactory。 同时，为连接和读取设置超时时间（connectTimeout, readTimeout），这是最基本的防护。

7.2 事故二：WebClient 间歇性返回 500 内部错误

• 现象：使用 WebClient 的服务，在调用一个偶有慢响应的下游服务时，会间歇性地抛出 WebClientRequestException: Connection prematurely closed 异常，导致业务 500 错误。
• 排查思路：
  1. 日志分析：发现下游服务在那段时间存在 P99 耗时增加的波动，但并未超过设置的超时时间（5s）。
  2. 开启 Debug 日志：在 application.properties 中增加 logging.level.reactor.netty.http.client=DEBUG。日志显示，在数据接收过程中，Netty 客户端单方面关闭了连接。
  3. 代码审查：发现代码中配置了 .timeout(Duration.ofSeconds(5))。但在 onStatus 处理中，没有正确消费或释放错误响应体。
  4. 深入分析：WebClient 在遇到超时或特定错误码时，会尝试取消上游。但若此时上游仍在发送数据，取消信号可能引发连接被粗暴关闭。更关键的是，如果 onStatus 函数内抛出了一个未预料的异常，而又没有一个全局的 .onErrorResume(...) 来兜底，这个异常会直接通过 Mono 传播，导致订阅链终止，连接被关闭。
• 根因分析： 错误处理逻辑不健壮。.timeout() 触发 TimeoutException 后，被 onStatus 中的逻辑再次抛出异常，最终没有被 .onErrorResume 捕获，导致 Mono 以错误结束。反应式流中的任何未处理异常都会导致订阅链的终结。
• 解决方案：
  1. 增加兜底逻辑：在调用链末尾增加 .onErrorResume(Exception.class, this::fallbackMethod)，确保所有未捕获异常都有降级方案，避免连接异常关闭。
  2. 检查 onStatus：确保每个 onStatus 的处理逻辑都正确返回一个 Mono.error，而不是直接 throw。
• 最佳实践：响应式编程的错误处理必须遵循“错误即信号”的原则，在整个管道末端必须有全局的错误降级或通知机制。 利用 Reactor 的 Hooks 和 Debug Agent 可以帮助快速定位这类问题。

8. 面试高频专题

1. RestTemplate、WebClient 和 RestClient 的区别及使用场景？

• 标准回答：从IO模型（同步阻塞 vs 异步非阻塞）、编程模型、性能与资源、适用场景等角度对比。RestTemplate是同步阻塞老将，WebClient是响应式先锋，RestClient是同步未来的替代品。
• 追问 1：RestTemplate 的同步阻塞模型具体在代码层面是如何体现的？答：在 doExecute 方法的 request.execute() 处线程阻塞。
• 追问 2：为何不把 RestTemplate 直接标记为 @Deprecated？答：存量太大，强行废弃会破坏海量现有系统，团队采取保守的“维护模式”。
• 追问 3：在 Spring MVC 项目中用 WebClient，线程模型会改变吗？答：不会，Servlet 容器的工作线程池依然存在，但 WebClient 本身不阻塞该线程，可以立即去做其他事，提升了单个请求内并行调用的效率。
• 加分回答：能指出 RestClient 底层通过适配 JdkClientHttpRequestFactory 获得“API同步，IO可能异步”的特性，并点出其作为同步客户端，线程模型依然是调者阻塞。

2. RestTemplate 默认的连接实现有什么问题？如何优化？

• 标准回答：默认使用 SimpleClientHttpRequestFactory，底层是 HttpURLConnection，无连接池，每次请求新建连接，存在性能低下和资源耗尽风险。
• 追问 1：PoolingHttpClientConnectionManager 的 maxTotal 和 maxPerRoute 如何设置？答：基于业务并发、下游服务实例数等，不能无限大，要计算最佳值。
• 追问 2：除了 HttpComponents，还有其他选择吗？答：OkHttp3 也常用，引入 okhttp3 依赖并配置 OkHttp3ClientHttpRequestFactory 即可。
• 追问 3：连接池中的连接失效了怎么办？答：需要配置 setValidateAfterInactivity、evictIdleConnections 等参数来探查和清理死连接。
• 加分回答：能画出 RestTemplate -> ClientHttpRequestFactory -> HttpClient -> PoolingHttpClientConnectionManager 的层次依赖图，并解释每一层的职责。

3. WebClient 的响应式模型相比 RestTemplate 的优势？

• 标准回答：非阻塞、高吞吐、背压支持、函数式组合性强。
• 追问 1：非阻塞是怎么实现的？答：基于 Netty 的 IO 多路复用和事件循环模型。
• 追问 2：背压是如何在 HTTP 调用中体现的？答：当消费端处理 Flux 数据慢时，TCP 接收窗口减小，上游发送速率自动降低。
• 追问 3：如果下游是一个传统的阻塞式 REST API，WebClient 还有优势吗？答：优势主要在调用方自身的资源利用上，不阻塞自己的线程，但对于下游的阻塞无能为力。
• 加分回答：能结合 Reactor 的信号机制，解释 Mono 和 Flux 如何在 WebClient 内部形成惰性执行的组装线，以及订阅在何时触发真正的网络调用。

4. 为什么说在 Servlet 容器中直接使用 WebClient 不会带来线程模型的彻底变革？

• 标准回答：因为请求的入口依然是 Servlet 容器（如 Tomcat）分配的工作线程。虽然调用 WebClient 不会阻塞此线程，但它最终还是需要一个线程来等待结果和返回，或者通过 AsyncContext 异步处理整个请求生命周期。
• 追问 1：那 Spring MVC 如何异步处理 Servlet 请求？答：可以通过返回 Callable 或 DeferredResult/WebAsyncTask，将工作线程释放，由任务线程池处理后再写回响应。
• 追问 2：@Async 和 WebClient 结合效果如何？答：是一种常见的“伪”并行提升，异步方法在另一个线程池执行并调用 WebClient，当前线程可处理其他请求。
• 追问 3：真正的全链路响应式优势何时体现？答：从网关到业务逻辑到数据库全链路都基于响应式驱动，没有任何阻塞点，所有操作都在事件循环驱动下完成。
• 加分回答：能明确指出响应式并非“快”，而是“扩展性强”和“资源利用率高”，并点出在低延迟、高并发的系统中，其优势呈指数级放大。

5. RestTemplate 的拦截器和 WebClient 的过滤器有什么差异？

• 标准回答：主要从接口契约、执行方式和处理对象上进行比较。Interceptor 是同步命令式，Filter 是函数式，返回 Mono。
• 追问 1：过滤器链是如何组合的？答：每个 ExchangeFilterFunction 都接收一个 ExchangeFunction，通过装饰模式形成链。
• 追问 2：能否在 WebClient 的过滤器中进行重试？答：可以，通过在 next.exchange(request) 返回的 Mono 上应用 .retry() 实现。
• 追问 3：在什么场景下，这两种拦截机制的表现会截然不同？答：在处理流式数据时，RestTemplate 拦截器能操作整个请求/响应体字节数组，而 WebClient 过滤器是惰性的，必须在 Mono 管道中处理。
• 加分回答：能将拦截器机制与前文所学的 Spring AOP 和横切关注点联系起来，说明它们都是责任链模式和 AOP 思想的实现。

6. 从 RestTemplate 迁移到 WebClient，常见的代码陷阱有哪些？

• 标准回答：.block() 滥用、try-catch 失效、ThreadLocal 数据丢失、事务上下文无法传播等。
• 追问 1：为什么在 WebFlux 中调用 .block() 是危险的？答：它会阻塞事件循环线程，导致整个服务瞬间不可用，性能雪崩。
• 追问 2：如何解决 ThreadLocal（如链路追踪ID）丢失问题？答：使用 Reactor 的 Context 机制，通过 .contextWrite() 传递。
• 追问 3：Spring Security 的 SecurityContext 怎么办？答：需引入 spring-boot-starter-security-reactive，它会自动适配 ReactiveSecurityContextHolder。
• 加分回答：能举出具体代码反例，比如在 map 操作符中直接调用 restTemplate 方法，导致异步链中出现“异步变同步”的灾难性后果。

7. RestClient 是如何做到同步 API 但可能拥有非阻塞性能的？

• 标准回答：它本身提供同步阻塞的 API 门面，但其底层可以接入像 JDK 11 HttpClient 这样内部使用 NIO 的 HTTP 引擎。因此，它在执行 I/O 时，对操作系统线程的占用更少、效率更高。
• 追问 1：为什么JDK 11 HttpClient 的 send() 方法是同步的，但它的内部却是异步的？答：send 会阻塞调用者线程，但其内部使用 Selector 进行事件循环，以非阻塞方式处理 Socket I/O，避免了“一线程一Socket”的连接模型。
• 追问 2：“对操作系统线程的占用更少”如何理解？答：传统BIO，一个阻塞的Socket读写就完全占用一个内核线程调度单元。而 JDK HttpClient 内部多个连接共享少数待处理的 I/O 事件，由少数线程管理。
• 追问 3：RestClient 能支持 HTTP/2 吗？答：如果底层 ClientHttpRequestFactory 支持（如 JdkClientHttpRequestFactory 或 Netty 5），那么 RestClient 就能透明地支持 HTTP/2。
• 加分回答：能明确指出这种设计模式本质上是一种基于适配的门面模式，并点明它是对开发者友好的同步模型与底层高效异步引擎的折中与统一。

8. 如何为 RestTemplate 或 WebClient 配置 SSL 以及设置特定的证书信任？

• 标准回答：
  • RestTemplate：通过 HttpComponentsClientHttpRequestFactory，构建自定义 SSLContext 加载信任证书，并设置给 CloseableHttpClient。
  • WebClient：通过 ReactorClientHttpConnector，使用 SslProvider 配置自定义的 SslContext。
• 追问 1：如何跳过 SSL 证书验证（例如在测试环境）？答：自定义一个信任所有证书的 TrustManager，但生产环境绝对禁止。
• 追问 2：如何实现双向认证 (mTLS)？答：除了配置 TrustManager，还需要在 SSLContext 中初始化 KeyManager，用于提供客户端证书。
• 追问 3：如何为不同的主机设置不同的证书？答：使用 SSLConnectionSocketFactory，配合 DefaultHostnameVerifier，或更高级的 Netty SslProvider 构建器，可实现按域名路由证书。
• 加分回答：能联系到实际生产中的证书热加载需求，并给出一种基于ReloadableX509KeyManager和ReloadableX509TrustManager的解决思路。

9. 怎样在不重启应用的情况下动态修改 WebClient 的超时配置？

• 标准回答：不能在已构建的 WebClient 实例上修改。需要将超时配置外化，并在变化时重新构建 WebClient 实例。
• 追问 1：有没有更灵活的方式？答：透传超时，即不在 WebClient 上设置全局超时，而是在每个请求上使用 .timeout(Duration duration) 操作符，此 duration 可从配置中心动态获取。
• 追问 2：大量重新构建 WebClient 实例会影响性能吗？答：WebClient 创建有成本，不应该高频重建。可以通过 ThreadLocal 或缓存获取对应配置的 WebClient 实例。
• 追问 3：如何实现并发布驱动的超时调整？答：基于订阅信号，可以将实时配置包装成一个 Mono，在请求时被动态解包并应用于 .timeout。
• 加分回答：能提到结合 Spring Cloud Config / Nacos 等配置中心，通过 RefreshScope 或自定义 Bean 的生命周期管理，来实现 WebClient Bean 的优雅动态重建。

10. 微服务调用如何传递认证 Token？

• 标准回答：
  • 通用：无论是哪种客户端，都是用拦截器(Interceptor/Filter)。从安全上下文中获取 Token，然后添加到请求头中（如 Authorization: Bearer ...）。
• 追问 1：在 RestTemplate 中怎么写这个拦截器？答：实现 ClientHttpRequestInterceptor，从 SecurityContextHolder 或其他上下文获取 Token。
• 追问 2：在 WebClient 中呢？答：使用 ExchangeFilterFunction。注意：此时已无法直接使用 SecurityContextHolder，必须使用 Reactive 的上下文 ReactiveSecurityContextHolder。
• 追问 3：如果使用 RestClient 呢？答：同样支持 ClientHttpRequestInterceptor，或者直接在流式调用中通过 Lambda 设置 Header。
• 加分回答：能扩展到 Spring Security 的 OAuth2 集成，如 ServletOAuth2AuthorizedClientExchangeFilterFunction 和 ReactiveOAuth2AuthorizedClientManager，它们能自动处理 Token 的获取、刷新和传递。

11. 在 Spring Cloud 环境下，通常是如何替代 RestTemplate 进行负载均衡调用的？

• 标准回答：通过 Spring Cloud LoadBalancer。对于 RestTemplate，使用 @LoadBalanced 注解；对于 WebClient，使用 ReactorLoadBalancerExchangeFilterFunction。
• 追问 1：@LoadBalanced 的原理是什么？答：它是一个标记注解，Spring Cloud 利用它为标记了此注解的 RestTemplate Bean 上自动织入一个 LoadBalancerInterceptor。
• 追问 2：LoadBalancerInterceptor 如何工作？答：它拦截请求，从 URI 中解析服务名，然后通过 LoadBalancerClient 获取实际的服务实例，最后用实际 URL 替换原 URI，发起调用。
• 追问 3：RestClient 如何与负载均衡集成？答：Spring Cloud 当前版本正快速适配 RestClient，其源码已显示对 @LoadBalanced 支持，未来会是主流。
• 加分回答：能指出 RestTemplate 基于 @LoadBalanced 的集成侵入性强，而 WebClient 基于 Filter 的集成更符合响应式和函数式风格，对代码无侵入。

12. （系统设计题）设计一个 API 网关的 HTTP 客户端模块

• 题目：设计一个 API 网关的 HTTP 客户端模块，要求能够根据请求的 Header 自动选择同步或异步转发路径，并支持动态路由、连接池隔离和熔断降级。请结合三种客户端的特点给出核心架构。
• 标准回答：可以设计一个 RoutingHttpClient 门面。
  1. 路由判定：解析请求头（如 X-Client-Type），决定转发模式。
  2. 异步路径：使用 WebClient 池，每个下游服务拥有独立 WebClient 实例，其底层 ConnectionProvider 隔离，实现连接池隔离。利用 resilience4j-reactor 实现熔断。
  3. 同步路径：使用 RestClient 池，同样为下游服务创建独立实例，并可配置独立连接池 (PoolingHttpClientConnectionManager)。利用 resilience4j-spring-boot2 的 @CircuitBreaker 或切面实现熔断。
  4. 动态路由：所有客户端实例都不写死 URI，而是根据从服务发现组件（如 Eureka/Nacos）动态解析出的实例地址进行构建。
• 追问 1：连接池隔离有什么好处？答：防止某个下游服务出问题，耗尽了所有可用连接，导致对其他服务的调用也被阻塞，即故障隔离。
• 追问 2：如何实现优雅的降级？答：在 WebClient 的 Mono 上用 .onErrorResume，在 RestClient 上用 exchange 方法中的 catch，触发时从本地缓存或降级逻辑中返回一个默认响应。
• 追问 3：这个模块如何与网关的响应式架构（如 Spring Cloud Gateway）融合？答：在 SCG 的 GlobalFilter 或自定义 Filter 中调用此模块。SCG 本身就是响应式的，因此异步路径为首选，但可通过将同步请求委托到一个专门的任务线程池来集成同步路径。
• 加分回答：
  1. 能提出使用环形缓冲区或队列来平滑流量尖刺。
  2. 能提到不仅按服务隔离连接池，甚至可按客户/Header 做更细粒度的隔离。
  3. 可以设计一个全链路的超时传递机制，将网关层收到的 timeout 请求头注入到下游客户端的超时配置中，实现端到端的超时控制。

---

HTTP 客户端选型速查表

客户端	推荐场景	连接池	线程模型	注意事项
RestTemplate	旧版本 (SB 2.x) 遗留同步调用 简单后台任务	必须手动配置 PoolingHttpClientConnectionManager	同步阻塞，每请求占用一线程	维护模式，不推荐新功能使用；极易因默认配置导致生产事故。
WebClient	响应式技术栈 (WebFlux) 高并发 API 网关 流式数据传输	ConnectionProvider 管理，可精细配置	事件驱动，非阻塞，极少量线程	学习曲线陡峭，切忌在响应式链中调用 .block()。需注意 Reactive 上下文传递。
RestClient	新版 (SB 3.x+) 同步调用首选 替代 RestTemplate 的新项目	默认 JdkHttpClient 自带，也可配置 HttpComponents	同步 API，但底层 I/O 可能异步	调用线程仍会阻塞。是 RestTemplate 的完美替代，代码更优雅。

---

延伸阅读

1. Spring Framework 官方文档：WebClient 和 RestTemplate 章节，是权威参考。
2. 《Spring Boot 编程思想》（小马哥）：对 Spring Boot 的自动配置原理有深入解读，可加深对客户端默认配置的理解。
3. Reactor 官方文档与参考指南：深入学习 Mono、Flux、操作符及背压，是掌握 WebClient 的基石。