Ribbon源码分析(负载均衡源码)

@Bean
@LoadBalanced //ribbon 的负载均衡注解

public RestTemplate restTemplate() {

return new RestTemplate();
}

加了@LoadBalanced //ribbon 的负载均衡注解的RestTemplate，是必须要走Ribbon 的流程（见4.1）的。接上文，如果想用原生的RestTemplate，要新new一个。

4.Ribbon 源码分析

4.1 Ribbon 要做什么事情？

先通过 “http://” + serviceId + “/info” 我们思考 ribbon 在真正调用之前需要做什么？

restTemplate.getForObject(“http://provider/info”, String.class);

想要把上面这个请求执行成功，我们需要以下几步

1. 拦截该请求；

2. 获取该请求的 URL 地址:http://provider/info

3. 截取 URL 地址中的 provider

4. 从服务列表中找到 key 为 provider 的服务实例的集合(服务发现(Eureka))

5. 根据负载均衡算法选出一个符合的实例

6. 拿到该实例的 host 和 port，重构原来 URL 中的 provider

7. 真正的发送 restTemplate.getForObject(“http://ip:port/info”，String.class)

4.2 Ribbon 负载均衡的测试

4.3 从 choose 方法入手，查看 Ribbon 负载均衡的源码

走进 getServer()方法

在 chooseServer()里面得到 rule 是哪个对象

发现当前的 rule 是 ZoneAvoidanceRule 对象，而他只有一个父类 PredicateBasedRule

最终进入 PredicateBasedRule 类的 choose()方法


com.netflix.loadbalancer.AbstractServerPredicate#incrementAndGetModulo

每请求一次，请求次数加1（CAS自增），next的值通过取模的方式得到，请求次数%机器数量。
2台机器：
1 mod 2=1 2 mod 2=0 3 mod 2=1 4 mod 2=0…
三台机器：
1 mod 3=1 2 mod 3=2 3 mod 3 = 0 4 mod 3=1 5 mod 3=2…

4.4 负载均衡之前的服务列表是从何而来呢？

Ribbon 里面有没有服务列表？

• Ribbon 只做负载均衡和远程调用
• 服务列表从哪来？ 从 eureka 来
• Ribbon 有一个核心接口 ILoadBalance（承上(eureka)启下（Rule））
• 我们发现在负载均衡之前，服务列表已经有数据了

重点接口 ILoadBalancer


Ribbon 没有服务发现的功能，但是 eureka 有，所以 ribbon 和 eureka 完美结合，我们继续干源码学习

第二步从服务列表中选一个实例 用到了负载均衡

首先关注这两个集合，就是存放从 eureka 服务端拉取的服务列表然后缓存到本地

我们去看 DynamicServerListLoadBalancer 类如何获取服务列表，然后放在 ribbon 的缓存里面

ServerList 实现类（DiscoveryEnabledNIWSServerList）

如果服务状态是up 则放入list集合中
再回到 BaseLoadBalancer 中真正的存放服务列表

最后我们得知，只有在初始化 DynamicServerListLoadBalancer 类时，去做了服务拉取和缓存也就是说并不是服务一启动就拉取了服务列表缓存起来，流程图如下:

4.5 Ribbon 把 serverList 缓存起来，脏读怎么处理？（选学）

根据上面缓存服务列表我们得知，ribbon 的每个客户端都会从 eureka-server 中把服务列表缓存起来
主要的类是 BaseLoadBalancer，那么有新的服务上线或者下线，这么保证缓存及时同步呢

Ribbon 中使用了一个 PING 机制,从 eureka 中拿到服务列表，缓存到本地，ribbon 搞了个定时任务，隔一段时间就去循环 ping
一下每个服务节点是否存活

我们查看 IPing 这个接口

解决脏读机制的总结：

1. Ping
2. 更新机制

• 都是为了解决脏读的现象而生的
• 测试发现：更新机制和 ping 有个重回，而且在 ping 的时候不能运行更新机制，在更新的时候不能运行 ping 机制，导致我们很难测到 ping 失败的现象！
  Ping 机制做不了事情

4.6 Ribbon 负载均衡的实现和几种算法【重点】

在 ribbon 中有一个核心的负载均衡算法接口 IRule

1.RoundRobinRule–轮询 请求次数 % 机器数量

2.RandomRule–随机

3.权重

4. iphash

3.AvailabilityFilteringRule --会先过滤掉由于多次访问故障处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对于剩余的服务列表按照轮询的策略进行访问

4.WeightedResponseTimeRule–根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率越大。刚启动时如果同统计信息不足，则使用轮询的策略，等统计信息足够会切换到自身规则

5.RetryRule-- 先按照轮询的策略获取服务，如果获取服务失败则在指定的时间内会进行重试，获取可用的服务

6.BestAvailableRule --会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量小的服务

7.ZoneAvoidanceRule – 默认规则，复合判断 Server 所在区域的性能和 Server 的可用行选择服务器。

Ribbon 默认使用哪一个负载均衡算法：

ZoneAvoidanceRule ：区间内亲和轮询的算法！通过一个 key 来区分负载均衡算法：随机 轮训 权重 iphash （响应时间最短算法，区域内亲和（轮训）算法）

• 这意味着它会首选同一区域内的服务器，只有当同一区域内没有可用服务器时，才会考虑其他区域的服务器。
  

5.如何修改默认的负载均衡算法

5.1 修改 yml 配置文件（指定某一个服务使用什么算法）

provider: #提供者的服务名称,那么访问该服务的时候就会按照自定义的负载均衡算法

ribbon:

NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

#几种算法的全限定类名

5.3 配置此消费者调用任何服务都用某种算法

7.Ribbon 总结（后面的代码中 不会出现 ribbon）

Ribbon 是客户端实现负载均衡的远程调用组件，用法简单

Ribbon 源码核心：

ILoadBalancer 接口：起到承上启下的作用

1. 承上：从 eureka 拉取服务列表

2. 启下：使用 IRule 算法实现客户端调用的负载均衡设计思想：每一个服务提供者都有自己的 ILoadBalancer
   userService—》客户端有自己的 ILoadBalancerTeacherService—》客户端有自己的 ILoadBalancer

在客户端里面就是 Map<String,ILoadBalancer> iLoadBalancersMap<String,ILoadBalancer> iLoadBalancers 消费者端
服务提供者的名称 value （服务列表 算法规则 ）

如何实现负载均衡的呢？

iloadBalancer loadbalance = iloadBalancers.get(“user-service”)
List<Server> servers = Loadbalance.getReachableServers();//缓存起来

Server server = loadbalance .chooseServer(key) //key 是区 id，--》IRule 算法

chooseServer 下面有一个 IRule 算法

IRule 下面有很多实现的负载均衡算法你就可以使用 eureka+ribbon 做分布式项目