02深度解析Spring Cloud Ribbon---LoadBalancerAutoConfiguration拦截器注入

一、LoadBalancerAutoConfiguration介绍

上一章我们已经分析了，RestTemplate 添加了相关的拦截器，使其具有了负载均衡的能力，而添加拦截的实现便是在 LoadBalancerAutoConfiguration里面实现的，相关的代码如下，并增加了相关的注释

@Configuration
@ConditionalOnClass(RestTemplate.class)  // 依赖 RestTemplate
@ConditionalOnBean(LoadBalancerClient.class)  // 需要提前注入 LoadBalancerClient 的Bean ,这里 需要 提前 注入配置类 RibbonAutoConfiguration
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {

    // 这里是 重点，重中之重，这里 是 注入 所有带有 @LoadBalanced 的 RestTemplate 
    // 这是由于 @LoadBalanced 里面加入了 @Qualifier ,这个是关键
	@LoadBalanced
	@Autowired(required = false)
	private List<RestTemplate> restTemplates = Collections.emptyList();

    // 这里是等待其他的Bean 都注入完成之后，再运行afterSingletonsInstantiated
    // 里面其实就是加入拦截器
	@Bean
	public SmartInitializingSingleton loadBalancedRestTemplateInitializer(
			final List<RestTemplateCustomizer> customizers) {
		return new SmartInitializingSingleton() {
			@Override
			public void afterSingletonsInstantiated() {
				for (RestTemplate restTemplate : LoadBalancerAutoConfiguration.this.restTemplates) {
					for (RestTemplateCustomizer customizer : customizers) {
						customizer.customize(restTemplate);
					}
				}
			}
		};
	}

    //LoadBalancerRequestTransformer接口
   // 没有任何实现类
	@Autowired(required = false)
	private List<LoadBalancerRequestTransformer> transformers = Collections.emptyList();


    //这个是一个 RequestFactory ，用于createRequest()新建一个LoadBalancerRequest 
	@Bean
	@ConditionalOnMissingBean
	public LoadBalancerRequestFactory loadBalancerRequestFactory(
			LoadBalancerClient loadBalancerClient) {
		return new LoadBalancerRequestFactory(loadBalancerClient, transformers);
	}

   //  这个是在没有重试机制下注入的，看一下 ConditionalOnMissingClass，重试的后面也会讲到
	@Configuration
	@ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
	static class LoadBalancerInterceptorConfig {
	  
	    // 这里就是 用 LoadBalancerRequestFactory  和  loadBalancerClient 构建一个         LoadBalancerInterceptor 
	    @Bean
		public LoadBalancerInterceptor ribbonInterceptor(
				LoadBalancerClient loadBalancerClient,
				LoadBalancerRequestFactory requestFactory) {
			return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
		}

       // 这里就是 添加拦截器，等会 上面会调用到这里，对 RestTemplate进行添加拦截器
		@Bean
		@ConditionalOnMissingBean
		public RestTemplateCustomizer restTemplateCustomizer(
				final LoadBalancerInterceptor loadBalancerInterceptor) {
			return new RestTemplateCustomizer() {
				@Override
				public void customize(RestTemplate restTemplate) {
					List<ClientHttpRequestInterceptor> list = new ArrayList<>(
							restTemplate.getInterceptors());
					list.add(loadBalancerInterceptor);
					restTemplate.setInterceptors(list);
				}
			};
		}
	}
	}

上面的代码都加了一些备注，总结一下

1、LoadBalancerAutoConfiguration 的注入满足条件

⑴存在RestTemplate.class
⑵需要提前注入 LoadBalancerClient 的Bean ,这里需要提前注入配置类 RibbonAutoConfiguration,如下图， RibbonAutoConfiguration 上面也提升了需要在 LoadBalancerAutoConfiguration.class 之前注入，完全吻合.
此外，LoadBalancerClient 的唯一实现类是 RibbonLoadBalancerClient

2、 LoadBalancerAutoConfiguration 内容

LoadBalancerAutoConfiguration 里面的注入：

生成了一个 LoadBalancerInterceptor 拦截器，参数为 LoadBalancerClient 和 LoadBalancerRequestFactory
注入了一个 RestTemplateCustomizer Bean , 这个的作用就是给带有 @LoadBalanced 的RestTemplate 添加拦截器 ,这个Bean 后续会被 afterSingletonsInstantiated 调用到
生成了一个transformers 的Bean ,这个没有实现类，可以自己实现
生成了一个 loadBalancerRequestFactory 的Bean ，这个主要是用于createRequest()新建一个LoadBalancerRequest
这里是重点 ，注入了一个带有 @LoadBalanced 的restTemplate ,为啥能收集到所有带有@LoadBalanced 注解的呢，这是由于里面有一个 @Qualifier ，这个可以自己去了解一下,这里确实不错，厉害
实例了一个 SmartInitializingSingleton ，主要是为了在其他的Bean 注入之后，进行对 RestTemplate 添加拦截器.

3、小结

LoadBalancerAutoConfiguration 这个自动配置类注入完成之后，就会将带有 @LoadBalanced 注解的 RestTemplate 具有负载均衡能力了.

二、LoadBalancerInterceptor的相关逻辑

1. intercept 拦截内容

上面已经分析了 RestTemplate 具有了负载均衡的能力了，接下来我们看一下具体的拦截器如何实现负载均衡的.，首先看一下代码如下：

从上面源码可以看出：

获取请求链接
获取ServiceName ，这就是为什么请求的链接里面输入 ip:port会报错
根据serviceName 到LoadBalancerClient 接口里面运行 execute

接下来我们分析一下这个 LoadBalancerClient ，这个是客户端的负载均衡，只有一个唯一的实现类（RibbonLoadBalancerClient），我们看一下 LoadBalancerClient 有哪些接口，如下：

public interface ServiceInstanceChooser {
    // 根据传入的serviceId，从负载均衡器中选一个对应服务的实例
    ServiceInstance choose(String serviceId);
}

public interface LoadBalancerClient extends ServiceInstanceChooser {
    
    // 根据传入的serviceId，负载均衡选择一个实例，然后执行请求
    <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;
    <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;
    
    // 重新构造url：把url中原来写的服务名(serverName) 换掉,变成 Ip：port
    URI reconstructURI(ServiceInstance instance, URI original);
}

2. RibbonLoadBalancerClient 具体内容

接下来就看一下具体的实现类里面的逻辑，代码如下：

从这里我们也可以看出一共有以下步骤：

选择负载均衡器 ILoadBalancer
通过负载均衡器选择一个应用实例server ，这里涉及到负载均衡器ILoadBalancer，这块的知识点详细在下面第三点分析，我们这里先把这个流程走通</>
将应用实例server 封装成对应的ribbonServer
进一步调用 execute ，这里其实就要回调接口函数request.apply(serviceInstance);
这里的 request.apply(serviceInstance); 就是上面传过来的 LoadBalancerRequest 接口，会进入到如下具体方法执行，如下图

*** 5.1 这里就是构建一个 request （通过 ServiceRequestWrapper ）这里一定要进入ServiceRequestWrapper 看一下，这个类重写了 getURI() 方法，这个方法就是将原来的 http://服务名 ===> http://ip:port ,这个方法后续要被调用的
**** 5.2 然后再运行 execution.execute(serviceRequest, body); 迭代调用本身（感觉也是另外一种递归），这里就解释了上一章里面的那个 if (this.iterator.hasNext()) 这里是一个循环，对于这种写法，我只能说一句 ‘我擦，流弊’
这样一个负载均衡的拦截器主要流程就结束了，下面我们继续里面的每一个步骤的细节.

3. ILoadBalancer 分析

上面说到第一步就是选择负载均衡器ILoadBalancer

ILoadBalancer loadBalancer = getLoadBalancer(serviceId);

先看一下这个接口提供了哪些方法，如下：

public interface ILoadBalancer {
	 // 添加服务器
	public void addServers(List<Server> newServers);

	 // 通过 key ,从负载均衡器里面 选择一个 服务器
	public Server chooseServer(Object key);

	 //标识通知此server 已经下线，不然负载均衡器会一直认为还活跃，直到再次PING
	public void markServerDown(Server server);

	 // 这个方法已经废弃
	@Deprecated
	public List<Server> getServerList(boolean availableOnly);

    //获取所有的活跃的服务器
    public List<Server> getReachableServers();

     //获取所有的 服务器，活跃和不活跃的
	public List<Server> getAllServers();
}

再看一下这个接口被哪些类实现了，如下：

可以看出基础实现类是 BaseLoadBalancer 类，DynamicServerListLoadBalancer 又在其基础上进行了扩展，ZoneAwareLoadBalancer 又继承了 DynamicServerListLoadBalancer 类，又做了一定的改进.

3.1 ILoadBalancer 的默认注入和依赖属性

在分析 ILoadBalancer 具体的属性和方法之前，我们先确认一下，默认的注入的是哪个实现类
提前说一下，是在 RibbonClientConfiguration.class这个类里面进行Bean 配置的,如下：

这个Bean 依赖的属性比较多，我们列一下并对其解释一下，这些属性都是在RibbonClientConfiguration 进行Bean 配置 ,这个是在没有和 Eureka 结合使用的情况下，如果使用了 Euraka ,那么可能有一些不同，具体配置如下：

名称	默认实现	结合Eureka 时配置	解释
IClientConfig	DefaultClientConfigImpl	DefaultClientConfigImpl	定义各种API用于初始化客户端或负载平衡器以及执行方法的客户端配置。
ServerList	ConfigurationBasedServerList（基于配置）	DomainExtractingServerList，里面是DiscoveryEnabledNIWSServerList	定义用于获取服务器列表的方法的接口
ServerListFilter	ZonePreferenceServerListFilter	ZonePreferenceServerListFilter	对ServerList 实例列表的过滤逻辑处理
IRule	ZoneAvoidanceRule	ZoneAvoidanceRule	负载均衡选择Server 的规则
IPing	DummyPing	NIWSDiscoveryPing	检验服务是否可用的方法实现
ServerListUpdater	PollingServerListUpdater	PollingServerListUpdater	对ServerList 更新的操作

3.1.1 定位RibbonClientConfiguration

我们是如何定位到 RibbonClientConfiguration.class ,并知道这些是在这个Bean 配置类里面实现的，流程如下：
在注入SpringClientFactory 的时候，指定了 defaultConfigType = RibbonClientConfiguration.class

所以在获取ILoadBanacer 时如下：

protected ILoadBalancer getLoadBalancer(String serviceId) {
		return this.clientFactory.getLoadBalancer(serviceId);
	}

public ILoadBalancer getLoadBalancer(String name) {
		return getInstance(name, ILoadBalancer.class);
	}

public <T> T getInstance(String name, Class<T> type) {
		AnnotationConfigApplicationContext context = getContext(name);
		if (BeanFactoryUtils.beanNamesForTypeIncludingAncestors(context,
				type).length > 0) {
			return context.getBean(type);
		}
		return null;
	}

一步步点击了代码看了一下，到最后如下：

这里便是注入 RibbonClientConfiguration这个Bean的配置类

3.2 AbstractLoadBalancer 类

下面继续说下实现类里面的方法：
**AbstractLoadBalancer 类：这个是ILoadBalancer 的抽象类，里面

public abstract class AbstractLoadBalancer implements ILoadBalancer {
    //增加了一个服务实例分组枚举
    public enum ServerGroup{
        ALL,                //所有服务
        STATUS_UP,                     //正常服务
        STATUS_NOT_UP           // 不正常服务
    }
    // 调用 chooseServer 方法，入参 null
    public Server chooseServer() {
    	return chooseServer(null);
    }
    
    //根据 服务器分组类型 获取 不同的服务器集合
    public abstract List<Server> getServerList(ServerGroup serverGroup);
    
    //获取与LoadBalancer相关的统计信息 
    //LoadBalancerStats 这个类比较重要，后面的服务器选择策略里面都有涉及到，后面详细讲
    public abstract LoadBalancerStats getLoadBalancerStats();    
}

3.3 BaseLoadBalancer 类

** BaseLoadBalancer 类：这个类是默认实现，首先我们看一下有哪些属性和方法：

3.3.1 BaseLoadBalancer 类的属性

public class BaseLoadBalancer extends AbstractLoadBalancer implements
        PrimeConnections.PrimeConnectionListener, IClientConfigAware {

　 // 默认的负载均衡 策略 是 轮休
    private final static IRule DEFAULT_RULE = new RoundRobinRule();
    
    // 具体的执行Ping 的策略对象,默认是 依次轮休，量大 效率比较低
    private final static SerialPingStrategy DEFAULT_PING_STRATEGY = new SerialPingStrategy();
    private static final String DEFAULT_NAME = "default";
    private static final String PREFIX = "LoadBalancer_";
    protected IRule rule = DEFAULT_RULE;
    protected IPingStrategy pingStrategy = DEFAULT_PING_STRATEGY;
    protected IPing ping = null;
    // 定义了一个 所有服务的 集合
    @Monitor(name = PREFIX + "AllServerList", type = DataSourceType.INFORMATIONAL)
    protected volatile List<Server> allServerList = Collections
            .synchronizedList(new ArrayList<Server>());
            
    // 定义了一个 更新服务的 集合
    @Monitor(name = PREFIX + "UpServerList", type = DataSourceType.INFORMATIONAL)
    protected volatile List<Server> upServerList = Collections
            .synchronizedList(new ArrayList<Server>());

    // 定义了 读写锁
    protected ReadWriteLock allServerLock = new ReentrantReadWriteLock();
    protected ReadWriteLock upServerLock = new ReentrantReadWriteLock();

    protected String name = DEFAULT_NAME;

    // 定义了一个 Timer ，每隔10S 定时运行一次
    protected Timer lbTimer = null;
    protected int pingIntervalSeconds = 10;
    protected int maxTotalPingTimeSeconds = 5;
    protected Comparator<Server> serverComparator = new ServerComparator();
    protected AtomicBoolean pingInProgress = new AtomicBoolean(false);

    // 定义了一个 LoadBalancerStats 统计相关信息
    protected LoadBalancerStats lbStats;

    private volatile Counter counter = Monitors.newCounter("LoadBalancer_ChooseServer");
    private PrimeConnections primeConnections;
    private volatile boolean enablePrimingConnections = false;
    private IClientConfig config;
    // 服务器列表变更监听 
    private List<ServerListChangeListener> changeListeners = new CopyOnWriteArrayList<ServerListChangeListener>();
    //服务器状态变更通知（具体的实现类 没有找到）
    private List<ServerStatusChangeListener> serverStatusListeners = new CopyOnWriteArrayList<ServerStatusChangeListener>();
}

1 负载均衡策略 IRule 默认初始化了RoundRobinRule();
2. 具体执行策略 SerialPingStrategy 是一个静态类，备注明确指出当量大时效果不理想,里面逻辑也是一个 for 循环
3. 定义了一个存储所有服务器实例的集合allServerList
4. 定义了一个存储正常服务器实例的集合upServerList
5. 定义了一个收集统计数据的LoadBalancerStats
6. 定义了要给 Timer 用于每隔10S去运行一次定时任务
7. 还定义了一些其他的辅助属性，如读写锁，服务器列表监听，服务器状态监听(serverStatusListeners ), 这个状态监听具体的实现类没有找到，但是不影响整个流程
此外BaseLoadBalancer 还涉及 PrimeConnections ，这个主要是由 enablePrimingConnections 控制，
PrimeConnections 主要就是对可用服务器列表异步连接测试一下，做一些统计，感觉没啥用,具体的逻辑
在 PrimeConnections.class 的 primeConnectionsAsync 方法：

BaseLoadBalancer 构造函数里面定义了一个定时任务，每隔10S都会去定时检测一些服务器状态，当规则为DummyPing，是不会运行的，具体介绍在下一个小小节

    public BaseLoadBalancer() {
        this.name = DEFAULT_NAME;
        this.ping = null;
        setRule(DEFAULT_RULE);
        setupPingTask();
        lbStats = new LoadBalancerStats(DEFAULT_NAME);
    }

3.3.2 PingTask() 介绍

这里就是主要就是更新 upServerList 正常活跃的服务类集合，代码如下：

void setupPingTask() {
      // 判断是否可以跳过
        if (canSkipPing()) {
            return;
        }
        // 先将上一次的取消
        if (lbTimer != null) {
            lbTimer.cancel();
        }
         // 重新 new ShutdownEnabledTimer
        lbTimer = new ShutdownEnabledTimer("NFLoadBalancer-PingTimer-" + name,
                true);
          // 运行，每隔10秒运行      
        lbTimer.schedule(new PingTask(), 0, pingIntervalSeconds * 1000);
        
        // 再次强制运行一次， 可能是作者考虑 上面是 异步，没有及时，不知道，反正 感觉这里有点多余
        forceQuickPing();
    }

  class PingTask extends TimerTask {
        public void run() {
            try {
              // 这里会 继续 根据 IPing逻辑去校验
            	new Pinger(pingStrategy).runPinger();
            } catch (Exception e) {
                logger.error("LoadBalancer [{}]: Error pinging", name, e);
            }
        }
    }

大致流程如下：
1 . 通过 canSkipPing() 判断是否可以跳过，ping == null || ping 是 DummyPing 类型，直接返回
2. 先将上一次的取消，然后再重新new ，这种做法比较好
3. 然后开始运行，每隔10 S去检测一些服务器的运行状态，是否UP
4. 这里就调用了 pingerStrategy ，这里是昨个服务器去 Check
5. Check 时，是调用 Ping 的具体实现isAlive() ,使用了 Eurka 的，就是走的NIWSDiscoveryPing 这个里面的方法
这里顺带说一下 IPING 的代码结构，只有一个方法 isAlive() ,逻辑都比较简单，就不多提了。

3.3.3 BaseLoadBalancer 方法介绍

addServers(List newServers) ---- 这个就是想原来的 allServerList 和新的 newServers都加到一个集合里面，再将老的 allServerList 指向新的 list .
getServerList(boolean availableOnly) -----根据 availableOnly 返回是全部的 serverList 还是可用的, 全部的就是allServerList，可用的就是upServerList
List getServerList(ServerGroup serverGroup) — 就是根据 serverGroup 来返回对应的数据
markServerDown(Server server)---- 将server 的活跃Flag(isAliveFlag) 改为false

3.4 DynamicServerListLoadBalancer介绍

3.4.1 DynamicServerListLoadBalancer 属性

public class DynamicServerListLoadBalancer<T extends Server> extends BaseLoadBalancer {

    // 服务器信息集合
    volatile ServerList<T> serverListImpl;

    // 对服务器过滤 集合
    volatile ServerListFilter<T> filter;

    // 服务器更新具体执行实现
    protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
        @Override
        public void doUpdate() {
            updateListOfServers();
        }
    };
    //对服务器更新
    protected volatile ServerListUpdater serverListUpdater;
}

上面是一些主要属性，我们就一个一个的看一下

3.4.1.1 ServerList 介绍

public interface ServerList<T extends Server> {
    // 获取初始服务器列表
    public List<T> getInitialListOfServers();
    // 获取更新的服务器列表
    public List<T> getUpdatedListOfServers();
}

一共就2个方法，我们在看一下具体的实现类

AbstractServerList 为其抽象类，里面又增加了一个方法
getFilterImpl(IClientConfig niwsClientConfig) — 这里就是获取一个 ServerListFilter 实例，默认是ZoneAffinityServerListFilter.class

DomainExtractingServerList 里面的属性

public class DomainExtractingServerList implements ServerList<DiscoveryEnabledServer> {

     // 这里 又定义了一个 ServerList 类型 
     // 如果 是没有Eureka ，这里的类型是:ConfigurationBasedServerList
     // 如果 配合 Eureka ,这里的是 : DiscoveryEnabledNIWSServerList
	private ServerList<DiscoveryEnabledServer> list;

    // 定义了一个 IClientConfig 
	private IClientConfig clientConfig;

	private boolean approximateZoneFromHostname;

	public DomainExtractingServerList(ServerList<DiscoveryEnabledServer> list,
			IClientConfig clientConfig, boolean approximateZoneFromHostname) {
		this.list = list;
		this.clientConfig = clientConfig;
		this.approximateZoneFromHostname = approximateZoneFromHostname;
	}
}

getInitialListOfServers() 和 getUpdatedListOfServers() 这两个方法都是返回里面的 list 对应的方法，这里的list 如果是没有Eureka ，这里的类型是:ConfigurationBasedServerList ,如果配合 Eureka ,这里的是 : DiscoveryEnabledNIWSServerList , ConfigurationBasedServerList ，返回的结果详见对应的实现类的分析

	private List<DiscoveryEnabledServer> setZones(List<DiscoveryEnabledServer> servers) {
		List<DiscoveryEnabledServer> result = new ArrayList<>();
		boolean isSecure = this.clientConfig.getPropertyAsBoolean(
				CommonClientConfigKey.IsSecure, Boolean.TRUE);
		boolean shouldUseIpAddr = this.clientConfig.getPropertyAsBoolean(
				CommonClientConfigKey.UseIPAddrForServer, Boolean.FALSE);
		for (DiscoveryEnabledServer server : servers) {
		 // 将获得的servers 进一步扩展封装成DomainExtractingServer 类型
			result.add(new DomainExtractingServer(server, isSecure, shouldUseIpAddr,
					this.approximateZoneFromHostname));
		}
		return result;
	}

这个方法就是将 servers 扩展为 DomainExtractingServer ，增加了一些额外的属性

ConfigurationBasedServerList 的 getInitialListOfServers() 和 getUpdatedListOfServers() 两个方法都是返回 listOfServers 里面的配置的服务器列表

DiscoveryEnabledNIWSServerList 的getInitialListOfServers() 和方法 getUpdatedListOfServers() 都是调用 obtainServersViaDiscovery() ,我们分析一下，主要就是：

获取Eureka 客户端，如果没有则报错
通过Eureka 客户端获取 listOfInstanceInfo 服务器实例
将服务器实例封装成DiscoveryEnabledServer 类型
设置区域，便于以后选择同一个Zone 进行调用（这里涉及 Region 和 Zone 相关的概念）
返回服务器列表

3.4.1.2 ServerListFilter 介绍

接口 ServerListFilter 只有一个方法，即

    public List<T> getFilteredListOfServers(List<T> servers);

看一下相关的实现结构：

①AbstractServerListFilter 是其抽象类，额外增加了一个负载均衡统计LoadBalancerStats

②ZoneAffinityServerListFilter 继承了AbstractServerListFilter ，这个过滤器就是主要根据是否需要 “区域亲和（Zone Affinity）” 来进行过滤，将服务器实例所属的Zone 与调用者自身的所处区域（Zone）进行比较，过滤掉那些不是同处一个区域的实例。

    @Override
    public List<T> getFilteredListOfServers(List<T> servers) {
       // 需要满足 servers 列表个数>1 ,并且 开启了zoneAffinity 或者zoneExclusive
        if (zone != null && (zoneAffinity || zoneExclusive) && servers !=null && servers.size() > 0){
            // 这里进行 第一步的 过滤
            List<T> filteredServers = Lists.newArrayList(Iterables.filter(
                    servers, this.zoneAffinityPredicate.getServerOnlyPredicate()));
             // 这里继续判断 是否正在需要开启 Zone 过滤
            if (shouldEnableZoneAffinity(filteredServers)) {
                return filteredServers;
            } else if (zoneAffinity) {
                overrideCounter.increment();
            }
        }
        return servers;
    }

上面方法主要通过Iterables.filter(servers, this.zoneAffinityPredicate.getServerOnlyPredicate()) ，进行过滤，这里就是将所有服务器的Zone 和调用者的对比，过滤掉不一致的.

过滤完了，还需要继续判断是否需要启用“区域亲和（Zone Affinity）” ，具体逻辑在 shouldEnableZoneAffinity(filteredServers)里面，这里有比较多的计算指标，不要急，慢慢渗入，如下：
Ⅰ 创建快照，里面的详细逻辑见下一个方法的解释
Ⅱ 获取对应的服务器负载情况和服务器的总数量、不能正常使用的服务器数量
Ⅲ 判断是否满足条件，这里有三个指标：
1. 不能用的服务器数量 / 总的数量 >0.8
2. 可用服务器上平均负载 >= 0.6
3. 可用服务器数（总的服务器 - 暂停的服务器数量)<2
满足上面任何一个，就不开启区域亲和（Zone Affinity）

    private boolean shouldEnableZoneAffinity(List<T> filtered) {    
        if (!zoneAffinity && !zoneExclusive) {
            return false;
        }
        if (zoneExclusive) {
            return true;
        }
        LoadBalancerStats stats = getLoadBalancerStats();
        if (stats == null) {
            return zoneAffinity;
        } else {
            logger.debug("Determining if zone affinity should be enabled with given server list: {}", filtered);
            // 创建快照，里面的详细逻辑 见下一个方法
            ZoneSnapshot snapshot = stats.getZoneSnapshot(filtered);
            // 获取对应的服务器负载情况
            double loadPerServer = snapshot.getLoadPerServer();
            // 获取服务器数量
            int instanceCount = snapshot.getInstanceCount();      
            // 不能用的服务器数量
            int circuitBreakerTrippedCount = snapshot.getCircuitTrippedCount();
            /**
              这里一共三个指标：
              1. 不能用的服务器数量 / 总的数量  >0.8
              2. 可用服务器上平均负载 >= 0.6 
              3. 可用服务器数（总的服务器 - 暂停 的服务器数量)<2
              满足上面 任何一个，就不开启 区域 亲和（Zone Affinity）
            **/
            if (((double) circuitBreakerTrippedCount) / instanceCount >= blackOutServerPercentageThreshold.get() 
                    || loadPerServer >= activeReqeustsPerServerThreshold.get()
                    || (instanceCount - circuitBreakerTrippedCount) < availableServersThreshold.get()) {
                logger.debug("zoneAffinity is overriden. blackOutServerPercentage: {}, activeReqeustsPerServer: {}, availableServers: {}", 
                        new Object[] {(double) circuitBreakerTrippedCount / instanceCount,  loadPerServer, instanceCount - circuitBreakerTrippedCount});
                return false;
            } else {
                return true;
            }
        }
    }

getZoneSnapshot 代码如下，

 public ZoneSnapshot getZoneSnapshot(List<? extends Server> servers) {
        if (servers == null || servers.size() == 0) {
            return new ZoneSnapshot();
        }
        int instanceCount = servers.size();
        int activeConnectionsCount = 0;
        int activeConnectionsCountOnAvailableServer = 0;
        int circuitBreakerTrippedCount = 0;
        double loadPerServer = 0;
        long currentTime = System.currentTimeMillis();
        for (Server server: servers) {
            ServerStats stat = getSingleServerStat(server);   
            // 判断当前时间是否能够访问当前的服务器,如果可以， 那就 同一个窗口时间内的 访问次数+1 ,不能 Trippedcount ++
            if (stat.isCircuitBreakerTripped(currentTime)) {
                circuitBreakerTrippedCount++;
            } else {
                activeConnectionsCountOnAvailableServer +=    stat.getActiveRequestsCount(currentTime);
            }
            activeConnectionsCount += stat.getActiveRequestsCount(currentTime);
        }
        // circuitBreakerTrippedCount == instanceCount ,就说明当前没有服务器可以使用
        if (circuitBreakerTrippedCount == instanceCount) {
            if (instanceCount > 0) {
                // should be NaN, but may not be displayable on Epic
                loadPerServer = -1;
            }
        } else {
        // 说明有可用的服务器，计算对应的负载
        //  可用服务器上访问的总次数 / (总的服务器数量 - 不能用的服务器数量)
            loadPerServer = ((double) activeConnectionsCountOnAvailableServer) / (instanceCount - circuitBreakerTrippedCount);
        }
        // 构造快照，把 总的服务器数量，不可用的服务器数量，所有的服务器 最近一个窗口之内访问的次数，负载   loadPerServer 传入
        return new ZoneSnapshot(instanceCount, circuitBreakerTrippedCount, activeConnectionsCount, loadPerServer);
    }

③DefaultNIWSServerListFilter 完全继承ZoneAffinityServerListFilter ，没有进行扩展

④ServerListSubsetFilter 将负载均衡器使用的服务器数量限制为所有服务器的子集。通过比较网络故障和并发连接，收回相对不正常服务器的能力。具体的逻辑如下：

获取过滤过一遍的服务器列表
获取到自己维护的currentSubset 服务器列表集
遍历一下 currentSubset ，剔除掉已经下线的，获取不在过滤服务器列表之内的
同时对剩下的进行过滤，判断的条件如下：
4.1. 服务器的最近的一个的窗口的访问次数> 设置的次数(默认是0)
4.2. 服务器访问失败的次数 > 设置的次数(默认是0)
获取需要保留的设置的子集(默认20个)，以及剔除百分比（默认0.1f）
判断一下，如果剩下的数量 > 设置的需要保留的或者剔除的百分比对应的数量还没有达到，那就要继续剔除
这是就对剩下的服务器按照健康排序，然后剔除掉相应的
如果剔除之后，保留的数量达不到默认保留的数量（默认20），这时候candidates.removeAll(newSubSet); 就是将新的服务器加进来，如果数量还不够，重新回滚到zoneAffinityFiltered ，再去取对应的数量的数据，代码就不贴了

⑤ ZonePreferenceServerListFilter 这里的getFilteredListOfServers() 逻辑也比较简单：

获取到过滤这之后的服务器列表集
2.一个一个的遍历，判断服务器的 Zone 和调用者的 Zone 是否一样，如果一样，就收集
返回，如果为空，就返回父类过滤的，代码如下：

	@Override
	public List<Server> getFilteredListOfServers(List<Server> servers) {
		List<Server> output = super.getFilteredListOfServers(servers);
		if (this.zone != null && output.size() == servers.size()) {
			List<Server> local = new ArrayList<Server>();
			for (Server server : output) {
				if (this.zone.equalsIgnoreCase(server.getZone())) {
					local.add(server);
				}
			}
			if (!local.isEmpty()) {
				return local;
			}
		}
		return output;
	}

3.4.1.3 ServerStats 介绍

ServerStats 的属性和方法的介绍如下,选了一部分：

public class ServerStats {
    //连接失败阈值，默认 3
    private final DynamicIntProperty connectionFailureThreshold;    
    //触发回环断路超时因子， 默认 10
    private final DynamicIntProperty circuitTrippedTimeoutFactor; 
    // 最大回环断路时间， 默认 30S
    private final DynamicIntProperty maxCircuitTrippedTimeout;
    //活动请求计数时间窗
    private static final DynamicIntProperty activeRequestsCountTimeout = DynamicPropertyFactory.getInstance().getIntProperty("niws.loadbalancer.serverStats.activeRequestsCount.effectiveWindowSeconds", 60 * 10);
   //最后连接失败时间
    private volatile long lastConnectionFailedTimestamp;
     //首次连接时间
    private volatile long firstConnectionTimestamp = 0;
      // 构造函数 给出默认
     public ServerStats() {
	        connectionFailureThreshold = DynamicPropertyFactory.getInstance().getIntProperty(
	                "niws.loadbalancer.default.connectionFailureCountThreshold", 3);        
	        circuitTrippedTimeoutFactor = DynamicPropertyFactory.getInstance().getIntProperty(
	                "niws.loadbalancer.default.circuitTripTimeoutFactorSeconds", 10);
	
	        maxCircuitTrippedTimeout = DynamicPropertyFactory.getInstance().getIntProperty(
	                "niws.loadbalancer.default.circuitTripMaxTimeoutSeconds", 30);
    }
   
   // 拿到 下一次 可以访问的时间，并与当前时间 对比，判断当前时间是否 可以继续访问
    public boolean isCircuitBreakerTripped(long currentTime) {
        long circuitBreakerTimeout = getCircuitBreakerTimeout();
        if (circuitBreakerTimeout <= 0) {
            return false;
        }
        return circuitBreakerTimeout > currentTime;
    }

    
    /** 
    先获取需要暂停的时间，在加上 上一次 连接失败开始的时间,就可以拿到 什么时候可以再次 访问的时间
    */
    private long getCircuitBreakerTimeout() {
        long blackOutPeriod = getCircuitBreakerBlackoutPeriod();
        if (blackOutPeriod <= 0) {
            return 0;
        }
        return lastConnectionFailedTimestamp + blackOutPeriod;
    }
    
    // 获取需要暂停的时间
    private long getCircuitBreakerBlackoutPeriod() {
        // 持续性的连接失败次数
        int failureCount = successiveConnectionFailureCount.get();
        // 默认连续失败的阈值 3
        int threshold = connectionFailureThreshold.get();
        // 如果没有达到阈值,直接返回0
        if (failureCount < threshold) {
            return 0;
        }
        //连续失败的次数和 阈值的差， 与16比较，最大 16
        int diff = (failureCount - threshold) > 16 ? 16 : (failureCount - threshold);
        // 获取需要停止时间 为 2的 diff 次方  ，再乘以 因子 10S
        int blackOutSeconds = (1 << diff) * circuitTrippedTimeoutFactor.get();
        暂停时间和 最大回环断路时间（30S）比较，最大取30S
        if (blackOutSeconds > maxCircuitTrippedTimeout.get()) {
            blackOutSeconds = maxCircuitTrippedTimeout.get();
        }
        return blackOutSeconds * 1000L;
    }
    
    // 这里就是把 当前时间设置为 最近一次连接失败的时间
    // 失败次数+1
    //由于失败，总共暂停多少时间
    public void incrementSuccessiveConnectionFailureCount() {
        lastConnectionFailedTimestamp = System.currentTimeMillis();
        successiveConnectionFailureCount.incrementAndGet();
        totalCircuitBreakerBlackOutPeriod.addAndGet(getCircuitBreakerBlackoutPeriod());
    } 
    
    // 这里是 获取活动窗口之内，成功访问的次数
    // 如果距离上一次访问时间 已经超过一个 窗口 的时间，那就 返回0 
    // 窗口的默认时间是 60*10 秒
    public int getActiveRequestsCount(long currentTime) {
        int count = activeRequestsCount.get();
        if (count == 0) {
            return 0;
        } else if (currentTime - lastActiveRequestsCountChangeTimestamp > activeRequestsCountTimeout.get() * 1000 || count < 0) {
            activeRequestsCount.set(0);
            return 0;            
        } else {
            return count;
        }
    }
}

3.4.1.4 ServerListUpdater 介绍

ServerListUpdater 就是用于以不同方式进行动态服务器列表更新的策略，先看一下有哪些接口：

public interface ServerListUpdater {

    // 接口里面内嵌了一个接口，执行里面的dopudate,来实现服务器列表更新
    public interface UpdateAction {
        void doUpdate();
    }

    // 开始服务器列表的更新，具体的 实现在 UpdateAction接口里面
    void start(UpdateAction updateAction);

     //停止服务器列表的更新
    void stop();

     // 返回上一次 更新时 的时间，以String 形式
    String getLastUpdate();

     //返回 从上一次开始更新经历时的 时间(毫秒)
    long getDurationSinceLastUpdateMs();

     //返回错过的更新周期数
    int getNumberMissedCycles();

     // 返回核心线程数
    int getCoreThreads();
}

在看一下 ServerListUpdater 的实现结构，就两个实现类，PollingServerListUpdater 和 EurekaNotificationServerListUpdater

①EurekaNotificationServerListUpdater类

EurekaNotificationServerListUpdater 是 DynamicServerListLoadBalancer的一种服务器列表更新的实现，它利用eureka的事件侦听器触发LB缓存更新。此外，当收到缓存刷新的通知时，serverList上的实际更新是在单独的线程池更新的。

start(final UpdateAction updateAction) 方法的主要逻辑为：

新建一个 EurekaEventListener() ，
重写里面的onEvent(EurekaEvent event) 事件，具体内容是启动一个线程去更新具体的内容
updateAction.doUpdate(); 而真正的内容是在调用方，即DynamicServerListLoadBalancer 类里面的 updateAction方法
设置最近一次更新时间

stop() 就是注销事件监听

@Override
    public synchronized void start(final UpdateAction updateAction) {
        if (isActive.compareAndSet(false, true)) {
            this.updateListener = new EurekaEventListener() {
                @Override
                public void onEvent(EurekaEvent event) {
                    if (event instanceof CacheRefreshedEvent) {
                        if (!updateQueued.compareAndSet(false, true)) {  // if an update is already queued
                            logger.info("an update action is already queued, returning as no-op");
                            return;
                        }

                        try {
                            refreshExecutor.submit(new Runnable() {
                                @Override
                                public void run() {
                                    try {
                                    // 具体实现在DynamicServerListLoadBalancer 类里面的 updateAction方法
                                        updateAction.doUpdate();
                                        // 记录时间
                                        lastUpdated.set(System.currentTimeMillis());
                                    } catch (Exception e) {
                                        logger.warn("Failed to update serverList", e);
                                    } finally {
                                        updateQueued.set(false);
                                    }
                                }
                            });  // fire and forget
                        } catch (Exception e) {
                            logger.warn("Error submitting update task to executor, skipping one round of updates", e);
                            updateQueued.set(false);  // if submit fails, need to reset updateQueued to false
                        }
                    }
                }
            };
            if (eurekaClient == null) {
                eurekaClient = eurekaClientProvider.get();
            }
            if (eurekaClient != null) {
                eurekaClient.registerEventListener(updateListener);
            } else {
                logger.error("Failed to register an updateListener to eureka client, eureka client is null");
                throw new IllegalStateException("Failed to start the updater, unable to register the update listener due to eureka client being null.");
            }
        } else {
            logger.info("Update listener already registered, no-op");
        }
    }

②PollingServerListUpdater 类
PollingServerListUpdater 是服务器列表动态更新的默认实现策略，就是调用了一个定时任务去定时执行，初始化之后 1秒开始运行，间隔周期是 30S ,同样具体的实现也是在 DynamicServerListLoadBalancer 类里面的 updateAction方法

  private static long LISTOFSERVERS_CACHE_UPDATE_DELAY = 1000; // msecs;
  private static int LISTOFSERVERS_CACHE_REPEAT_INTERVAL = 30 * 1000; // msecs;
  
@Override
    public synchronized void start(final UpdateAction updateAction) {
        if (isActive.compareAndSet(false, true)) {
            final Runnable wrapperRunnable = new Runnable() {
                @Override
                public void run() {
                    if (!isActive.get()) {
                        if (scheduledFuture != null) {
                            scheduledFuture.cancel(true);
                        }
                        return;
                    }
                    try {
                        updateAction.doUpdate();
                        lastUpdated = System.currentTimeMillis();
                    } catch (Exception e) {
                        logger.warn("Failed one update cycle", e);
                    }
                }
            };

            scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
                    wrapperRunnable,
                    initialDelayMs,
                    refreshIntervalMs,
                    TimeUnit.MILLISECONDS
            );
        } else {
            logger.info("Already active, no-op");
        }
    }

3.4.1.5 IRule介绍

IRule 就是负载均衡的选择策略，先看一下IRule 的接口，就3个,主要是针对 choose(Object key) 的分析

public interface IRule{
    public Server choose(Object key);
    
    public void setLoadBalancer(ILoadBalancer lb);
    
    public ILoadBalancer getLoadBalancer();    
}

再看一下 IRule 的继承结构，然后我们就分析一下每个规则的特色：

◆ AbstractLoadBalancerRule 是IRule 的抽象类，增加了一个 ILoadBalancer lb 属性
◆ RandomRule 随机策略就是通过Random.nextInt(serverCount) 随机取一个 index ,在可用服务里面获取对应的Server .
自己认为这个随机策略存在好几个问题
1. 可用服务器的 Size 肯定是小于等于所有服务器的个数，那么 server = upList.get(index); 这里不是会出现数组越界嘛
2. 如果出现一直取不到server 的情况，就会进去死循环了

 public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            return null;
        }
        Server server = null;

        while (server == null) {
            if (Thread.interrupted()) {
                return null;
            }
            List<Server> upList = lb.getReachableServers();
            List<Server> allList = lb.getAllServers();

            int serverCount = allList.size();
            if (serverCount == 0) {
                return null;
            }
            int index = rand.nextInt(serverCount);
            server = upList.get(index);
            if (server == null) {
                /*
                 * The only time this should happen is if the server list were
                 * somehow trimmed. This is a transient condition. Retry after
                 * yielding.
                 */
                Thread.yield();
                continue;
            }
            if (server.isAlive()) {
                return (server);
            }
            // Shouldn't actually happen.. but must be transient or a bug.
            server = null;
            Thread.yield();
        }
        return server;
    }

◆ RoundRobinRule 轮询策略，逻辑就是维护了一个计数器nextServerCyclicCounter ，每次+1 ,依次访问下一个 , 如果连续10次获取的都是无效的server，就直接终止，不再获取server.

◆ RetryRule 重试策略，设置了一个时间段，和一个 RoundRobinRule() 策略，即默认是maxRetryMillis = 500;就是在 500 ms 之内，如果没有获取到就不断的依次获取server，如果时间到了，就由Timer 触发将当前线程 interrupt();然后返回 null

◆ WeightedResponseTimeRule 以响应时间作为权重，响应时间越短的服务器被选中的概率越大的策略.

◆ ClientConfigEnabledRoundRobinRule 这个类没啥特别，就是内置了一个 RoundRobinRule 策略，调用 RoundRobinRule 的策略，我的疑问就是为啥子类不继承 RoundRobinRule ，都继承这个干啥呢，不是多走了一步弯路

◆ BestAvailableRule策略，这个就是对所有的可用服务器进行过滤，里面涉及的方法在 serverStats 都介绍过，即首先判断每一台服务器是否还处于暂停访问期间，如果是直接放弃，
接着判断获取一个滑动窗口内的有效请求总数，取所有服务器种最小的一个，说明负载最小

◆ PredicateBasedRule策略，抽象类，调用chooseRoundRobinAfterFiltering ，从名字可以猜测出就是通过对 server 过滤，然后通过RoundRobin轮询策略获取server ，最重要的就是 getEligibleServers 方法里面的 this.apply(new PredicateKey(loadBalancerKey, server)) ，这里需要重新实现Predicate 里面的apply方法，也就是要把 PredicateBasedRule 类里面的 public abstract AbstractServerPredicate getPredicate() 重新实现一下，返回一个具体的 Predicate 接口对应的实现类.


    @Override
    public Server choose(Object key) {
        ILoadBalancer lb = getLoadBalancer();
        Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
        if (server.isPresent()) {
            return server.get();
        } else {
            return null;
        }       
    }

    public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
        List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
        if (eligible.size() == 0) {
            return Optional.absent();
        }
        return Optional.of(eligible.get(nextIndex.getAndIncrement() % eligible.size()));
    }
    
    public List<Server> getEligibleServers(List<Server> servers, Object loadBalancerKey) {
        if (loadBalancerKey == null) {
            return ImmutableList.copyOf(Iterables.filter(servers, this.getServerOnlyPredicate()));            
        } else {
            List<Server> results = Lists.newArrayList();
            for (Server server: servers) {
                if (this.apply(new PredicateKey(loadBalancerKey, server))) {
                    results.add(server);
                }
            }
            return results;            
        }
    }

◆ ZoneAvoidanceRule 继承了 PredicateBasedRule 类，这里 Predicate的是一个组合型的过滤，是由 ZoneAvoidancePredicate 和 AvailabilityPredicate 一起组合的过滤 ,是一个 and 的逻辑，然后如果没有达到要求，还有从过滤逻辑，直到满足条件。

    public ZoneAvoidanceRule() {
        super();
        ZoneAvoidancePredicate zonePredicate = new ZoneAvoidancePredicate(this);
        AvailabilityPredicate availabilityPredicate = new AvailabilityPredicate(this);
        compositePredicate = createCompositePredicate(zonePredicate, availabilityPredicate);
    }

具体看一下 AndPredicate 类的 apply 实现， AndPredicate.class 也是实现了Predicate ，重写了apply 方法，只要有一个不通过，那就不通过

☆☆☆ 分析一下 CompositePredicate的方法 getEligibleServers里面的逻辑，代码如下：

    public List<Server> getEligibleServers(List<Server> servers, Object loadBalancerKey) {
        List<Server> result = super.getEligibleServers(servers, loadBalancerKey);
        Iterator<AbstractServerPredicate> i = fallbacks.iterator();
        while (!(result.size() >= minimalFilteredServers && result.size() > (int) (servers.size() * minimalFilteredPercentage))
                && i.hasNext()) {
            AbstractServerPredicate predicate = i.next();
            result = predicate.getEligibleServers(servers, loadBalancerKey);
        }
        return result;
    }

逻辑为：
1 .使用主过滤对所有实例过滤并返回过滤后的服务器实例清单
2. 需要判断下面两个条件，只要有一个符合就不再进行从过滤，将当前结果返回供线性轮询算法选择：

	1. 过滤后的服务器实例总数 >= 最小过滤服务器实例数（minimalFilteredServers，默认为1）
	2. 过滤后的服务器实例比例 > 最小过滤百分比（minimalFilteredPercentage，默认为0）

3.4.1.5.1 ZoneAvoidanceRule 相关的方法介绍

㈠方法：Map<String, ZoneSnapshot> createSnapshot(LoadBalancerStats lbStats)
先获取所有的可用区域，然后在对每一个区域创建快照，存入Map<String, ZoneSnapshot>

㈡方法：String randomChooseZone(Map<String, ZoneSnapshot> snapshot,
Set chooseFrom)
就是从 chooseFrom 随机取一个，但是实现逻辑个人感觉复杂了，还加了服务器个数的判断，为啥不直接 set 转list ,然后random.nextInt 不就可以了.

㈢方法： Set getAvailableZones(
Map<String, ZoneSnapshot> snapshot, double triggeringLoad,
double triggeringBlackoutPercentage)
这段代码的逻辑主要流程如下：
Ⅰ 获取所有的的区域集合，如果Size =1 ,直接返回
Ⅱ 开始对每一个区域下的情况开始计算，满足如下条件的就剔除：

    ❶ 该区域下面的 服务器实例数为 0 
    ❷ 不可用服务器实例数 /  总数   > 触发的百分比 （默认值 为0.99999d）
    ❸ 负载小于 0 ，就是 服务器列表全坏的情况

Ⅲ 同时还收集较高负载的集合Set worstZones, 负载越高越差, 并获到负载最高的区域
Ⅳ 如果所有区域中的最高负载都没有超过触发点（默认是 0.2d），并且所有的区域都正常(没有剔除过)，那就直接返回所有区域
Ⅴ 否则，那就从负载较高的区域 worstZones 中随机去掉一个，然后返回

㈣方法：getAvailableZones(LoadBalancerStats lbStats,
double triggeringLoad, double triggeringBlackoutPercentage) 这个方法就是上面两个方法的结合，先创建区域快照，然后选择可用区域

3.4.1.5.2 AvailabilityFilteringRule

◆ AvailabilityFilteringRule 继承了 PredicateBasedRule 类，从写了choose 方法，
首先通过 roundRobinRule 轮询一个server ，在通过 predicate （这里的具体实现类是AvailabilityPredicate ）判断是否符合条件，符合条件就返回此server ,不符合继续轮询获取server 然后再判断，如果连续10次都不符合，那就调用父类的choose 方法.

AvailabilityPredicate 的apply 的判断是否符合的逻辑还是 stat 里面那一块，

此server 是否在禁止访问期间
实例请求数量是否大于阈值（默认 Integer.MAX_VALUE）

    public Server choose(Object key) {
        int count = 0;
        Server server = roundRobinRule.choose(key);
        while (count++ <= 10) {
            if (predicate.apply(new PredicateKey(server))) {
                return server;
            }
            server = roundRobinRule.choose(key);
        }
        return super.choose(key);
    }

   //AvailabilityPredicate 类 的apply 方法
       @Override
    public boolean apply(@Nullable PredicateKey input) {
        LoadBalancerStats stats = getLBStats();
        if (stats == null) {
            return true;
        }
        return !shouldSkipServer(stats.getSingleServerStat(input.getServer()));
    }
    
    private boolean shouldSkipServer(ServerStats stats) {        
        if ((CIRCUIT_BREAKER_FILTERING.get() && stats.isCircuitBreakerTripped()) 
                || stats.getActiveRequestsCount() >= activeConnectionsLimit.get()) {
            return true;
        }
        return false;
    }

3.4.2 DynamicServerListLoadBalancer 方法介绍

DynamicServerListLoadBalancer 继承了 BaseLoadBalancer，动态获取候选服务器列表的功能。
这里介绍三个方法，并分析一下主要干了啥，就不贴代码和备注了

方法 restOfInit(IClientConfig clientConfig) 主要做了以下事情：

先保存 enablePrimingConnections 原先的值，然后将 enablePrimingConnections 暂时设置为false，这是为了防止启动两个异步线程去运行相关的提前httpClient 的请求,因为在 BaseLoadBalancer的初始化的过程中也会有 enablePrimingConnections 相关的判断
通过 enableAndInitLearnNewServersFeature(); 开启一个定时任务去定时更新 serverList 信息(上面已经分析过了，初始化1S 之后)，这里的服务列表信息更新实例就是默认的 PollingServerListUpdater实例，updateAction 方法就是 DynamicServerListLoadBalancer类里面的 updateListOfServers();
立刻运行updateListOfServers(); // 这里这么做应该是考虑到上面有1秒的延时问题
再将 enablePrimingConnections 这里改为原来的值

方法 ** setServersList(List lsrv) 主要逻辑如下：

调用父类的 super.setServersList(lsrv); 进行相关逻辑的处理
在缓存 serverStatsCache 里面创建一下（如果没有）
建立一个 Map<String, List> 的映射关系 key(Zone) --> Value( 对应的服务器列表)
调用 setServerListForZones 方法进行更新upServerListZoneMap ，并且确保每一个Zone 信息都在zoneStatsMap 里面

方法 ** updateListOfServers() 这个就是 UpdateAction 更新serverList 的具体操作，上面提到过好几次，这里梳理一下逻辑：

    protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
        @Override
        public void doUpdate() {
            updateListOfServers();
        }
    };
@VisibleForTesting
    public void updateListOfServers() {
        List<T> servers = new ArrayList<T>();
        if (serverListImpl != null) {
            servers = serverListImpl.getUpdatedListOfServers();
            LOGGER.debug("List of Servers for {} obtained from Discovery client: {}",
                    getIdentifier(), servers);

            if (filter != null) {
                servers = filter.getFilteredListOfServers(servers);
                LOGGER.debug("Filtered List of Servers for {} obtained from Discovery client: {}",
                        getIdentifier(), servers);
            }
        }
        updateAllServerList(servers);
    }

获取到可用服务器，这里serverListImpl 的注入分情况而定，如果是纯Ribbon ,注入的是ConfigurationBasedServerList ，如果结合了 Eureka ,那就是 DomainExtractingServerList，里面是DiscoveryEnabledNIWSServerList ，里面定义了一个 list . 具体获取的逻辑上面都介绍过了
在通过 ServerListFilter过滤一下服务器列表，这里的 ServerListFilter 过滤器的默认实现是 ZonePreferenceServerListFilter，getFilteredListOfServers的具体实现上面也介绍过了，这里略
更新一下所有的服务器信息，其中会 Ping 一下(如果满足Ping 条件)，调用 super.forceQuickPing();

3.4.3 DynamicServerListLoadBalancer 小结

DynamicServerListLoadBalancer 类对 Zone相关的其实没有处理，DynamicServerListLoadBalancer 类里面的 setServerListForZones 主要就是更新了一下 key(zone)->value(serverlist )的Map，以及保存了区域Zone的信息
DynamicServerListLoadBalancer 类没有重写chooseServer 方法，调用的还是BaseLoadBalancer的chooseServer 方法，也就是走的new RoundRobinRule() 轮询的策略.

3.5 ZoneAwareLoadBalancer介绍

ZoneAwareLoadBalancer 负载均衡器又继承了 DynamicServerListLoadBalancer ，对DynamicServerListLoadBalancer 进行了扩展，主要重写了setServerListForZones(Map<String, List> zoneServersMap)、chooseServer(Object key) 这两个方法。

ZoneAwareLoadBalancer 从名字上就能看出来，ZoneAwareLoadBalancer 负载均衡器考虑到了区域Zone的因素，DynamicServerListLoadBalancer 类对区域没有处理，都是通过RoundRobinRule() 轮休策略去访问，而针对跨区域的情况，访问不同区域的延时比较大的时候，可以选择相同的区域访问，带来性能上的提高. 我们看一下ZoneAwareLoadBalancer 做了哪些改进，先看setServerListForZones方法，大致的逻辑如下：


    @Override
    protected void setServerListForZones(Map<String, List<Server>> zoneServersMap) {
        super.setServerListForZones(zoneServersMap);
        if (balancers == null) {
            balancers = new ConcurrentHashMap<String, BaseLoadBalancer>();
        }
        for (Map.Entry<String, List<Server>> entry: zoneServersMap.entrySet()) {
        	String zone = entry.getKey().toLowerCase();
            getLoadBalancer(zone).setServersList(entry.getValue());
        }
        // check if there is any zone that no longer has a server
        // and set the list to empty so that the zone related metrics does not
        // contain stale data
        for (Map.Entry<String, BaseLoadBalancer> existingLBEntry: balancers.entrySet()) {
            if (!zoneServersMap.keySet().contains(existingLBEntry.getKey())) {
                existingLBEntry.getValue().setServersList(Collections.emptyList());
            }
        }
    }

还是调到父类的setServerListForZones(zoneServersMap); 将key(zone)—>value(serverlist)和 zone 信息更新
将所有的区域相关的信息更新到缓存 balancers里面（key 为区域Zone，value 为 BaseLoadBalancer），以区域划分，一个区域对应一个 BaseLoadBalancer，再将区域下面的ServerList 填充进去.
再次校验一下，将那些被过滤掉的Zone ,下面对应的 serverList 置为空.
//分析来，DynamicServerListLoadBalancer 其实已经将 zone—>serverList 做了划分，但是没有后续的操作了,这也是ZoneAwareLoadBalancer 先调用 super.setServerListForZones(zoneServersMap); 在此基础上进一步扩展

我们再分析一下 ZoneAwareLoadBalancer 的chooseServer 方法：

    @Override
    public Server chooseServer(Object key) {
        // 判断 是否开启 以及 可用的区域是否 超过1个
        if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
            logger.debug("Zone aware logic disabled or there is only one zone");
            return super.chooseServer(key);
        }
        Server server = null;
        try {
            LoadBalancerStats lbStats = getLoadBalancerStats();
            // 获取区域快照，保存在 Map里面
            Map<String, ZoneSnapshot> zoneSnapshot = ZoneAvoidanceRule.createSnapshot(lbStats);
            logger.debug("Zone snapshots: {}", zoneSnapshot);
             // 获取 默认 触发实例负载 的参数，默认为0.2d
            if (triggeringLoad == null) {
                triggeringLoad = DynamicPropertyFactory.getInstance().getDoubleProperty(
                        "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".triggeringLoadPerServerThreshold", 0.2d);
            }
           // 获取 触发 服务器实例故障率的百分比，默认为0.99999d
            if (triggeringBlackoutPercentage == null) {
                triggeringBlackoutPercentage = DynamicPropertyFactory.getInstance().getDoubleProperty(
                        "ZoneAwareNIWSDiscoveryLoadBalancer." + this.getName() + ".avoidZoneWithBlackoutPercetage", 0.99999d);
            }
            // 获取到 可用区域
            Set<String> availableZones = ZoneAvoidanceRule.getAvailableZones(zoneSnapshot, triggeringLoad.get(), triggeringBlackoutPercentage.get());
            logger.debug("Available zones: {}", availableZones);
            if (availableZones != null &&  availableZones.size() < zoneSnapshot.keySet().size()) {
                // 随机选择一个 区域
                String zone = ZoneAvoidanceRule.randomChooseZone(zoneSnapshot, availableZones);
                logger.debug("Zone chosen: {}", zone);
                if (zone != null) {
                    // 获取BaseLoadBalancer 
                    BaseLoadBalancer zoneLoadBalancer = getLoadBalancer(zone);
                    // 获取服务器列表
                    server = zoneLoadBalancer.chooseServer(key);
                }
            }
        } catch (Exception e) {
            logger.error("Error choosing server using zone aware logic for load balancer={}", name, e);
        }
        if (server != null) {
            return server;
        } else {
            logger.debug("Zone avoidance logic is not invoked.");
            return super.chooseServer(key);
        }
    }

上面代码的整个逻辑如下：

判断是否开启区域过滤，并且可用区域的个数 > 1 ,否则调用父类的 chooseServer
调用 ZoneAvoidanceRule.createSnapshot ，创建区域快照，保存到 Map<String, ZoneSnapshot> zoneSnapshot里面
再次调用 ZoneAvoidanceRule.getAvailableZones 进行区域过滤，这里面的逻辑详细见上面ZoneAvoidanceRule.getAvailableZones 里面的解释
如果可用区域 availableZones 不为空，并且小于所有快照区域的大小，那就从可用区域中随机选一个区域 zone
根据选择出来的 zone 获取对应的BaseLoadBalancer ，然后在根据对应的IRule 获取server 服务器实例
如果服务器实例为Null(没有获取到服务器实例) ，那就调用父类的 super.chooseServer(key);

三、运行的流程图

四、小结

本来介绍了 Ribbon 相关的源码和相关的调用过程，里面的内容比较多,如有哪里不对，麻烦指出，谢谢.

02深度解析Spring Cloud Ribbon---LoadBalancerAutoConfiguration拦截器注入

02深度解析Spring Cloud Ribbon---LoadBalancerAutoConfiguration拦截器注入

一、LoadBalancerAutoConfiguration介绍

1、LoadBalancerAutoConfiguration 的注入满足条件

2、 LoadBalancerAutoConfiguration 内容

3、小结

二、LoadBalancerInterceptor的相关逻辑

1. intercept 拦截内容

2. RibbonLoadBalancerClient 具体内容

3. ILoadBalancer 分析

3.1 ILoadBalancer 的默认注入和依赖属性

3.1.1 定位RibbonClientConfiguration

3.2 AbstractLoadBalancer 类

3.3 BaseLoadBalancer 类

3.3.1 BaseLoadBalancer 类的属性

3.3.2 PingTask() 介绍

3.3.3 BaseLoadBalancer 方法介绍

3.4 DynamicServerListLoadBalancer介绍

3.4.1 DynamicServerListLoadBalancer 属性

3.4.1.1 ServerList 介绍

3.4.1.2 ServerListFilter 介绍

3.4.1.3 ServerStats 介绍

3.4.1.4 ServerListUpdater 介绍

3.4.1.5 IRule介绍

3.4.1.5.1 ZoneAvoidanceRule 相关的方法介绍

3.4.1.5.2 AvailabilityFilteringRule

3.4.2 DynamicServerListLoadBalancer 方法介绍

3.4.3 DynamicServerListLoadBalancer 小结

3.5 ZoneAwareLoadBalancer介绍

三、运行的流程图

四、小结

mysql-connector-java 屬性介紹

spring源碼解析之-----SimpleAliasRegistry解析

Sqoop相關概念

sqoop整體介紹

BeanPostProcessor 源碼解析

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

02深度解析Spring Cloud Ribbon---LoadBalancerAutoConfiguration拦截器注入

02深度解析Spring Cloud Ribbon---LoadBalancerAutoConfiguration拦截器注入

一、LoadBalancerAutoConfiguration介绍

1、LoadBalancerAutoConfiguration 的注入满足条件

2、 LoadBalancerAutoConfiguration 内容

3、小结

二、LoadBalancerInterceptor的相关逻辑

1. intercept 拦截内容

2. RibbonLoadBalancerClient 具体内容

3. ILoadBalancer 分析

3.1 ILoadBalancer 的默认注入和 依赖属性

3.1.1 定位RibbonClientConfiguration

3.2 AbstractLoadBalancer 类

3.3 BaseLoadBalancer 类

3.3.1 BaseLoadBalancer 类 的属性

3.3.2 PingTask() 介绍

3.3.3 BaseLoadBalancer 方法介绍

3.4 DynamicServerListLoadBalancer介绍

3.4.1 DynamicServerListLoadBalancer 属性

3.4.1.1 ServerList 介绍

3.4.1.2 ServerListFilter 介绍

3.4.1.3 ServerStats 介绍

3.4.1.4 ServerListUpdater 介绍

3.4.1.5 IRule介绍

3.4.1.5.1 ZoneAvoidanceRule 相关的方法介绍

3.4.1.5.2 AvailabilityFilteringRule

3.4.2 DynamicServerListLoadBalancer 方法介绍

3.4.3 DynamicServerListLoadBalancer 小结

3.5 ZoneAwareLoadBalancer介绍

三、运行的流程图

四、 小结

3.1 ILoadBalancer 的默认注入和依赖属性

3.3.1 BaseLoadBalancer 类的属性

四、小结