除了选用Ribbon官方提供的均衡策略外,我们也可以自定义均衡策略。
<br/>
在消费端 cloud-comsumer-order80 自定义均衡策略的步骤如下:
**1. 自定义我们的均衡策略**
(1)需求:Ribbon默认的轮询策略是每台机器一次,然后轮到下一个机器。现在要求在轮询策略的基础上加上新的需求,即每个服务器要求被调用5次才开始轮到下一个服务器。
(2)下面先让我们来看一下 RandomRule 均衡策略的源码,了解它的基本原理。
*`com.netflix.loadbalancer.RandomRule`*
```java
package com.netflix.loadbalancer;
import com.netflix.client.config.IClientConfig;
import edu.umd.cs.findbugs.annotations.SuppressWarnings;
import java.util.List;
import java.util.Random;
public class RandomRule extends AbstractLoadBalancerRule {
Random rand = new Random();
public RandomRule() {
}
/**
* 其实实现其主要作用的就是该方法
*/
@SuppressWarnings({"RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE"})
public Server choose(ILoadBalancer lb, Object key) {
if (lb == null) {
return null;
} else {
Server server = null;
while(server == null) {
if (Thread.interrupted()) {
return null;
}
// 1. 获取所有可用的服务
List<Server> upList = lb.getReachableServers();
// 2. 获取所有的服务,可用的和不可用的
List<Server> allList = lb.getAllServers();
int serverCount = allList.size();
if (serverCount == 0) {
return null;
}
// 3. 可以看到随机就是随机地在一个可用的服务列表中随机的返回一个Server
int index = this.rand.nextInt(serverCount);
server = (Server)upList.get(index);
if (server == null) {
Thread.yield();
} else {
if (server.isAlive()) {
return server;
}
server = null;
Thread.yield();
}
}
return server;
}
}
/**
* 该方法返回最终选择的均衡器
*/
public Server choose(Object key) {
return this.choose(this.getLoadBalancer(), key);
}
public void initWithNiwsConfig(IClientConfig clientConfig) {
}
}
```
(3)根据上面的需求实现的自定义均衡器如下。
```java
public class MyRoundRibbonByFiveRule extends AbstractLoadBalancerRule {
/**
* 每台总共被调用的次数,目前要求每台被调用5次
*/
private int total = 0;
/**
* 当前提供服务的机器号
*/
private int currentIndex = 0;
public Server choose(ILoadBalancer lb, Object key) {
if (lb == null) {
return null;
}
Server server = null;
while (server == null) {
if (Thread.interrupted()) {
return null;
}
// (1)获取所有可用的机器和所有机器(包括可用的和不可用的)
List<Server> upList = lb.getReachableServers();
List<Server> allList = lb.getAllServers();
int serverCount = allList.size();
if (serverCount == 0) {
return null;
}
// (2)根据需求设计的均衡器选择规则如下
// int index = rand.nextInt(serverCount);
// server = upList.get(index);
if (total < 5) {
server = upList.get(currentIndex);
total++;
} else {
total = 0;
currentIndex++;
if (currentIndex >= upList.size()) {
currentIndex = 0;
}
}
if (server == null) {
Thread.yield();
continue;
}
if (server.isAlive()) {
return (server);
}
server = null;
Thread.yield();
}
return server;
}
@Override
public Server choose(Object key) {
return choose(getLoadBalancer(), key);
}
@Override
public void initWithNiwsConfig(IClientConfig clientConfig) {
// TODO Auto-generated method stub
}
}
```
**2. 将自定义的均衡器进行装配**
有一个要求:<mark>就是装配自定义均衡器的类不能在`@ComponentScan`的包及其子包下</mark>,如下的启动类。
```java
// 1. @SpringBootApplication标注的类为启动类
@SpringBootApplication
public class OrderMain80
{
public static void main(String[] args) {
SpringApplication.run(OrderMain80.class, args);
}
}
// 2. @SpringBootApplication用到了@ComponentScan
@ComponentScan(
excludeFilters = {@Filter(
type = FilterType.CUSTOM,
classes = {TypeExcludeFilter.class}
), @Filter(
type = FilterType.CUSTOM,
classes = {AutoConfigurationExcludeFilter.class}
)}
)
public @interface SpringBootApplication {
// 3. 所以就是装配自定义均衡器的类不能与启动类同级目录,或者子目录。
```
说了这么多,下面就将自定义的均衡器进行装配。
```java
/**
* 注意:我当前模块的启动类位置在 com.atguigu.springcloud.OrderMain80
* 所以当前装配的自定义均衡策略的类不能定义在com.atguigu.springcloud包下及其子包下
*/
@Configuration
public class MyRoundRibbonByFiveRuleConfig {
/**
* 将自定义的均衡器进行装配。
*/
@Bean
public IRule myRoundRibbonByFiveRule() {
return new MyRoundRibbonByFiveRule();
}
}
```
**3. 在消费端启动类上添加注解`@RibbonClient`**
```java
@SpringBootApplication
@EnableEurekaClient
/**
* name:服务端的 spring.application.name 配置
* configuration:我们自定义的均衡策略
*/
@RibbonClient(name = "${provider.payment.name}",configuration = MyRoundRibbonByFiveRuleConfig.class)
public class OrderMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderMain80.class,args);
}
}
```
**4. 测试效果**
访问消费端的 http://localhost/order/idport ,经过测试,确实刷新5次后才会更换下一个服务器。
- 微服务
- 微服务是什么?
- 微服务架构
- 微服务优缺点
- 微服务技术栈
- 微服务框架对比
- SpringCloud
- SpringCloud是什么
- SpringCloud与SpringBoot对比
- SpringCloud与Dubbo对比
- Rest微服务案例
- 总体介绍
- 父工程构建步骤
- 公共模块构建步骤
- 服务端模块构建步骤
- 消费端模块构建步骤
- Eureka服务注册与发现
- Eureka是什么
- Eureka原理
- Eureka注册服务中心构建
- 向Eureka注册已有微服务
- Eureka的自我保护机制
- Eureka服务发现
- Eureka集群配置
- Eureka与Zookeeper对比
- Ribbon负载均衡
- Ribbon是什么
- Ribbon负载均衡演示
- 构建服务端模块
- 构建消费端模块
- Ribbon核心组件IRule
- 自定义负载均衡策略
- Ribbon均衡策略优先级
- 轮询策略算法
- OpenFeign负载均衡
- OpenFeign是什么
- 负载均衡演示
- 日志打印功能
- 导出功能
- Hystrix断路器
- Hystrix是什么
- 服务熔断
- Hystrix服务端构建
- 服务熔断演示
- 服务熔断类型
- HystrixProperty配置汇总
- 服务降级
- Hystrix客户端构建
- 服务降级演示
- fallbackFactory
- 熔断与降级
- 服务监控
- 网关服务Zuul
- Zuul是什么
- Zuul路由服务构建
- 设置访问映射规则
- Config分布式配置中心
- Config分布式配置中心是什么
- Config服务端与Git通信
- Config客户端获取配置
- Config客户端动态刷新
- Bus消息总线
- Bus消息总线是什么
- Bus消息总线原理
- 广播通知设计思想
- 广播通知演示
- 定点通知演示
- Stream消息驱动
- 为什么要引入Stream
- Stream消息驱动是什么
- Stream设计思想
- Stream流程和注解
- Stream案例演示
- 重复消费问题
- 消息持久化
- Sleuth分布式链路跟踪
- Sleuth是什么
- 搭建链路监控
- SpringCloud Alibaba
- Nacos注册与配置中心
- Nacos是什么
- 安装并运行Nacos
- Nacos注册中心
- 服务端入住Nacos
- 消费端入住Nacos
- Nacos负载均衡演示
- 服务注册中心对比
- Nacos的AP和CP转化
- Nacos配置中心
- 基础配置演示
- Nacos分类配置
- Nacos集群搭建
- Sentinel实现熔断与限流
- Sentinel是什么
- Sentinel环境搭建
- Sentinel监控微服务演示
- Sentinel流控规则
- 流量监控的作用
- 设置流控规则
- Sentinel降级规则
- 熔断降级作用
- 设置降级规则
- Sentinel热点限流
- 什么是热点
- 设置热点限流
- Sentinel系统限流
- @SentinelResource
- @SentinelResource属性
- @SentinelResource限流演示
- @SentinelResource熔断演示
- 规则持久化
- 熔断框架比较
- Seata分布式事务
- 分布式事务问题
- Seata是什么
- Seata分布式事务过程
- Seata环境搭建
- 演示示例
- 业务说明
- 数据库环境准备
- 微服务环境准备
- 测试
- Consul服务注册与发现
- Consul是什么
- Consul能做什么
- 环境搭建
- Windows平台
- 服务端入住Consul
- 消费端入住Consul
- 注册中心对比
- Zookeeper服务注册与发现
- Zookeeper是什么
- 环境搭建
- 服务端入住Zookeeper
- 消费端入住Zookeeper
- 网关服务Gateway
- Gateway是什么
- Gateway能做什么
- Gateway对比Zuul
- 三大核心概念
- Gateway工作流
- 环境搭建
- 网关路由配置方式
- 配置文件配置
- 代码中配置
- 动态路由
- Predicate断言
- 断言是什么
- 常用断言
- Filter过滤器
- 过滤器是什么
- 过滤器种类
- 自定义过滤器