我们这里通过Ribbon组件来实习负载均衡 【默认的负载均衡算法是 轮询】
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-alibaba-nacos-discoveryartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-ribbonartifactId>
dependency>
@Configuration
public class WebConfig {
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
这里是写Nacos 的配置文件,暂时没有配置Ribbon的配置
spring:
cloud:
nacos:
discovery:
server-addr: 1.117.97.88:8848
application:
name: artisan-order-center
作为服务提供方,仅需要注册到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;
}
}
分别请求三次
日志如下
可以猜测,默认策略为轮询算法
请求三次
可以看到是采用的策略设计模式,公共的都写到了抽象类中
随机选择一个Server
对选定的负载均衡策略机上重试机制,在一个配置时间段内当选择Server不成功,则一直尝试使用subRule的方式选择一个可用的server.
轮询选择, 轮询index,选择index对应位置的Server
过滤掉一直连接失败的被标记为circuit tripped的后端Server,并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来包含过滤server的逻辑,其实就就是检查status里记录的各个Server的运行状态
选择一个最小的并发请求的Server,逐个考察Server,如果Server被tripped了,则跳过。
根据响应时间加权,响应时间越长,权重越小,被选中的可能性越低;
复合判断Server所在Zone的性能和Server的可用性选择Server,在没有Zone的情况下类是轮询。