本文主要是介绍SpringCloud负载均衡源码解析 | 带你从表层一步步剖析Ribbon组件如何实现负载均衡功能，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
1、负载均衡原理
2、源码分析
2.1、@LoadBalanced
2.2、LoadBalancerClient
2.3、RibbonAutoConfiguration
2.4、LoadBalancerAutoConfiguration
2.5、LoadBalancerIntercepor⭐
2.6、再回LoadBalancerClient
2.7、RibbonLoadBalancerClient
2.7.1、DynamicServerListLoadBalancer
2.7.2、getServer
2.8、BaseLoadBalancer
2.9、RoundRobinRule
2.10、总结
3、负载均衡策略
3.1、负载均衡策略
3.2、自定义负载均衡策略
3.3、饥饿加载⭐
🍃作者介绍：双非本科大三网络工程专业在读，阿里云专家博主，专注于Java领域学习，擅长web应用开发、数据结构和算法，初步涉猎Python人工智能开发和前端开发。
🦅主页：@逐梦苍穹🥡所属专栏：微服务
📕您的一键三连，是我创作的最大动力🌹
1、负载均衡原理
在上一篇中，添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？
SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。
思考：发出的请求明明是http://userservice/user/2，怎么变成了http://localhost:8081/user/2的呢？
2、源码分析
为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然是因为有什么组件帮我们根据service名称，获取到了服务实例的ip和端口。
先说结论：它就是LoadBalancerInterceptor。
这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
下面进行源码分析。
2.1、@LoadBalanced
按住CTRL键，点进@LoadBalanced源码，选择加载完整，可以看到如下：
看起来非常的平平无奇，但是请留意上面的英文说明：
Annotation to mark a RestTemplate or WebClient bean to be configured to use a LoadBalancerClient.
简单来说，就是这个@LoadBalanced注解是用来标记的，标记要使用的是LoadBalancerClient。
所以真正起作用的其实是LoadBalancerClient这个Java类。
下面找到LoadBalancerClient这个类。
2.2、LoadBalancerClient
可以看到，这个类也是一个接口。
看一下类里面有什么方法：
只有这三个方法，三个都打断点尝试一下，看看拦截的是哪一个。
经过尝试，拦截的是：
<T> T execute(String serviceId, ServiceInstance serviceInstance,LoadBalancerRequest<T> request) throws IOException;并且，拦截到实现类是RibbonLoadBalancerClient：
但是这时候，我再往下调试断点，发现有点没有头绪了。
后面的内容并没有像前文这样显而易见的内容，都是一些判断之类的业务逻辑。
此时想起Ribbon组件，应该就是一整套东西。
那么查一下是否还有别的类？
让我们接着往下看
2.3、RibbonAutoConfiguration
查看ribbon包下其他的类，发现以ribbon开头的Java文件如下：
其中有一个很引人注目的类，即是配置类RibbonAutoConfiguration！
点进去看一下：
英文提示信息是：Auto configuration for Ribbon (client side load balancing).
顾名思义，这个类果然是自动配置ribbon相关内容的。
看一下这个类实现了什么方法：
此时看见了LoadBalancerClient()方法，那么这个LoadBalancerClient()和LoadBalancerClient.java会不会有什么关系呢？点过去看一下：
原来这个方法是返回了一个新的RibbonLoadBalancerClient对象，并且限制了注入LoadBalancerClient对象只允许注册一个实例。
其实，返回了一个新的RibbonLoadBalancerClient对象，本质上也是返回了一个LoadBalancerClient对象，因为RibbonLoadBalancerClient是实现LoadBalancerClient的：
2.4、LoadBalancerAutoConfiguration
进入LoadBalancerClient，查看哪些类实现了这个接口：
又出现一个自动配置类，点进去查看：
英文提示：Auto-configuration for blocking client-side load balancing.
顾名思义，自动配置阻塞客户端负载平衡。
看来，关键点找到了！
看一下这个类实现了什么方法：
可以看到这里有一个LoadBalancerInterceptorConfig拦截器配置。
那么猜想里面应该是配置了拦截器。
这符合之前分析的流程，Ribbon组件接收到请求，然后去找Eureka拉去实例列表，那这个过程的实现，不就是需要一个拦截器么？请接着往下看：
原来这是一个静态内部类。这个内部类的内容如下：
@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
static class LoadBalancerInterceptorConfig {@Beanpublic LoadBalancerInterceptor loadBalancerInterceptor(LoadBalancerClient loadBalancerClient,LoadBalancerRequestFactory requestFactory) {return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);}@Bean@ConditionalOnMissingBeanpublic RestTemplateCustomizer restTemplateCustomizer(final LoadBalancerInterceptor loadBalancerInterceptor) {return restTemplate -> {List<ClientHttpRequestInterceptor> list = new ArrayList<>(restTemplate.getInterceptors());list.add(loadBalancerInterceptor);restTemplate.setInterceptors(list);};}
}这部分内容，我们让通义灵码解释一下：
由此，重点就在LoadBalancerIntercepor了。
2.5、LoadBalancerIntercepor⭐
进入LoadBalancerIntercepor：
LoadBalancerIntercepor实现了ClientHttpRequestInterceptor(翻译过来是：客户端Http请求拦截器)。
到这里，基本上就没错了，接下来就是打断点接着拦截！
实现的方法如下：
对intercept方法打断点：
可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：
①request.getURI()：获取请求uri，本例中就是 http://userservice:8081/user/2
②originalUri.getHost()：获取uri路径的主机名，其实就是服务id，userservice
③this.loadBalancer.execute()：处理服务id，和用户请求。
这里的this.loadBalancer是LoadBalancerClient类型:
继续跟入末尾的execute方法。
2.6、再回LoadBalancerClient
可以注意到文章目录其实有两个LoadBalancerClient。
第一次是断点定位到execute方法之后没有头绪，
第二次则是带着答案的合理猜测来的。
继续跟入this.loadBalancer.execute方法：
此时来到了RibbonLoadBalancerClient.java。下面进入这个类。
2.7、RibbonLoadBalancerClient
继续进入RibbonLoadBalancerClient的execute方法：
（进入发现其实还是RibbonLoadBalancerClient类里面的方法，只不过是别的execute方法）：
2.7.1、DynamicServerListLoadBalancer
注意上图中的DynamicServerListLoadBalancer，在这里已经拉取到实例了。
上图是DynamicServerListLoadBalancer类的说明，意思翻译过来就是：
具有使用动态源获取候选服务器列表的能力的LoadBalancer。例如，服务器列表可能会在运行时更改。它还包含一些工具，其中服务器列表可以通过筛选条件传递，以过滤掉不符合所需条件的服务器。
2.7.2、getServer
注意到这里有一个getServer方法，点进去一探究竟：
再进chooseServer方法：
来到了ZoneAwareLoadBalancer.java的chooseServer方法
再进super.chooseServer(key)，来到了ZoneAwareLoadBalancer的父类BaseLoadBalancer。
2.8、BaseLoadBalancer
进入BaseLoadBalancer的chooseServer方法：
断点来到了rule.choose(key)。
rule则是规则的意思，查看一下rule是什么：
根据命名规范，I是指interface接口的意思，所以IRule是一个接口：
英文提示信息：
Interface that defines a "Rule" for a LoadBalancer.
A Rule can be thought of as a Strategy for loadbalacing.
Well known loadbalancing strategies include Round Robin, Response Time based etc.
信息主要内容：规则被认为是一种负载平衡策略。众所周知的负载平衡策略包括轮询、基于响应时间等。
所以到这一步，就已经很明显了。
SpringCloud底层利用Ribbon实现负载均衡，而Ribbon则通过IRule实现负载均衡。
也就是说，Ribbon实现负载均衡的组件，一定是IRule的实现类。
在IDEA中CTRL+H查看一下IRule的实现类：
RoundRobinRule.java就是实现了轮询规则。
2.9、RoundRobinRule
进入RoundRobinRule，查看实现方法：
打上断点，看看Ribbon组件有没有使用RoundRobinRule，有则说明Ribbon的原理就是轮询策略实现负载均衡。
我们的验证是没有错的，Ribbon组件实现负载均衡就是轮询规则。
2.10、总结
SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：
基本流程如下：
- 拦截RestTemplate请求http://userservice/user/2
- RibbonLoadBalancerClient会从请求url中获取服务名称，也就是userservice
- DynamicServerListLoadBalancer根据userservice到eureka拉取服务列表
- eureka返回列表，localhost:8081、localhost:8082
- IRule利用内置负载均衡的轮询规则，从列表中选择一个，例如localhost:8081
- RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/2，发起真实请求
3、负载均衡策略
3.1、负载均衡策略
负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：
不同规则的含义如下：
| 内置负载均衡规则类 | 规则描述 |
| RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| RetryRule | 重试机制的选择逻辑 |
默认的实现就是ZoneAvoidanceRule，是一种轮询方案
3.2、自定义负载均衡策略
通过定义IRule实现可以修改负载均衡规则，有两种方式：
①代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：
@Bean
public IRule randomRule(){return new RandomRule();
}②配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则注意，一般用默认的负载均衡规则，不做修改。
3.3、饥饿加载⭐
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:eager-load:enabled: trueclients: userservice这篇关于SpringCloud负载均衡源码解析 | 带你从表层一步步剖析Ribbon组件如何实现负载均衡功能的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
