挥别Feign，拥抱Spring 6.1 RestClient：高可用HTTP客户端构建之路
一、引言
**
在微服务架构风靡的当下，远程服务通信已然成为系统架构中极为关键的一环。各个微服务犹如独立运作的个体，它们需要高效、可靠的通信方式来协同工作，完成复杂的业务流程。打个比方，在一个电商系统中，订单服务需要与库存服务、支付服务等进行频繁的交互，以确保订单的正常处理 、库存的准确扣减以及支付的顺利完成。
在过去，Feign 作为 Spring Cloud 生态中颇受欢迎的声明式 HTTP 客户端，凭借其简洁的声明式 API 风格，让开发者能够像调用本地方法一样轻松调用远程服务，极大地简化了远程服务调用的复杂性，提高了开发效率，深受广大开发者的喜爱。例如，通过简单的注解配置，就可以定义一个远程服务接口，然后在代码中直接调用该接口的方法，无需手动处理 HTTP 请求的细节，如 URL 的拼接、请求参数的设置、响应结果的解析等。
然而，随着技术的飞速发展和业务需求的日益复杂，Feign 逐渐显露出一些不足之处。例如，它的性能在高并发场景下可能无法满足需求，配置相对繁琐，与最新的 Spring 版本集成时也可能出现一些兼容性问题 。
而 Spring 6.1 中引入的 RestClient 则为我们带来了新的解决方案。RestClient 以其更简洁的 API 设计、更强大的扩展能力以及更好的性能表现，成为构建高可用声明式 HTTP 客户端的有力选择。它不仅继承了 RestTemplate 的强大功能，还借鉴了 WebClient 的一些优秀特性，为开发者提供了更加流畅、高效的开发体验。
本文将深入探讨如何基于 Spring 6.1 RestClient 构建高可用声明式 HTTP 客户端，通过详细的代码示例和深入的原理分析，帮助大家全面了解 RestClient 的使用方法和优势，从而在实际项目中能够灵活运用 RestClient，提升系统的性能和稳定性。
二、认识 Feign 与 Spring 6.1 RestClient
（一）Feign 的回顾
Feign 作为一款基于声明式的 HTTP 客户端，在微服务架构中曾扮演着举足轻重的角色。它的核心工作原理是通过动态代理机制，依据开发者定义的接口和注解，自动生成 HTTP 请求，并负责处理请求的发送以及响应的解析。举个例子，当我们定义一个 Feign 接口，其中的方法使用了诸如@GetMapping、@PostMapping等注解时，Feign 会在运行时根据这些注解信息，构建出对应的 HTTP 请求，就像是有一个幕后的 “请求构建大师”，将我们简单的接口定义转化为复杂的 HTTP 交互。
在实际应用中，Feign 提供了一系列实用的注解，极大地简化了开发过程。@FeignClient注解用于声明一个 Feign 客户端，通过指定其name属性，可以轻松实现服务发现与负载均衡。例如，@FeignClient(name = "user-service")，这就告诉 Feign 要调用名为 “user-service” 的微服务，在运行时，Feign 会借助服务发现组件（如 Eureka、Consul 等）获取该服务的实际地址，并通过负载均衡策略选择一个合适的实例进行请求。
在 Spring Cloud 生态系统中，Feign 更是如鱼得水。它与 Ribbon 紧密集成，实现了客户端的负载均衡，为微服务之间的通信提供了强大的支持。在一个电商系统中，订单服务可能需要频繁调用商品服务来获取商品信息，使用 Feign 和 Ribbon，订单服务可以透明地调用商品服务的多个实例，而无需关心具体的负载均衡细节，就像在调用本地的多个方法一样自然。同时，Feign 还可以与 Hystrix 集成，实现服务的容错处理，当某个服务出现故障时，Hystrix 可以快速地进行熔断、降级等操作，保证整个系统的稳定性，就像是为系统添加了一层坚固的 “保护盾”。
然而，随着时间的推移和技术的发展，Feign 在实际使用中逐渐暴露出一些问题。在高并发场景下，Feign 的性能瓶颈逐渐凸显。由于其基于动态代理的实现方式，在处理大量请求时，会产生较高的代理开销，导致性能下降，就像一辆老旧的汽车，在高速行驶时显得力不从心。Feign 的配置相对复杂，尤其是在处理一些高级特性（如自定义编码器、解码器、拦截器等）时，需要编写大量的配置代码，这对于开发者来说是一个不小的负担，增加了开发和维护的难度，仿佛在攀登一座陡峭的山峰。此外，Feign 对依赖的管理也较为复杂，不同版本之间的兼容性问题时常出现，这给项目的升级和维护带来了诸多不便，就像拼图中那些难以匹配的碎片，让人头疼不已。
（二）Spring 6.1 RestClient 初相识
Spring 6.1 引入的 RestClient，为我们带来了全新的体验。它的设计理念旨在提供一种更简洁、高效且易于扩展的声明式 HTTP 客户端解决方案。RestClient 的目标是在继承 RestTemplate 强大功能的基础上，借鉴 WebClient 的优秀特性，为开发者打造一个更加现代化、灵活的 HTTP 调用工具，就像是一款集多种先进技术于一身的 “超级武器”。
与 Feign 相比，RestClient 具有诸多优势。RestClient 拥有简洁明了的 API，使用起来更加直观、方便。通过链式调用的方式，我们可以轻松地构建 HTTP 请求，就像在搭建一座积木城堡，每一步都清晰可见。例如，使用 RestClient 发送一个 GET 请求，代码可以简洁地写成RestClient.create().get().uri("/users").retrieve().bodyToMono(User.class)，这种简洁的表达方式大大提高了开发效率，减少了出错的可能性。
RestClient 在扩展性方面表现出色。它提供了丰富的扩展点，允许开发者根据实际需求自定义请求处理逻辑、响应处理逻辑等。通过实现ClientHttpRequestInterceptor接口，我们可以轻松地添加自定义的请求拦截器，实现诸如日志记录、身份验证、参数加密等功能，就像给 HTTP 请求加上了各种个性化的 “装备”，使其更符合项目的需求。在安全性要求较高的项目中，可以通过自定义拦截器对请求进行签名验证，确保请求的合法性和安全性。
RestClient 还在性能方面进行了优化，采用了更高效的底层实现，能够更好地应对高并发场景，为系统的性能提升提供了有力保障，就像为系统注入了一剂 “强心针”，使其在高负载下依然能够稳定运行。
三、搭建基于 Spring 6.1 RestClient 的开发环境
（一）项目创建
首先，我们可以利用 Spring Initializr 来快速搭建一个 Spring Boot 项目。以 Maven 项目为例，在浏览器中访问https://start.spring.io/，这是一个方便快捷的 Spring 项目初始化网站，就像是一个 “项目生成工厂”，能够根据我们的需求生成项目的基础结构。在该页面中，我们可以进行如下配置：
- 项目元数据：
- Group：填写项目的组 ID，通常是公司或组织的域名倒写，比如com.example，它就像是项目的 “家族姓氏”，用于标识项目所属的组织或团队。
- Artifact：填写项目的 Artifact ID，即项目名，例如rest-client-demo，这是项目的 “名字”，是项目在组内的唯一标识。
- Name：项目的显示名称，默认与 Artifact ID 相同，也可以根据喜好进行修改，它主要用于在一些界面中展示，让开发者更直观地识别项目。
- Description：对项目的简短描述，方便开发者快速了解项目的功能和用途，比如 “基于 Spring 6.1 RestClient 的示例项目”，就像是给项目贴上了一个简要的 “功能标签”。
- Package Name：项目的包名，默认是Group和Artifact的组合，如com.example.restclientdemo，包名用于组织项目中的代码文件，就像将物品分类存放在不同的文件夹中一样。
- Java Version：选择项目使用的 Java 版本，这里我们选择 Java 11 及以上版本，以充分利用新特性和更好的性能。
- 依赖选择：在 “Dependencies” 搜索框中，输入并选择所需的依赖，如 Spring Web、Spring Cloud LoadBalancer 等，这些依赖就像是项目的 “零部件”，为项目提供各种功能支持。
完成上述配置后，点击 “Generate” 按钮，即可下载一个压缩包。解压该压缩包，将得到一个完整的 Spring Boot 项目基础结构，包含了项目所需的目录结构、配置文件和基础依赖，就像是搭建好了一座房子的框架，等待我们进一步装修和布置。
如果使用 Gradle 构建项目，同样可以在 Spring Initializr 中选择 Gradle 项目，然后按照类似的步骤进行配置和生成。生成的项目会包含build.gradle文件，用于管理项目的构建和依赖，与 Maven 的pom.xml文件类似，但语法和使用方式略有不同 。
（二）依赖引入
在项目的pom.xml（Maven）或build.gradle（Gradle）文件中，我们需要引入以下核心依赖：
- Spring Web：org.springframework.boot:spring-boot-starter-web，它是 Spring Boot 中用于 Web 开发的核心依赖，提供了构建 Web 应用所需的基础组件和功能，如 HTTP 请求处理、路由映射、视图解析等，就像是搭建 Web 应用这座大厦的基石。例如，它包含了 Spring MVC 框架，使得我们可以方便地创建控制器来处理 HTTP 请求，通过注解配置路由，将不同的 URL 映射到相应的处理方法上。
- Spring Cloud LoadBalancer：org.springframework.cloud:spring-cloud-starter-loadbalancer，这是 Spring Cloud 提供的客户端负载均衡器，用于在多个服务实例之间进行负载均衡，确保请求能够均匀地分配到各个实例上，提高系统的可用性和性能，就像是一个智能的 “交通调度员”，合理分配请求流量。在一个分布式系统中，当有多个相同的服务实例提供相同的功能时，负载均衡器可以根据一定的策略（如轮询、随机、根据负载情况等）选择一个实例来处理请求，避免某个实例因负载过高而出现性能瓶颈。
- Spring RestClient：org.springframework:spring-web，从 Spring 6.1 开始，RestClient 成为 Spring Web 模块的一部分，引入此依赖即可使用 RestClient 进行 HTTP 请求操作，它为我们提供了简洁、高效的声明式 HTTP 客户端功能，让我们可以轻松地与其他服务进行通信，就像是一把便捷的 “通信钥匙”。通过 RestClient，我们可以使用链式调用的方式构建 HTTP 请求，设置请求头、参数、请求体等，并且可以方便地处理响应结果，将响应数据自动映射到 Java 对象中。
此外，如果项目需要与服务发现组件（如 Eureka、Consul、Nacos 等）集成，还需要引入相应的依赖。以 Nacos 为例，需要引入com.alibaba.cloud:spring-cloud-starter-alibaba-nacos-discovery依赖，用于实现服务的注册与发现，使得各个微服务能够相互发现并进行通信，就像是在一个大型社区中，每个居民都有自己的地址（服务实例地址），并且能够通过社区的地址簿（服务发现组件）找到其他居民的地址，从而进行交流和合作。
（三）基础配置
在src/main/resources目录下的application.properties（或application.yml）文件中，我们需要进行一些基础配置：
- 服务地址和端口：配置当前服务的端口号，例如server.port=8081，指定服务监听的端口，就像是给服务分配一个 “门牌号”，让外界能够通过这个端口访问到服务。同时，如果需要调用其他服务，还需要配置目标服务的地址，如target.service.url=http://localhost:8082，明确要通信的目标服务的位置。
- 日志配置：为了方便调试，我们可以配置日志相关参数。在application.properties中添加如下配置：
logging.level.root=info
logging.level.com.example=debug
上述配置将根日志级别设置为info，表示记录一般的信息；将com.example包下的日志级别设置为debug，表示记录更详细的调试信息，这样在开发和调试过程中，我们可以通过查看日志了解程序的运行情况，及时发现和解决问题，就像是给程序安装了一个 “监控摄像头”，随时观察程序内部的运行状态 。
如果使用application.yml文件，配置如下：
server:port: 8081
logging:level:root: infocom.example: debug通过这些基础配置，我们为项目搭建了一个稳定的运行环境，为后续使用 RestClient 进行开发奠定了坚实的基础。
四、使用 Spring 6.1 RestClient 构建声明式 HTTP 客户端
（一）定义 HTTP 接口
在 Spring 6.1 中，我们可以通过使用@HttpExchange、@GetExchange、@PostExchange等注解来定义 HTTP 接口。以一个简单的用户服务接口为例：
import org.springframework.http.HttpMethod;
import org.springframework.web.bind.annotation.*;@HttpExchange(url = "http://user-service/users")
public interface UserServiceClient {@GetExchange("/{id}")User getUserById(@PathVariable("id") Long id);@PostExchangeUser createUser(@RequestBody User user);@PutExchange("/{id}")User updateUser(@PathVariable("id") Long id, @RequestBody User user);@DeleteExchange("/{id}")void deleteUser(@PathVariable("id") Long id);
}在上述代码中，@HttpExchange注解定义了接口的基础 URL，即所有方法的请求 URL 都将基于这个基础 URL 进行构建，就像是为接口搭建了一个 “地址框架”。@GetExchange、@PostExchange、@PutExchange和@DeleteExchange分别对应 HTTP 的 GET、POST、PUT 和 DELETE 方法，用于定义具体的请求操作，就像为每个方法贴上了一个明确的 “操作标签”。
接口中方法的参数含义如下：
- @PathVariable注解用于从 URL 路径中提取参数，例如@PathVariable("id") Long id表示从 URL 路径中提取名为 “id” 的参数，并将其赋值给id变量，就像从一个包裹上提取特定的信息标签。
- @RequestBody注解用于接收请求体中的数据，并将其转换为指定的 Java 对象，例如@RequestBody User user表示将请求体中的数据转换为User对象，就像将包裹中的物品取出并整理成特定的格式。
方法的返回值含义如下：
- User getUserById(@PathVariable("id") Long id)方法返回一个User对象，表示根据传入的id从远程服务获取到的用户信息，就像是从远程仓库中取出的特定物品。
- User createUser(@RequestBody User user)方法返回一个User对象，表示创建用户后返回的新用户信息，就像是提交订单后返回的订单确认信息。
- void deleteUser(@PathVariable("id") Long id)方法返回void，表示删除用户操作不需要返回具体的数据，只需要确保操作执行成功即可，就像清理垃圾不需要得到垃圾的反馈。
（二）配置 RestClient
配置 RestClient 可以通过RestClient.builder()来实现，以下是一个配置示例：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.ClientHttpRequestFactory;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;@Configuration
public class RestClientConfig {@Beanpublic RestClient restClient() {ClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();// 设置连接超时时间为5秒((HttpComponentsClientHttpRequestFactory) factory).setConnectTimeout(5000);// 设置读取超时时间为10秒((HttpComponentsClientHttpRequestFactory) factory).setReadTimeout(10000);return RestClient.builder().requestFactory(factory).baseUrl("http://user-service").build();}
}在上述配置中，我们首先创建了一个ClientHttpRequestFactory实例，这里使用HttpComponentsClientHttpRequestFactory，它基于 Apache HttpClient 实现，提供了更丰富的配置选项和更好的性能表现，就像是为 RestClient 选择了一辆高性能的 “交通工具”。
然后，通过((HttpComponentsClientHttpRequestFactory) factory).setConnectTimeout(5000)和((HttpComponentsClientHttpRequestFactory) factory).setReadTimeout(10000)分别设置了连接超时时间为 5 秒和读取超时时间为 10 秒，这两个时间设置非常重要，连接超时时间决定了客户端尝试建立与服务器连接的最长等待时间，如果超过这个时间仍未建立连接，就会抛出异常，就像是在等待公交车时，如果等了太久还没来，就会选择离开；读取超时时间决定了从服务器读取响应数据的最长等待时间，如果超过这个时间还未读取到完整的数据，也会抛出异常，就像是在下载文件时，如果长时间没有下载完成，就会提示下载失败。
接着，使用RestClient.builder()创建 RestClient 的构建器，并通过requestFactory(factory)设置请求工厂，baseUrl("http://user-service")设置基础 URL，最后通过build()方法构建出 RestClient 实例，就像是按照设计图纸，一步一步地组装出一辆完整的汽车。
如果需要添加拦截器，实现请求头处理、日志记录等功能，可以如下配置：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.ClientHttpRequestInterceptor;
import org.springframework.web.client.RestClient;import java.util.List;@Configuration
public class RestClientConfig {@Beanpublic RestClient restClient() {ClientHttpRequestInterceptor interceptor = (request, body, execution) -> {// 添加自定义请求头request.getHeaders().add("Custom-Header", "Value");// 记录请求日志System.out.println("Request URL: " + request.getURI());System.out.println("Request Headers: " + request.getHeaders());if (body != null) {System.out.println("Request Body: " + body);}return execution.execute(request, body);};return RestClient.builder().requestInterceptor(interceptor).build();}
}在上述代码中，我们定义了一个ClientHttpRequestInterceptor拦截器，在拦截器的intercept方法中，首先通过request.getHeaders().add("Custom-Header", "Value")添加了一个自定义请求头，就像是在包裹上贴上一个特殊的标签；然后通过打印语句记录了请求的 URL、请求头和请求体信息，就像是在发送包裹前，对包裹的信息进行详细记录，以便后续跟踪和排查问题。最后，通过requestInterceptor(interceptor)将拦截器添加到 RestClient 的配置中，使拦截器生效，就像是为汽车安装了一个特殊的装置，使其具备了新的功能。
（三）调用 HTTP 接口
在服务层或控制器层中，我们可以通过依赖注入的方式使用定义好的 HTTP 接口。以控制器层为例：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;@RestController
@RequestMapping("/users")
public class UserController {@Autowiredprivate UserServiceClient userServiceClient;@GetMapping("/{id}")public User getUser(@PathVariable("id") Long id) {return userServiceClient.getUserById(id);}@PostMappingpublic User createUser(@RequestBody User user) {return userServiceClient.createUser(user);}@PutMapping("/{id}")public User updateUser(@PathVariable("id") Long id, @RequestBody User user) {return userServiceClient.updateUser(id, user);}@DeleteMapping("/{id}")public void deleteUser(@PathVariable("id") Long id) {userServiceClient.deleteUser(id);}
}在上述代码中，通过@Autowired注解将UserServiceClient接口注入到UserController中，就像是将一把钥匙插入锁孔，使控制器能够使用接口提供的功能。
在各个请求处理方法中，直接调用UserServiceClient接口的相应方法来发起 HTTP 请求，就像是使用钥匙打开对应的门，获取门后的资源。例如，getUser方法中调用userServiceClient.getUserById(id)来获取用户信息，createUser方法中调用userServiceClient.createUser(user)来创建用户等。
在处理接口调用的返回结果时，对于成功的情况，直接返回接口调用的结果即可，就像是收到包裹后，直接将包裹中的物品展示出来。对于失败的情况，我们可以通过全局异常处理机制来统一处理。例如，在application.yml中配置全局异常处理器：
spring:mvc:throw-exception-if-no-handler-found: trueresources:add-mappings: false然后创建一个全局异常处理器类：
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.client.RestClientException;@ControllerAdvice
public class GlobalExceptionHandler {@ExceptionHandler(RestClientException.class)public ResponseEntity<String> handleRestClientException(RestClientException e) {return new ResponseEntity<>("HTTP request failed: " + e.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);}
}在上述代码中，@ControllerAdvice注解表示这是一个全局异常处理器，就像是一个 “超级管家”，负责处理所有控制器抛出的异常。@ExceptionHandler(RestClientException.class)注解表示处理RestClientException类型的异常，当接口调用失败抛出RestClientException异常时，会进入这个方法进行处理。在方法中，返回一个包含错误信息的ResponseEntity，状态码设置为HttpStatus.INTERNAL_SERVER_ERROR，就像是在包裹出现问题时，返回一个带有问题说明的反馈信息，让调用者能够清楚地知道发生了什么错误。
五、Spring 6.1 RestClient 的高级特性与优化
（一）负载均衡集成
在微服务架构中，负载均衡是提升系统可用性和性能的关键技术之一。Spring Cloud LoadBalancer 作为 Spring Cloud 生态中的客户端负载均衡器，为我们提供了强大的负载均衡功能。
要集成 Spring Cloud LoadBalancer，首先需要确保项目中引入了spring-cloud-starter-loadbalancer依赖，就像为系统安装了一个 “负载均衡引擎”。在前面搭建开发环境时，我们已经完成了这一步骤。
接下来，配置负载均衡策略。Spring Cloud LoadBalancer 仅支持轮询（Round Robin）和随机（Random）两种负载均衡策略。
以轮询策略为例，Spring Cloud LoadBalancer 的默认负载均衡策略就是轮询。在实际使用中，我们可以通过配置类来进一步明确这一策略。例如：
import org.springframework.cloud.loadbalancer.annotation.LoadBalancerClient;
import org.springframework.cloud.loadbalancer.core.RoundRobinLoadBalancer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.client.WebClient;@Configuration
@LoadBalancerClient(name = "user-service", configuration = UserServiceLoadBalancerConfig.class)
public class LoadBalancerConfig {@Beanpublic WebClient.Builder webClientBuilder() {return WebClient.builder();}public static class UserServiceLoadBalancerConfig {@Beanpublic RoundRobinLoadBalancer userServiceLoadBalancer() {// 这里可以根据需要进行更复杂的配置return new RoundRobinLoadBalancer();}}
}在上述代码中，@LoadBalancerClient注解用于指定该负载均衡策略针对的服务，name属性指定为 “user-service”，表示该策略应用于名为 “user-service” 的服务。在UserServiceLoadBalancerConfig内部类中，通过@Bean注解创建了一个RoundRobinLoadBalancer实例，明确了使用轮询策略对 “user-service” 进行负载均衡，就像是为 “user-service” 这个服务分配了一个按顺序分发请求的 “调度员”。
如果要使用随机策略，可以创建一个配置类来实现。示例代码如下：
import org.springframework.cloud.loadbalancer.annotation.LoadBalancerClient;
import org.springframework.cloud.loadbalancer.core.RandomLoadBalancer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;@Configuration
@LoadBalancerClient(name = "user-service", configuration = UserServiceRandomLoadBalancerConfig.class)
public class RandomLoadBalancerConfig {public static class UserServiceRandomLoadBalancerConfig {@Beanpublic RandomLoadBalancer userServiceRandomLoadBalancer() {// 这里可以根据需要进行更复杂的配置return new RandomLoadBalancer();}}
}在这段代码中，UserServiceRandomLoadBalancerConfig内部类通过@Bean注解创建了一个RandomLoadBalancer实例，这就为 “user-service” 服务设置了随机负载均衡策略，使得请求能够随机地被分配到 “user-service” 的不同实例上，就像是在众多服务实例中随机抽取一个来处理请求，增加了请求分配的随机性 。
（二）连接池配置
RestClient 通过ClientHttpRequestFactory来决定底层采用哪种 HTTP 连接，而不同的ClientHttpRequestFactory实现类对应着不同的连接池配置方式。以 Apache HttpClient 的连接池为例，它提供了丰富的配置选项，能够有效地提高 HTTP 请求的性能和稳定性，就像是为 HTTP 请求打造了一个高效的 “连接仓库”。
首先，需要在项目中引入 Apache HttpClient 的依赖：
<dependency><groupId>org.apache.httpcomponents</groupId><artifactId>httpclient</artifactId>
</dependency>上述依赖引入了 Apache HttpClient 库，为使用其连接池功能提供了基础，就像是为连接池配置准备了必要的 “工具”。
然后，配置连接池参数。以下是一个配置示例：
import org.apache.http.client.config.RequestConfig;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.impl.conn.PoolingHttpClientConnectionManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.ClientHttpRequestFactory;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;@Configuration
public class RestClientConnectionPoolConfig {@Beanpublic RestClient restClient() {PoolingHttpClientConnectionManager poolingHttpClientConnectionManager = new PoolingHttpClientConnectionManager();// 设置最大连接数为100poolingHttpClientConnectionManager.setMaxTotal(100);// 设置每个路由的默认最大连接数为20poolingHttpClientConnectionManager.setDefaultMaxPerRoute(20);RequestConfig requestConfig = RequestConfig.custom().setConnectTimeout(5000) // 设置连接超时时间为5秒.setSocketTimeout(10000) // 设置套接字超时时间为10秒.build();CloseableHttpClient closeableHttpClient = HttpClients.custom().setConnectionManager(poolingHttpClientConnectionManager).setDefaultRequestConfig(requestConfig).build();ClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(closeableHttpClient);return RestClient.builder().requestFactory(factory).build();}
}在上述配置中，首先创建了一个PoolingHttpClientConnectionManager实例，它是 Apache HttpClient 连接池的核心管理器，负责管理连接的创建、分配和回收，就像是连接池的 “大管家”。通过poolingHttpClientConnectionManager.setMaxTotal(100)设置了连接池的最大连接数为 100，这限制了连接池能够同时容纳的最大连接数量，避免资源过度消耗，就像是规定了仓库的最大容量；通过poolingHttpClientConnectionManager.setDefaultMaxPerRoute(20)设置了每个路由的默认最大连接数为 20，每个路由可以理解为到特定目标服务器的连接路径，这确保了每个目标服务器不会被过多的连接占用资源，就像是为每个货架规定了最大存放数量。
接着，创建了一个RequestConfig实例，用于配置请求的相关参数。通过setConnectTimeout(5000)设置连接超时时间为 5 秒，这表示在尝试建立与服务器的连接时，如果超过 5 秒还未成功建立连接，就会抛出异常，就像是在等待公交车时，如果等了 5 秒还没来，就会选择离开；通过setSocketTimeout(10000)设置套接字超时时间为 10 秒，这表示在从服务器读取数据时，如果超过 10 秒还未读取到数据，也会抛出异常，就像是在下载文件时，如果 10 秒还没有下载完成，就会提示下载失败。
然后，使用HttpClients.custom()创建一个CloseableHttpClient实例，并将之前配置好的连接管理器和请求配置应用到其中，就像是将 “大管家” 和 “规则手册” 整合到一个客户端中。
最后，创建一个HttpComponentsClientHttpRequestFactory实例，并将CloseableHttpClient传入其中，作为 RestClient 的请求工厂，这就像是为 RestClient 选择了一个使用特定连接池的 “交通工具”，使其能够利用连接池的功能来处理 HTTP 请求 。
（三）错误处理与重试机制
在 HTTP 请求过程中，难免会遇到各种错误，如网络故障、服务器过载等。因此，合理的错误处理和重试机制对于提高系统的稳定性和可靠性至关重要，就像是为系统穿上了一层 “防护铠甲”，能够在遇到问题时及时应对。
首先，展示如何自定义错误处理逻辑。我们可以通过实现ResponseErrorHandler接口来自定义错误处理逻辑。以下是一个示例：
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.stereotype.Component;
import org.springframework.web.client.ResponseErrorHandler;import java.io.IOException;@Component
public class CustomResponseErrorHandler implements ResponseErrorHandler {@Overridepublic boolean hasError(ClientHttpResponse response) throws IOException {// 判断响应状态码是否为错误状态码（4xx或5xx）int statusCode = response.getStatusCode().value();return statusCode >= 400;}@Overridepublic void handleError(ClientHttpResponse response) throws IOException {// 处理错误逻辑，例如记录日志、返回自定义错误信息等System.out.println("HTTP request failed with status code: " + response.getStatusCode());}
}在上述代码中，CustomResponseErrorHandler实现了ResponseErrorHandler接口。在hasError方法中，通过判断响应的状态码是否大于等于 400 来确定是否发生了错误，因为在 HTTP 协议中，4xx 和 5xx 状态码通常表示客户端或服务器端发生了错误，就像是在收到包裹时，通过检查包裹上的特定标记（状态码）来判断包裹是否有问题。在handleError方法中，简单地打印了错误状态码，实际应用中可以根据需求进行更复杂的处理，如记录详细的错误日志、返回自定义的错误信息给调用方等，就像是在发现包裹有问题时，根据问题的严重程度进行不同的处理，如拍照留证、联系寄件人等 。
接下来，配置 RestClient 使用自定义的错误处理器：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.ClientHttpRequestFactory;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;@Configuration
public class RestClientErrorConfig {@Beanpublic RestClient restClient(CustomResponseErrorHandler customResponseErrorHandler) {ClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();return RestClient.builder().requestFactory(factory).responseErrorHandler(customResponseErrorHandler).build();}
}在上述配置中，通过responseErrorHandler(customResponseErrorHandler)将自定义的错误处理器customResponseErrorHandler设置到 RestClient 中，使 RestClient 在处理 HTTP 响应时，能够使用我们自定义的错误处理逻辑，就像是为 RestClient 安装了一个定制的 “错误检测器”，能够按照我们的规则来检测和处理错误 。
为了实现重试机制，我们可以借助 Spring Retry 框架。首先，在项目中引入 Spring Retry 依赖：
<dependency><groupId>org.springframework.retry</groupId><artifactId>spring-retry</artifactId>
</dependency>上述依赖引入了 Spring Retry 框架，为实现重试机制提供了基础支持，就像是为系统添加了一个 “重试引擎”。
然后，配置重试逻辑。以下是一个示例：
import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.EnableRetry;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestClientException;@Service
@EnableRetry
public class UserService {@Retryable(value = RestClientException.class, maxAttempts = 3, backoff = @Backoff(delay = 2000))public User getUserById(Long id) {// 这里调用RestClient的方法来获取用户信息// 假设RestClient的调用逻辑在userServiceClient中return userServiceClient.getUserById(id);}
}在上述代码中，@EnableRetry注解开启了重试功能，就像是打开了 “重试引擎” 的开关。@Retryable注解用于标记需要重试的方法，value = RestClientException.class表示当方法抛出RestClientException异常时进行重试，这就像是给方法设置了一个 “异常检测器”，专门检测RestClientException异常；maxAttempts = 3表示最大重试次数为 3 次，即当方法调用失败并抛出指定异常时，会最多重试 3 次，就像是给方法的重试次数设置了一个上限；backoff = @Backoff(delay = 2000)表示每次重试之间的延迟时间为 2000 毫秒（2 秒），这就像是在每次重试之前，先等待 2 秒，给系统一些时间来恢复或解决问题 。通过这些配置，我们实现了在 HTTP 请求失败时自动重试的功能，有效地提高了系统的容错性和稳定性。
六、案例实战：替换 Feign 为 Spring 6.1 RestClient
（一）现有 Feign 项目分析
假设我们有一个电商系统，其中订单服务（Order Service）需要调用商品服务（Product Service）来获取商品信息。在现有的项目中，使用 Feign 来实现这一远程服务调用。
订单服务中定义了一个 Feign 客户端接口：
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;@FeignClient(name = "product-service")
public interface ProductFeignClient {@GetMapping("/products/{id}")Product getProductById(@PathVariable("id") Long id);
}在订单服务的业务逻辑中，通过注入ProductFeignClient来调用商品服务的接口：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;@Service
public class OrderService {@Autowiredprivate ProductFeignClient productFeignClient;public Order createOrder(Order order) {// 根据订单中的商品id获取商品信息Long productId = order.getProductId();Product product = productFeignClient.getProductById(productId);// 省略订单创建的其他逻辑return order;}
}随着业务的发展和用户量的增长，这个基于 Feign 的系统逐渐暴露出一些问题和痛点：
- 性能瓶颈：在高并发场景下，Feign 的动态代理机制带来的开销逐渐凸显，导致服务响应时间变长。当大量订单同时创建时，对商品服务的调用会变得缓慢，影响用户体验，就像交通拥堵时，车辆行驶速度会大幅下降。
- 配置复杂：Feign 的配置相对繁琐，特别是在处理一些高级特性时。如果需要自定义编码器、解码器或拦截器，需要编写大量的配置代码，增加了开发和维护的难度，就像搭建一个复杂的机器，需要不断调整各种参数和零件。
- 兼容性问题：在与最新的 Spring 版本集成时，Feign 可能会出现一些兼容性问题。当尝试将项目升级到最新的 Spring Boot 版本时，发现 Feign 与新的 Spring 特性之间存在不兼容的情况，导致部分功能无法正常使用，就像旧的软件插件无法在新的操作系统上运行。
（二）迁移步骤
- 接口定义的修改：将 Feign 接口转换为 Spring 6.1 RestClient 接口。首先，删除 Feign 相关的依赖和注解，引入 Spring Web 相关依赖，确保项目使用 Spring 6.1 及以上版本。
将上述 Feign 接口修改为 RestClient 接口：
import org.springframework.http.client.ClientHttpRequestFactory;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.web.client.RestClient;public interface ProductRestClient {default Product getProductById(Long id) {ClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();RestClient restClient = RestClient.builder().requestFactory(factory).baseUrl("http://product-service").build();return restClient.get().uri("/products/{id}", id).retrieve().body(Product.class);}
}在上述代码中，通过RestClient.builder()构建 RestClient 实例，设置请求工厂和基础 URL。然后使用链式调用的方式构建 GET 请求，设置请求 URI，并将响应体映射为Product对象。
- 配置文件的调整：在application.properties（或application.yml）文件中，可能需要调整一些与服务调用相关的配置。例如，原来在 Feign 中配置的超时时间、日志级别等，需要重新配置到 RestClient 相关的配置项中。
假设原来在application.yml中对 Feign 的配置如下：
feign:client:config:product-service:connectTimeout: 5000readTimeout: 10000loggerLevel: full迁移到 RestClient 后，配置如下：
spring:rest-client:product-service:connect-timeout: 5000read-timeout: 10000log-level: full这里将 Feign 的配置项转换为 RestClient 对应的配置项，确保服务调用的超时时间和日志级别等设置保持一致。
- 业务逻辑的调整：在订单服务的业务逻辑中，将对 Feign 客户端的依赖替换为对 RestClient 接口的依赖。
修改后的OrderService代码如下：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;@Service
public class OrderService {@Autowiredprivate ProductRestClient productRestClient;public Order createOrder(Order order) {Long productId = order.getProductId();Product product = productRestClient.getProductById(productId);// 省略订单创建的其他逻辑return order;}
}通过上述步骤，完成了从 Feign 到 Spring 6.1 RestClient 的接口定义、配置文件和业务逻辑的迁移。
（三）测试与验证
- 功能测试：编写单元测试用例，对替换后的接口进行功能测试。使用 JUnit 5 和 Mockito 框架，模拟远程服务的响应，验证接口的返回结果是否正确。
import org.junit.jupiter.api.Test; import org.mockito.Mockito; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.boot.test.mock.mockito.MockBean;import static org.junit.jupiter.api.Assertions.assertEquals;@SpringBootTest public class OrderServiceTest {@Autowiredprivate OrderService orderService;@MockBeanprivate ProductRestClient productRestClient;@Testpublic void testCreateOrder() {Long productId = 1L;Product product = new Product();product.setId(productId);product.setName("Test Product");Mockito.when(productRestClient.getProductById(productId)).thenReturn(product);Order order = new Order();order.setProductId(productId);Order createdOrder = orderService.createOrder(order);assertEquals(productId, createdOrder.getProductId());} }在上述测试用例中，使用MockBean注解创建ProductRestClient的模拟对象，通过Mockito.when(productRestClient.getProductById(productId)).thenReturn(product)模拟远程服务的响应。然后调用orderService.createOrder(order)方法，验证订单创建的功能是否正常，确保返回的订单中包含正确的商品信息。
- 性能测试：使用 JMeter 等性能测试工具，对替换前后的系统进行性能测试。模拟高并发场景，对比 Feign 和 RestClient 在不同并发用户数下的响应时间、吞吐量等性能指标。
假设在 JMeter 中，设置了一个线程组，包含 100 个线程，循环执行 1000 次订单创建操作。测试结果如下：
| 客户端 | 并发用户数 | 平均响应时间（ms） | 吞吐量（TPS） |
| ---- | ---- | ---- | ---- |
| Feign | 100 | 500 | 200 |
| RestClient | 100 | 300 | 300 |
从测试结果可以看出，在相同的并发用户数下，RestClient 的平均响应时间更短，吞吐量更高，展现出了更好的性能表现，就像一辆高性能的汽车，在高速行驶时更加稳定和快速。通过功能测试和性能测试，验证了将 Feign 替换为 Spring 6.1 RestClient 后的系统能够正常工作，并且在性能上有显著提升 。