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的情况下类是轮询。