关于负载均衡
负载均衡⼀般分为服务器端负载均衡和客户端负载均衡。
所谓服务器端负载均衡,⽐如Nginx、F5这些,请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。
所谓客户端负载均衡,⽐如我们要说的Ribbon,服务消费者客户端会有⼀个服务器地址列表,调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问,负载均衡算法的执⾏是在请求客户端进⾏。
Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤,Ribbon利⽤从Eureka中读取到服务信息,在调⽤服务提供者提供的服务时,会根据⼀定的算法进⾏负载。

Ribbon⾼级应⽤
不需要引⼊额外的jar坐标,因为在服务消费者中我们引⼊过eureka-client,它会引⼊Ribbon相关jar。

代码中使⽤如下,在RestTemplate上添加对应注解即可。
@Bean
// Ribbon负载均衡
@LoadBalanced
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
Ribbon负载均衡策略
Ribbon内置了多种负载均衡策略,内部负责复杂均衡的顶级接⼝为 com.netflix.loadbalancer.IRule,类树如下

| 负载均衡策略 | 描述 |
|---|---|
| RoundRobinRule:轮询策略 | 默认超过10次获取到的server都不可⽤,会返回⼀个空的server |
| RandomRule:随机策略 | 如果随机到的server为null或者不可⽤的话,会while不停的循环选取 |
| RetryRule:重试策略 | ⼀定时限内循环重试。默认继承RoundRobinRule,也⽀持⾃定义注⼊,RetryRule会在每次选取之后,对选举的server进⾏判断,是否为null,是否alive,并且在500ms内会不停的选取判断。⽽RoundRobinRule失效的策略是超过10次,RandomRule是没有失效时间的概念,只要serverList没都挂。 |
| BestAvailableRule:最⼩连接数策略 | 遍历serverList,选取出可⽤的且连接数最⼩的⼀个server。该算法⾥⾯有⼀个LoadBalancerStats的成员变量,会存储所有server的运⾏状况和连接数。如果选取到的server为null,那么会调⽤RoundRobinRule重新选取。 |
| AvailabilityFilteringRule:可⽤过滤策略 | 扩展了轮询策略,会先通过默认的轮询选取⼀个server,再去判断该server是否超时可⽤,当前连接数是否超限,都成功再返回。 |
| ZoneAvoidanceRule:区域权衡策略(默认策略) | 扩展了轮询策略,继承了2个过滤器:ZoneAvoidancePredicate和AvailabilityPredicate,除了过滤超时和链接数过多的server,还会过滤掉不符合要求的zone区域⾥⾯的所有节点,AWS --ZONE 在⼀个区域/机房内的服务实例中轮询 |
注:Netflix公司当时服务部署在亚马逊云AWS上,AWS云服务器在世界各地有多个区域zone,所以Netflix把ZoneAvoidanceRule作为默认策略。
修改负载均衡策略:
#针对被调⽤⽅的微服务名称,不加就是全局⽣效
service-customer:
ribbon:
# 负载策略调整
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
详细的Ribbon配置放在Feign中写,因为Ribbon不是特别兼容RestTemplate。
Ribbon核⼼源码剖析
Ribbon⼯作原理

重点:Ribbon给restTemplate添加了⼀个拦截器
当我们访问http://cloud-eureka-server/shop/order/的时候,ribbon应该根据服务名service-consumer获取到该服务的实例列表并按照⼀定的负载均衡策略从实例列表中获取⼀个实例Server,并最终通过RestTemplate进⾏请求访问。
Ribbon细节结构图(涉及到底层的⼀些组件/类的描述)
- 获取服务实例列表
- 从列表中选择⼀个server

图中核⼼是负载均衡管理器LoadBalancer(总的协调者,相当于⼤脑,为了做事情,协调四肢),围绕它周围的多有IRule、IPing等。
- IRule:是在选择实例的时候的负载均衡策略对象
- IPing:是⽤来向服务发起⼼跳检测的,通过⼼跳检测来判断该服务是否可⽤
- ServerListFilter:根据⼀些规则过滤传⼊的服务实例列表
- ServerListUpdater:定义了⼀系列的对服务列表的更新操作
@LoadBalanced源码剖析
为什么在RestTemplate实例上添加了⼀个@LoadBalanced注解,就可以实现负载均衡?接下来分析这个注解背后的操作(负载均衡过程)
- 查看@LoadBalanced注解,这个注解是在哪⾥被识别到的?

- LoadBalancerClient类(实现类RibbonLoadBalancerClient,待⽤)
public interface LoadBalancerClient extends ServiceInstanceChooser {
// 根据服务执⾏请求内容
<T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;
// 根据服务执⾏请求内容
<T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;
// 拼接请求⽅式 传统中是ip:port 现在是服务名称:port 形式
URI reconstructURI(ServiceInstance instance, URI original);
}
- SpringCloud充分利⽤了SpringBoot的⾃动装配特点,找spring.factories配置⽂件


- 研究LoadBalancerAutoConfiguration

LoadBalancerAutoConfiguration⾥⾯的内容剖析:
第⼀处:注⼊resttemplate对象到集合待⽤

第⼆处:注⼊resttemplate定制器

第三处:使⽤定制器给集合中的每⼀个resttemplate对象添加⼀个拦截器

至此我们明⽩,添加了注解的RestTemplate对象会被添加⼀个拦截器LoadBalancerInterceptor,该拦截器就是后续拦截请求进⾏负载处理的。
所以,下⼀步重点该分析拦截器LoadBalancerInterceptor的intercept()⽅法

RibbonLoadBalancerClient对象是在哪⾥注⼊的?回到最初的⾃动配置类
RibbonAutoConfiguration中

负载均衡的事情执⾏原来交给了我们最初看到的RibbonLoadBalancerClient对象。
⾮常核⼼的⼀个⽅法:RibbonLoadBalancerClient.execute()

关注一:

回到主配置类RibbonAutoConfiguration


RibbonClientConfiguration中装配了⼤脑和肢⼲


关注二:

ZoneAwareLoadBalancer#chooseServer
因为我们始终在世界的一个区域(中国),所以zone的值为1

⽗类:com.netflix.loadbalancer.BaseLoadBalancer#chooseServer

来到区域隔离策略的⽗类choose⽅法中com.netflix.loadbalancer.PredicateBasedRule#choose



关注三:
通过打断点和浏览器访问探索



AbstractClientHttpRequest#execute
此处,就已经到了RestTemplate底层执⾏的代码了,由此也将验证最终请求的调⽤还是靠的RestTemplate

在进⾏负载chooseServer的时候,LoadBalancer负载均衡器中已经有了serverList,那么这个serverList是什么时候被注⼊到LoadBalancer中的?
来到RibbonClientConfiguration


把⽬光聚焦到使⽤这个空对象ServerList的地⽅




进⼊enableAndInitLearnNewServersFeature()⽅法



RoundRobinRule轮询策略源码剖析
//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//
package com.netflix.loadbalancer;
import com.netflix.client.config.IClientConfig;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class RoundRobinRule extends AbstractLoadBalancerRule {
private AtomicInteger nextServerCyclicCounter;
private static final boolean AVAILABLE_ONLY_SERVERS = true;
private static final boolean ALL_SERVERS = false;
private static Logger log = LoggerFactory.getLogger(RoundRobinRule.class);
public RoundRobinRule() {
this.nextServerCyclicCounter = new AtomicInteger(0);
}
public RoundRobinRule(ILoadBalancer lb) {
this();
this.setLoadBalancer(lb);
}
// 负载均衡策略类核⼼⽅法
public Server choose(ILoadBalancer lb, Object key) {
if (lb == null) {
log.warn("no load balancer");
return null;
} else {
Server server = null;
int count = 0;
while(true) {
if (server == null && count++ < 10) {
// 所有可⽤服务实例列表
List<Server> reachableServers = lb.getReachableServers();
// 所有服务实例列表
List<Server> allServers = lb.getAllServers();
int upCount = reachableServers.size();
int serverCount = allServers.size();
if (upCount != 0 && serverCount != 0) {
// 获得⼀个轮询索引
int nextServerIndex = this.incrementAndGetModulo(serverCount);
// 根据索引取出服务实例对象
server = (Server)allServers.get(nextServerIndex);
if (server == null) {
Thread.yield();
} else {
// 判断服务可⽤后返回
if (server.isAlive() && server.isReadyToServe()) {
return server;
}
server = null;
}
continue;
}
log.warn("No up servers available from load balancer: " + lb);
return null;
}
if (count >= 10) {
log.warn("No available alive servers after 10 tries from load balancer: " + lb);
}
return server;
}
}
private int incrementAndGetModulo(int modulo) {
int current;
int next;
do {
// 取出上次的计数
current = this.nextServerCyclicCounter.get();
// 因为是轮询,计数+1之后对总数取模
next = (current + 1) % modulo;
} while(!this.nextServerCyclicCounter.compareAndSet(current, next));
return next;
}
public Server choose(Object key) {
return this.choose(this.getLoadBalancer(), key);
}
public void initWithNiwsConfig(IClientConfig clientConfig) {
}
}
RandomRule随机策略源码剖析

