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>
step2 搞注解 （在RestTemplate上加入@LoadBalanced注解）
@Configuration public class WebConfig { @Bean @LoadBalanced public RestTemplate restTemplate(){ return new RestTemplate(); } }
Step3 搞配置文件
这里是写Nacos 的配置文件,暂时没有配置Ribbon的配置
spring: cloud: nacos: discovery: server-addr: 1.117.97.88:8848 application: name: artisan-order-center
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; } }
验证
日志如下
可以猜测，默认策略为轮询算法
修改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的情况下类是轮询。
