Spring Cloud Alibaba - 07 Ribbon 应用篇及内置的负载均衡算法

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
- 点赞
- 收藏
- 关注作者
 
             
           
评论(0)