Ribbon单独使用，配置自动重试，实现负载均衡和高可用

比眉伴天荒 2023-10-09 09:37 9阅读 0赞

## 一、前言 ##

### **1.1 实现目标** ###

服务A调用服务B1和B2（B1和B2提供同种服务），当服务B1/B2在停止和重新发布阶段，或B1/B2有一个服务故障时，

*  需保证服务A正常调用B服务，达到无感知发布的效果（服务B高可用）
 *  需保证服务A的请求负载均衡，避免某个B服务节点压力过大（服务B负载均衡）

**说明**：这里是独立使用Ribbon，不依赖于Eureka、Zookeeper等任何服务注册发现组件。

### **1.2 环境** ###

JDK 1.8，SpringCloud Greenwich.SR2，SpringBoot 2.1.3.RELEASE

## 二、实现 ##

本文示例，CONSUMER-SERVICE服务调用*PRODUCER-SERVICE*服务。在进行以下步骤前，请先启动两个普通的SpringBoot服务*PRODUCER-SERVICE*。

### 2.1 pom依赖 ###

因为这里独立使用Ribbon，所以*CONSUMER-SERVICE*只需要spring-cloud-starter-netflix-ribbon，启动主类也无需更多的注解，如

@EnableEurekaClient、@EnableDiscoveryClient、@EnableCircuitBreaker等，只需保留@SpringBootApplication即可。

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
        </dependency>
    </dependencies>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Greenwich.SR2</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

### 2.2 RestTemplate配置 ###

Ribbon是对RestTemplate的加强，需要为RestTemplate添加注解***@LoadBalanced***，使之具有负载均衡能力。如下：

@Bean
    @LoadBalanced
    public RestTemplate restTemplate(ClientHttpRequestFactory factory) {
        RestTemplate restTemplate = new RestTemplate(factory);
        restTemplate.getMessageConverters().set(1, new StringHttpMessageConverter(StandardCharsets.UTF_8));
        return restTemplate;
    }

### 2.3 Ribbon配置 ###

**注意**：网上和书上很多教程都没有提到***ribbon.restclient.enabled***这一配置，导致再怎么尝试都无法成功自动重试。

spring.application.name=CONSUMER-SERVICE
    server.port=8801
    
    ribbon.restclient.enabled=true
    #开启重试机制
    spring.cloud.loadbalancer.retry.enabled=true
    #请求连接的超时时间
    PRODUCER-SERVICE.ribbon.ConnectTimeout=250
    #请求处理的超时时间
    PRODUCER-SERVICE.ribbon.ReadTimeout=1000
    #对所有操作请求都进行重试，默认false，只有GET请求会重试；这是防止POST等对数据有影响的请求在重试后因为接口未做幂等性导致数据异常，影响较大
    PRODUCER-SERVICE.ribbon.OkToRetryOnAllOperations=true
    #指定请求重试开关，经调试源码该属性未被使用，疑似bug，导致不论怎么设置，都是只有服务提供者的Get请求可以被自动重试
    #PRODUCER-SERVICE.ribbon.RequestSpecificRetryOn=true
    #切换实例的重试次数
    PRODUCER-SERVICE.ribbon.MaxAutoRetriesNextServer=2
    #对当前实例的重试次数
    PRODUCER-SERVICE.ribbon.MaxAutoRetries=1
    
    #服务PRODUCER-SERVICE的地址
    PRODUCER-SERVICE.ribbon.listOfServers=localhost:8080,localhost:8083

### **2.4 Ribbon调用服务** ###

在Controller中，注入RestTemplate，使用服务名（即*spring.application.name*）的方式，调用*PRODUCER-SERVICE*服务的**GET**接口，如下：

@Controller
    @RequestMapping("consumer/api")
    public class ConsumerController {
        @Autowired
        private RestTemplate restTemplate;
    
        @GetMapping("/test")
        @ResponseBody
        public String test() {
            ResponseEntity<String> entity = restTemplate
                    .getForEntity("http://PRODUCER-SERVICE/outer/data?res=3&msgKey=token123", String.class);
            return entity.getBody();
        }
    }

## 三、测试运行 ##

### 3.1 负载均衡测试 ###

启动一个消费者服务*CONSUMER-SERVICE*，多次访问*/consumer/api/test*，可以通过给*PRODECER-SERVICE*服务的*/outer/data*接口添加调试日志的打印，来确认默认使用了轮询的负载均衡策略。

### 3.2 高可用测试 ###

停止其中一个*PRODECER-SERVICE*服务实例，确认轮询到已停止的服务时，可以成功地在未停止的服务上自动重试请求。

## 四、无法成功自动重试的几种情况 ##

本人在单独使用Ribbon的过程中，碰到以下几种无法自动重试其他服务节点的情况：

### 4.1 ribbon.restclient.enabled ###

遇到Ribbon的问题，网上一搜，千篇一律，也不知道作者们是否亲自实践证明可用，就随意发篇文章。言归正传，若不设置***ribbon.restclient.enabled=true***，在本人的实验环境中是无法自动重试的。

### 4.2 Maven打包有警告 ###

在SpringCloud生态的开发中，各组件往往自动依赖了很多其他的jar包，如果向Maven本地仓库下载的过程中，网络不好，就会下载到一份不完整的jar包或pom文件，最终可能会导致打包出错。下面是在使用Maven打包项目时，比较常见下面的警告：

[WARNING] The POM for com.sun.jersey:jersey-core:jar:1.19.1 is invalid, transitive dependencies (if any) will not be available
    [WARNING] The POM for com.sun.jersey:jersey-client:jar:1.19.1 is invalid, transitive dependencies (if any) will not be available
    ...

可以看出来，提示我们传递依赖将失效，所以有可能整个打包过程是***SUCCESS***的，但是最后启动jar包时，却可能报NoClassDef等缺少jar包的错误。因此，我们需要在打包时加上参数 ***-X*** 以查看具体原因：

[WARNING] The POM for com.sun.jersey:jersey-core:jar:1.19.1 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.jersey:jersey-core:[unknown-version]
    [FATAL] Non-parseable POM E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom: processing instruction can not have PITarget with reserved xml name (position: END_TAG seen ...</properties>\n\n</project>\n<?xml ... @627:7)  @ E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom, line 627, column 7
    
    [WARNING] The POM for com.sun.jersey:jersey-client:jar:1.19.1 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.jersey:jersey-client:[unknown-version]
    [FATAL] Non-parseable POM E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom: processing instruction can not have PITarget with reserved xml name (position: END_TAG seen ...</properties>\n\n</project>\n<?xml ... @627:7)  @ E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom, line 627, column 7
    
    [WARNING] The POM for com.sun.jersey.contribs:jersey-apache-client4:jar:1.19.1 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.jersey.contribs:jersey-apache-client4:[unknown-version]
    [FATAL] Non-parseable POM E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom: processing instruction can not have PITarget with reserved xml name (position: END_TAG seen ...</properties>\n\n</project>\n<?xml ... @627:7)  @ E:\maven\repository\com\sun\jersey\jersey-project\1.19.1\jersey-project-1.19.1.pom, line 627, column 7

特别注意*FATAL*这个最严重的日志级别的信息， 日志提醒我们本地仓库的pom文件*E:\\maven\\repository\\com\\sun\\jersey\\jersey-project\\1.19.1\\jersey-project-1.19.1.pom*解析出错，然后我们去此目录下，可以发现这个文件未被下载完整。最后的解决方式是删除此文件的父目录，重新打包，则会自动下载一份完整的pom文件，警告消失，打包成功。

### 4.3 OkToRetryOnAllOperations和RequestSpecificRetryOn失效 ###

在上文的例子中，消费者服务调用的生产者服务接口是**GET**类型，自动重试没有任何问题。接着，本人尝试让消费者调用生产者服务的**POST**接口，同时仍然设置了***ribbon.OkToRetryOnAllOperations=true***，结果无法成功重试，然后去调试ribbon源码，查看自动重试机制，经查，***OkToRetryOnAllOperations***和***RequestSpecificRetryOn***属性可以成功获取到，但***RequestSpecificRetryOn***并未被获取出来使用，疑似Ribbon的bug。这里记录一下调试的重要部分，

（1）Ribbon配置属性类com.netflix.client.config.CommonClientConfigKey；

（2）Ribbon判断是否重试：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70 2][]

所以，单独使用Ribbon需谨慎！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20190927172525567.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20190927172553220.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20190927172611471.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nvbmd6ZWhhbw==,size_16,color_FFFFFF,t_70