Ribbon之ZoneAwareLoadBalancer及其父类做了些什么？

1.看看ZoneAwareLoadBalancer都做了些什么？

这个类主要是跟Zone有关的,提供了跟zone有关的方法。但是在国内基本上用不上。

eureka提供了region和zone两个概念来进行分区，这两个概念均来自于亚马逊的AWS：
region：可以简单理解为地理上的分区，比如亚洲地区，或者华北地区，再或者北京等等，没有具体大小的限制。根据项目具体的情况，可以自行合理划分region。
zone：可以简单理解为region内的具体机房，比如说region划分为北京，然后北京有两个机房，就可以在此region之下划分出zone1,zone2两个zone。

简单的说一下这个类里面的几个方法：

1.setServerListForZones : 这个基于Zone进行服务划分

2.chooseServer这里也是主要跟zone有关的计算，当然默认的Zone只有一个，所以直接是调用的父类的chooseServer（key)

3.getLoadBalancer(String zone) 基于zone去获取LoadBalancer

4.setRule(IRule rule) 为每个负载均衡器设置规则。

这里可以看到，其实这个主要是针对Zone做了一些分类处理，就是将原来属于同一服务的服务实例，再根据地区进行划分。这也是为了能够快速响应而设置的。

2.ZoneAwareLoadBalancer的父类DynamicServerListLoadBalancer 做了些什么？

这个类按照名称来说就是动态加载服务列表使用的。其中有个几个比较重要的方法

1.获取服务列表并更新本地缓存的服务列表

2.开启服务列表更新定时任务

3.开启监听

DynamicServerListLoadBalancer的核心就是获取服务列表，默认是通过DomainExtractingServerList来获取，这个类是在org.springframework.cloud.netflix.ribbon.eureka.EurekaRibbonClientConfiguration#ribbonServerList

方法中声明的。这是eureka为ribbon提供的获取服务列表的入口。

3.如何通过DynamicServerListLoadBalancer 来获取服务列表的呢？

从上面的两张图可以看出，DomainExtractingServerList是用来获取服务列表，那底层是如何实现的呢？

这两张图刚好与ribbonServerList方法中创建DomainExtractingServerList的情形一致。那么我们就知道了，DiscoveryEnabledNIWSServerList才是获取服务列表的最终处理类(这是在基于有eureka的情况下)。

7.DynamicServerListLoadBalancer的父类BaseLoadBalancer做了些什么？

核心默认值

• 默认的负载均衡策略RoundRobinRule

• 默认的Ping策略SerialPingStrategy

• 所有服务实例容器：allServerList

• 在线服务实例容器：upServerList

从子类构造中将对应的负载均衡规则，ping策略，ping等传递过来

这里可以看到ping为null，setPingTask是用来开启ping的定时任务，默认每10秒ping一次。

8.ping做了些什么？

PingTask作为一个线程任务，就是定期检查服务是否都存活，跟ServerListUpdater服务更新机制不冲突。这是ribbon自己维护的一套服务检测机制，主要是为了降低访问失败的概率。默认在使用eureka时，ping是使用的是NIWSDiscoveryPing来完成服务保活检测。由eureka 和 ServerListUpdater来刷新服务列表。

这里有个常用的定时任务快速退出的方法，我觉得在我们自己写的时候也可以使用。

就是在同一个定时任务如果执行时间超过了定时周期，那么下一个定时任务发现上一个定时任务还没有执行完时，就先取消。

这里也用了很多锁机制，比如复制所有服务实例到一个新的对象时使用的是读锁，就是告诉allServers现在只能读不能写。

在发送ping后，将检测通过的服务放入newUpList中，最后通过写锁，将upServerList锁住。

这里就是只能有一个写，且不能读。

上面是ping在检测过程中关于读写锁和原子类的使用，是我们应该学着融入我们自己的项目中的东西。

主要流程就是：

1.读取全部服务实例列表

2.检测服务实例是否存活pingServers

3.将服务状态发生改变的放入changedServers

4.将服务在线的放入newUpList

5.将newUpList赋值到upServerList 在线服务实例列表中

这里面pingServers就是检查心跳的

private static class SerialPingStrategy implements IPingStrategy {

        @Override
        public boolean[] pingServers(IPing ping, Server[] servers) {
            int numCandidates = servers.length;
            boolean[] results = new boolean[numCandidates];

            logger.debug("LoadBalancer:  PingTask executing [{}] servers configured", numCandidates);

            for (int i = 0; i < numCandidates; i++) {
                results[i] = false; /* Default answer is DEAD. */
                try {
                    // NOTE: IFF we were doing a real ping
                    // assuming we had a large set of servers (say 15)
                    // the logic below will run them serially
                    // hence taking 15 times the amount of time it takes
                    // to ping each server
                    // A better method would be to put this in an executor
                    // pool
                    // But, at the time of this writing, we dont REALLY
                    // use a Real Ping (its mostly in memory eureka call)
                    // hence we can afford to simplify this design and run
                    // this
                    // serially
										// 上面一片注释告诉我们，如果我们有很多服务，其实直接使用for循环来写
										// 会比较耗时，最好是用线程池来做。但是，ribbon主要是为了跟eureka进行结合，
										// 这里的调用就是调用的当前服务的eurekaClient来检测
										// 其实不涉及到ping其他服务，所以这里就偷懒了。
										// 而spring cloud ribbon连ping都没用
                    if (ping != null) {
                        results[i] = ping.isAlive(servers[i]);
                    }
                } catch (Exception e) {
                    logger.error("Exception while pinging Server: '{}'", servers[i], e);
                }
            }
            return results;
        }
    }
}

其实在我使用eureka和ribbon进行连接的时候，ping是为NIWSDiscoveryPing的。

其实如果不使用ping的话，默认的ribbon从eureka读取注册表信息是30秒一次。且也没有事件监听机制。那么ribbon自己的缓存更新，可能会造成一个服务上线或者下线30秒后才会被ribbon发现。所以ping机制还是有必要的，所以每10秒检测一次服务存活状态刚好弥补了30秒的空档期。

9.BaseLoadBalancer的其他功能简述

1. 对allServerList和upServerList的读写锁方法
2. 提供对allServerList和upServerList的增删改功能
3. 提供了PingTask（ping的定时任务），Pinger（ping的执行器）
4. 基于负载均衡策略选择服务rule.choose(key)
5. 提供默认的ping策略SerialPingStrategy

ILoadBalancer各个层级之间负责不同的功能，这也是我们自己在设计一个对象时需要考虑的事情，从不同的层次去继承和组合我们就能得到我们想要的东西。