这篇“SpringCloud Ribbon负载均衡使用策略是什么”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“SpringCloud Ribbon负载均衡使用策略是什么”文章吧。
Spring Cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端负载均衡工具，Ribbon客户端组件提供了一系列的完善的配置，如超时，重试等。
通过Load Balancer获取到服务提供的所有机器实例，Ribbon会自动基于某种规则(轮询，随机)去调用这些服务。Ribbon也可以实现我们自己的负载均衡算法。
负载均衡这个概念大家都不陌生，几乎可以说是互联网公司标配，目前主流负载方案主要分为以下两种：
集中式负载均衡，在消费者和服务提供方中间使用独立的代理方式进行负载，有硬件的（比如 F5），也有软件的（比如 Nginx）；客户端根据自身请求情况做负载均衡，Ribbon 就属于客户端自己做负载均衡，在dubbo中，客户端也可以配置负载均衡策略，也是类似的思想；
顾名思义，就是由客户端根据自身的情况做负载均衡策略的选择或配置，比如spring cloud中的ribbon，简单来说，当服务提供者将自身的服务注册到服务注册中心之后，客户端相应的会维护一个服务器地址列表，在发送请求前，先通过负载均衡算法选择一个服务器，然后进行访问，这就是客户端负载均衡，即在客户端就进行负载均衡算法分配。
如下，为ribbon作为客户端的负载均衡的调用流程图。
即集中式的管控负载均衡策略的组件，比如Nginx，即所有的请求过来之后，先通过Nginx进行负载均衡，先发送请求到具体的微服务，然后通过nginx中配置的负载均衡算法，在多个服务器之间选择一个进行访问，即在服务器端再进行负载均衡算法分配。
下面列举日常开发中经常用到的一些负载均衡算法，可以说很多组件的负载均衡的底层算法思想都是大同小异
通过随机选择集群中的某个可用的服务进行请求执行，在集群的各服务器配置差不多的情况下可以考虑使用，一般这种方式使用较少
负载均衡默认的实现方式，请求过来之后，依次轮流从可用服务中选择进行处理
通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;
根据请求的地址进行Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度， ip --->hash，这样相同请求的IP将会被打到相同的服务器处理；
即使请求均衡了，压力也不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分配到当前压力最小的服务器上，最小连接数也叫最小活跃数。
在springcloud-alibaba整合nacos中，客户端通过nacos进行服务调用默认使用的就是Ribbon负载均衡，只需下面两步
添加一个RestTemplate 的配置bean，使用LoadBalanced注解标注
@Configuration
public class RestConfig {
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}具体调用的时候，仍然使用restTemplate调用即可，如果服务端有多个实例，将会自动走默认负载均衡策略；
@RestController
@RequestMapping("/order")
public class OrderController {
@Autowired
RestTemplate restTemplate;
@Value("${service-url.nacos-user-service}")
private String serverURL;
//localhost:8083/order/add
@GetMapping("/add")
public String add(){
System.out.println("下单成功");
//String forObject = restTemplate.getForObject("http://localhost:8082/stock/reduct", String.class);
String forObject = restTemplate.getForObject(serverURL + "/stock/reduct", String.class);
System.out.println(forObject);
return "add order :" + forObject;
}
}通过完整的类的依赖关系图，可以看到Ribbon提供了很多种负载均衡策略，下面就Ribbon中常用的负载均衡策略做详细的解读。
这是所有负载均衡策略的父接口，里边的核心方法就是choose方法，用来选择一个服务实例
一个抽象类，里边主要定义了一个ILoadBalancer，这里定义它的目的主要是辅助负责均衡策略选取合适的服务端实例。
这种负载均衡策略就是随机从多个服务实例中选择一个服务实例
通过源码发现，在RandomRule的无参构造方法中初始化了一个Random对象，然后在它重写的choose方法又调用了choose(ILoadBalancer lb, Object key)这个重载的choose方法，在这个重载的choose方法中，每次利用random对象生成一个不大于服务实例总数的随机数，并将该数作为下标所以获取一个服务实例；
可以参阅源码
public Server choose(ILoadBalancer lb, Object key) {
if (lb == null) {
return null;
} else {
Server server = null;
while(server == null) {
if (Thread.interrupted()) {
return null;
}
List<Server> upList = lb.getReachableServers();
List<Server> allList = lb.getAllServers();
int serverCount = allList.size();
if (serverCount == 0) {
return null;
}
int index = this.chooseRandomInt(serverCount);
server = (Server)upList.get(index);
if (server == null) {
Thread.yield();
} else {
if (server.isAlive()) {
return server;
}
server = null;
Thread.yield();
}
}
return server;
}
}RoundRobinRule 这种负载均衡策略也叫线性轮询负载均衡策略
这个类的choose(ILoadBalancer lb, Object key)方法整体逻辑是这样的：
开启一个计数器count，在while循环中遍历务清单，获取清单之前先通过incrementAndGetModulo方法获取一个下标，这个下标是一个不断自增长的数先加1然后和服务清单总数取模之后获取到的（所以这个下标从来不会越界）；
然后拿着下标再去服务清单列表中取服务，每次循环计数器都会加1，如果连续10次都没有取到服务，则会报一个警告No available alive servers after 10 tries from load balancer: XXXX；
在轮询基础上重试，即这种负载均衡策略带有重试功能
它整体工作流程是这样：
首先RetryRule中定义了一个subRule，它的实现类是RoundRobinRule；
然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次还是采用RoundRobinRule中的choose规则来选择一个服务实例；
如果选到的实例正常就返回，如果选择的服务实例为null或者已经失效，则在失效时间deadline之前不断的进行重试（重试时获取服务的策略还是RoundRobinRule中定义的策略）；
如果超过了deadline还是没取到则会返回一个null；
顾名思义，带有权重功能，权重 — nacos的NacosRule ，Nacos还扩展了一个自己的基于配置的权重扩展
大致工作原理如下：
WeightedResponseTimeRule是RoundRobinRule的一个子类，在WeightedResponseTimeRule中对RoundRobinRule的功能进行了扩展；
WeightedResponseTimeRule中会根据每一个实例的运行情况来给计算出该实例的一个权重，然后在挑选实例的时候则根据权重进行挑选，这样能够实现更优的实例调用；
WeightedResponseTimeRule中有一个名叫DynamicServerWeightTask的定时任务，默认情况下每隔30秒会计算一次各个服务实例的权重；
权重计算规则很简单，如果一个服务的平均响应时间越短则权重越大，那么该服务实例被选中执行任务的概率也就越大；
这种策略实现很简单，内部定义了RoundRobinRule，choose方法还是采用了RoundRobinRule的 choose方法，所以它的选择策略和RoundRobinRule的选择策略一致，就不再过多不赘述。
BestAvailableRule继承自ClientConfigEnabledRoundRobinRule；
它在ClientConfigEnabledRoundRobinRule的基础上主要增加了根据loadBalancerStats中保存的服务实例的状态信息来过滤掉失效的服务实例的功能，然后顺便找出并发请求最小的服务实例来使用；
然而loadBalancerStats有可能为null，如果loadBalancerStats为null，则BestAvailableRule将采用它的父类即ClientConfigEnabledRoundRobinRule的服务选取策略（线性轮询）；
默认规则 ，复合判断server所在区域的性能和server的可用性选择服务器
ZoneAvoidanceRule是PredicateBasedRule的一个实现类，只不过这里多一个过滤条件；
ZoneAvoidanceRule中的过滤条件是以ZoneAvoidancePredicate为主过滤条件和以AvailabilityPredicate为次过滤条件组成的一个叫做CompositePredicate的组合过滤条件；
过滤成功之后，继续采用线性轮询(RoundRobinRule)的方式从过滤结果中选择一个出来；
先过滤掉故障实例，再选择并发较小的实例，具体来说，过滤掉一直连接失败的被标记为circuit tripped的后端Server，并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来 包含过滤server的逻辑，其实就是检查status里记录的各个Server的运行状态。
上面详细了解了Ribbon中的常用的一些负载均衡配置策略，接下来通过实际操作演示下如何修改Ribbon的负载均衡配置策略。
这是一种比较灵活的修改配置方式，只需要添加一个配置类，并配置指定的负载均衡bean即可
注意这里有个坑，自定义的配置类不能写在@SpringbootApplication注解的@CompentScan扫描得到的地方，否则自定义的配置类就会被所有的 RibbonClients共享。
因此实际开发中不建议这么使用，推荐yml方式
工程的目录结构如下
RibbonRandomRuleConfig 配置类
@Configuration
public class RibbonRandomRuleConfig {
@Bean
public IRule iRule(){
return new RandomRule();
}
}@SpringBootApplication
@RibbonClients(value = {
@RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})
public class RibbonOrderApp {
public static void main(String[] args) {
SpringApplication.run(RibbonOrderApp.class,args);
}
}分别启动stock-service的两个工程，再启动order工程，stock-service可以在idea中通过区分端口的方式
启动完成之后，检查nacos，可以看到stock-service有两个服务实例，这正好是我们希望的
调用order模块的接口：http://localhost:8030/order/add，由于是客户端负载均衡，而且我们配置的是随机的策略，预计在随机调用该接口之后，会呈现出不同的接口
多调用几次，可以看到8021与8023对应的服务不断交替出现，并且没什么规律
去掉启动类中的注解信息
@SpringBootApplication
/*@RibbonClients(value = {
@RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})*/
public class RibbonOrderApp {
public static void main(String[] args) {
SpringApplication.run(RibbonOrderApp.class,args);
}
}在配置文件下方增加如下配置，这里是哦也能够的是nacos提供的基于权重的策略，也可以选择其他的；
stock-service: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
在nacos服务列表那一栏，进入到如下所示 stock-servide具体的详情页面
分别编辑两个实例的权重大小，比如这里给8023实例权重为10，另一个保持默认为1
设置完成后按照预期猜想，设置权重更高的那个将会优先得到访问的机会，启动order服务，再次按照上面的方式调用多次观察效果
粗略统计发现，在10多次的请求中，权重高的那个被访问的次数更多，这也就符合我们的预期效果了；
从上面的ribbon类图可以发现，通过实现 IRule 接口可以自定义负载策略，主要的选择服务逻辑在 choose 方法中完成，最简单的就是继承AbstractLoadBalancerRule这个抽象类；
只需要继承AbstractLoadBalancerRule抽象类，并重写里面的choose方式，在该方式中，使用了类似的随机算法的策略，也可以根据自身的需求，定制特定的负载均衡算法；
public class CustomRule extends AbstractLoadBalancerRule {
private static Logger logger = LoggerFactory.getLogger(CustomRule.class);
@Override
public Server choose(Object o) {
ILoadBalancer loadBalancer = this.getLoadBalancer();
List<Server> reachableServers = loadBalancer.getReachableServers();
int i = ThreadLocalRandom.current().nextInt(reachableServers.size());
Server server = reachableServers.get(i);
return server;
}
@Override
public void initWithNiwsConfig(IClientConfig iClientConfig) {
}
}stock-service: ribbon: #NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule #使用自定义的负载均衡策略 NFLoadBalancerRuleClassName: com.ribbon.CustomRule
将上一步的nacos中stock-service的两个服务实例的权重都调整为1，然后再次访问接口，可以看到呈现出随机的效果；
Ribbon的负载均衡策略默认是懒加载，意味着只有在发起调用的时候才会创建客户端，这带来的问题是，如果网络不好，第一次调用的时候可能会出现调用超时，我们通过控制台日志也能看出来；
如何解决这个问题呢？可以手动开启饥饿加载，来解决第一次调用慢的问题，只需要在配置文件中添加如下配置即可；
ribbon: eager-load: # 开启ribbon饥饿加载 enabled: true # 配置stock-service使用ribbon饥饿加载，多个使用逗号分隔 clients: stock-service
再次重启order服务，通过控制台输出日志可以看到，在启动的时候负载均衡策略就被加载了；
Spring Cloud LoadBalancer是Spring Cloud官方自己提供的客户端负载均衡器, 用来替代
Ribbon
Spring 官方提供了两种负载均衡客户端
RestTemplate是 Spring提供的用于访问Rest服务的客户端，RestTemplate提供了多种便捷访问远程Http服务的方法，能够大大提高客户端的编写效率。默认情况下，RestTemplate默认依赖jdk的HTTP连接工具
WebClient是从Spring WebFlux 5.0版本开始提供的一个非阻塞的基于响应式编程的进行Http请求的客户端工具。它的响应式编程的基于Reactor的。WebClient中提供了标准Http请求方式对应的get、post、put、delete等方法，可以用来发起相应的请求
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!--nacos-config 配置中心-自带动态刷新--> <!--<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency>--> <!--nacos-discovery 注册中心-服务发现与注册--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <exclusions> <exclusion> <groupId>org.springframework.cloud</groupId> <artifactId>spring‐cloud‐starter‐netflix‐ribbon</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring‐cloud‐starter‐loadbalancer</artifactId> </dependency> </dependencies>
这里主要是将默认的ribbon的loadbalancer负载均衡策略禁用掉
server: port: 8033 spring: application: name: order-service cloud: nacos: discovery: server-addr: localhost:8848 #服务注册中心地址 #config: #server-addr: localhost:8848 #配置中心地址 loadbalancer: ribbon: enabled: false service-url: nacos-user-service: http://stock-service
@SpringBootApplication
//@EnableDiscoveryClient
public class BalancerOrderApp {
public static void main(String[] args) {
SpringApplication.run(BalancerOrderApp.class,args);
}
}启动stock-service和当前order模块，启动完成后，界面调用：localhost:8033/order/add
loadbalancer默认走的是轮询策略，通过反复调用上面的接口，可以看到请求的结果端口显示看，是stock-service两个服务轮着来的；
以上就是关于“SpringCloud Ribbon负载均衡使用策略是什么”这篇文章的内容，相信大家都有了一定的了解，希望小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
