SpringCloud学习笔记(四) Ribbon负载均衡

概述

Github地址

源码中的ribbon-loadbalancer比较重要，/ribbon-loadbalancer/src/main/java/com/netflix/loadbalancer下的IRule.java、AbstractLoadBalancer.java

是什么

Spring Cloud Ribbon是基于Ntflix Ribbon实现的一套客户端负载均衡的工具。

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时、重试等。简单的说，就是在配置文件中列出Load Balancer (简称LB)后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

能干嘛

LB，即负载均衡(Load Balance)，在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。
常见的负载均衡有软件Nginx,、LVS、 硬件F5等。
相应的在中间件，例如dubbo和SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。

集中式LB：偏硬件

即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件 如F5, 也可以是软件 如nginx）, 由该设施负责把访问请求通过某种策略转发至服务的提供方

进程式LB：偏软件

将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

Ribbon配置初步

修改consumer80的pom文件

<!-- 添加如下依赖 -->
<!--Ribbon相关-->
<dependency>
    <!--Ribbon需要跟Eureka整合-->
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

consumer80的application.yml

追加Eureka的服务注册地址

eureka:
  client:                  #客户端注册进Eureka服务列表内
    register-with-eureka: false
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

consumer80的ConfigBean

在getRestTemplate方法上增加@LoadBalanced注解，默认的是轮询算法

consumer80的主启动类

添加@EnableEurekaClient注解

consumer80的DeptController_Consumer

将请求地址由写死的http://localhost:8001改为http://MICROSERVICECLOUD-DEPT

private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";

总结

Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号

Ribbon负载均衡

架构

Ribbon在工作时分成两步
第一步先选择EurekaServer，它优先选择在同一个区域内负载较少的server。
第二步再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。

其中Ribbon提供了多种策略，比如轮询、随机和根据响应时间加权。

新建provider8002与provider8003

仿照provider8001新建，修改pom依赖、启动类名称、yml

其中yml要修改端口、数据库、eureka.instance.instance-id，而对外暴露的微服务的名字spring.application.name=microservicecloud-dept不能改，三者保持一致

启动

先启动三个Eureka，再启动三个provider，最后启动consumer80，通过consumer80去调用，会发现三个provider服务是通过轮询的方式被调用。

总结

Ribbon其实就是一个软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和eureka结合只是其中的一个实例。

Ribbon核心组件IRule

IRule：根据特定算法，从服务列表中选取一个要访问的服务

1. RoundRobinRule 轮询
2. RandomRule 随机
3. AvailabilityFilteringRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问
4. WeightedResponseTimeRule 根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大，被选中的概率越高。刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够，会切换到WeightedResponseTimeRule
5. RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务
6. BestAvailableRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器
7. ZoneAvoidanceRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器

默认使用的是轮询算法，要想指定所使用的算法，可以修改consumer80的ConfigBean配置

// 新增方法
@Bean
public IRule myRule(){
    return new RoundRobinRule(); //用随机算法代替默认的轮询算法
}

Ribbon自定义

官方文档明确给出了警告：

这个自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，也就是说达不到特殊化定制的目的了。主启动类上有@SpringBootApplication注解，点进去有@ComponentScan注解，也就是说，自定义配置类不能放在主启动类所在的包以及子包下。

Consumer80启动类

在启动该微服务的时候就能去加载我们的自定义Ribbon配置类，从而使配置生效，形如：
@RibbonClient(name = "MICROSERVICECLOUD-DEPT",configuration = MySelfRule.class)

com.demo.MyRule.MySelfRule

@Configuration
public class MySelfRule {
    @Bean
    public IRule myRule(){
        return new RandomRule();
    }
}

若给出的7种特定算法不能满足自定义的需求，可以从github上拷贝该类的源码修改，比如要修改RandomRule算法，可以拷贝这个类（github上RandomRule源码）,重命名一下，修改其内部逻辑，然后在MySelfRule类的myRule方法中调用自定义的这个类。