loadbalancer源码分析
![](/images/12.png)
loadbalancer源码分析
Duckkkkkloadbalancer是如何实现挂载的
- 我们可以通过源码追踪看他底层是如何实现的在pom文件中发现我们导入的依赖是
<dependency> |
- 去依赖里看他导进来的依赖,可以看到这里只有一个pom文件 点开pom文件发现里面导入了一个 spring-cloud-loadbalancer 的依赖
- 再去他的里面找源码
- 我们可以发现在spring.factories中找到他的配置类
- 通过翻译不难发现LoadBalancerAutoConfiguration是 负载均衡自动配置 按住ctrl+鼠标左键可以追踪
// |
- @LoadBalancerClients //v表明所有的客户端都用这套方案
- EnableConfigurationProperties 客户端的配置属性
- AutoConfigureBefore 表明要实现自动配置需要这两个字节码文件
- starter自动配置最重要的是其中最核心的其实是@Bean
- @ConditionalOnMissingBean表示如果没有这个bean就新创建
- LoadBalancerZoneConfig 主要是做机架管理的不同的机房分成不同域,不用管
- LoadBalancerClientFactory的托管,是我们需要的,继续追踪
// |
public ReactiveLoadBalancer<ServiceInstance> getInstance(String serviceId) { |
- 工厂方法中最重要的是获取实例对象,找到LoadBalancerClientFactory对应的getInstance()方法 在方法内部可以发现,它获取了ReactorServiceInstanceLoadBalancer.class (基于响应式的服务实列的负载均衡器)实例对象,继续追踪
- serviceId其实是你注册的名称
// |
- 点进去对象发现是一个接口(官方注释写:容许你选择一个服务注册的实列)那么我们就要去找他的实现类,其实loadbalance默认是轮询方式进行负载均衡,这个后面会说 ,这里是通过注册一个项目的两个服务 测试结果发现他会轮流调用
- 两个默认类一个是轮询一个是随机所以我们点进RoundRobinLoadBalancer里
// |
- serviceInstanceListSupplierProvider-服务实例列表供应商提供商
//getIfAvailable()方法判断服务是否可用,如果可用获取服务实列NoopServiceInstanceListSupplier |
this.getInstanceResponse(serviceInstances); 获取相应实列
getInstanceResponse()方法是关键的使用那种负载均衡算法
//如果只有一个服务就返回这个 |
//假设我们现在有两个服务实列 请求第一次进来时 position为1,对整形最大值作模运算为本身,对服务实列个数取余为1 返回第二个服务,再发送请求,incrementAndGet方法会自增1,此时position为2,做相同操作 结果为0 返回第一个服务 |
- 这样就通过长轮询实现了负载均衡
两种负载均衡方案loadbalancer默认使用哪个
我们可以通过注解追踪
发现里面有一个
Class<?>[] configuration() default {}; |
下载注解后官方注释给出:
- A custom @Configuration for the load balancer client. Can contain override @Bean definition for the pieces that make up the client. |
点击for the defaults
|
默认返回了轮询负载均衡策略