Ribbon整合三部曲

我们这里通过Ribbon组件来实习负载均衡 【默认的负载均衡算法是 轮询】

artisan-cloud-ribbon-order

step1 搞依赖

   <!--nacos-client-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-nacos-discovery</artifactId>
        </dependency>

        <!--加入ribbon-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
        </dependency>

  
 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
 

step2 搞注解 （在RestTemplate上加入@LoadBalanced注解）

@Configuration
public class WebConfig {
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

  
 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
 

Step3 搞配置文件

这里是写Nacos 的配置文件,暂时没有配置Ribbon的配置

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 1.117.97.88:8848
        
  application:
    name: artisan-order-center

  
 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

artisan-cloud-ribbon-product

作为服务提供方，仅需要注册到Nacos , 无需集成Ribbon, 启动多个测试Ribbon的负载策略即可。

@RestController
@Slf4j
public class ProductInfoController {

    @Value("${server.port}")
    private Integer port;

    @Autowired
    private ProductInfoMapper productInfoMapper;

    @RequestMapping("/selectProductInfoById/{productNo}")
    public Object selectProductInfoById(@PathVariable("productNo") String productNo) {
        log.info("{} 被请求了",port);
        ProductInfo productInfo = productInfoMapper.selectProductInfoById(productNo);
        return productInfo;
    }

}

  
 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
 

验证

分别请求三次

日志如下

可以猜测，默认策略为轮询算法

修改Ribbon默认的负载策略

请求三次

Ribbon的内置的负载均衡算法

类关系 （IRule接口 AbstractLoadBalancerRule抽象类）

可以看到是采用的策略设计模式，公共的都写到了抽象类中

负载均衡算法

RandomRule

随机选择一个Server

RetryRule

对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server.

RoundRobinRule

轮询选择， 轮询index，选择index对应位置的Server

AvailabilityFilteringRule

过滤掉一直连接失败的被标记为circuit tripped的后端Server，并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态

BestAvailableRule

选择一个最小的并发请求的Server，逐个考察Server，如果Server被tripped了，则跳过。

WeightedResponseTimeRule

根据响应时间加权，响应时间越长，权重越小，被选中的可能性越低；

ZoneAvoidanceRule（默认）

复合判断Server所在Zone的性能和Server的可用性选择Server，在没有Zone的情况下类是轮询。

源码

https://github.com/yangshangwei/SpringCloudAlibabMaster

文章来源: artisan.blog.csdn.net，作者：小小工匠，版权归原作者所有，如需转载，请联系作者。

原文链接：artisan.blog.csdn.net/article/details/122770934