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文件
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-eurekaartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-ribbonartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-configartifactId>
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：根据特定算法，从服务列表中选取一个要访问的服务
- RoundRobinRule 轮询
- RandomRule 随机
- AvailabilityFilteringRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问
- WeightedResponseTimeRule 根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大，被选中的概率越高。刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够，会切换到WeightedResponseTimeRule
- RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务
- BestAvailableRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器
- 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方法中调用自定义的这个类。