Ribbon 在实现客户端负载均衡时，是通过Ribbo的ILoadBalancer接口实现的。
AbstractLoadBalancer
是ILoadBalancer接口的抽象实现，定义了一个分组枚举类ServerGroup
还实现了一个chooseServer()方法，其中key为null，表示在选择具体实例时忽略key的条件判断
还定义了两个抽象方法
getServerList(ServerGroup serverGroup):根据分组类型获取不同的实例列表
getLoadBalancerStats():定义了获取LoadBalancerStats对象的方法，
LoadBalancerStats对象被用来存储负载均衡中各个服务实例当前的属性和统计信息。
BaseLoadBalancer
是Ribbon负载均衡的基础实现类，
定义并维护了两个存储服务实例Server对象的列表。一个用于存储所有服务实例的清单，
一个用于存储正常服务的实例清单
定义了各服务实例属性和统计信息的LoadBalancerStats对象
定义了检查服务实例是否正常服务的IPing对象，默认为null，构造时注入
定义了检查服务实例操作的执行策略对象IPingStrategy，在BaseLoadBalancer中
默认使用了SerialPingStrategy，遍历检查
定义了负载均衡的处理规则IRule对象，从BaseLoadBalancer中
chooseServer(Object key)，实际将选择任务委托给IRule.choose()方法，IRule默认为
RoundRobinRule
启动ping任务：在BaseLoadBalancer的默认构造方法中，会直接启动一个用于定时检查Server是否健康的任务
DynamicServerListLoadBalancer
对基础负载均衡的扩展。在该负载均衡中，实现了服务实例清单在运行期的动态更新能力；
同时，还具备了对服务实例清单的过滤功能。新增如下
ServerList serverListImpl
ServerList继承结构如下
上图中有多个ServerList的实现类，那么在DynamiceServerListLoadBalancer中的ServerList默认配置到底使用了哪个具体实现？
既然该负载均衡类中需要实现服务实例的动态更新，那么势必需要Ribbon具备访问Eureka来获取服务实例的能力，在包
org.springframework.cloud.netflix.ribbon.eureka下，可以找到配置类EurekaRibbonClientConfiguration，找到如下
这里创建的一个DomainExtractingServerList实例，在这个类源码中，还定义类一个ServerList list. 同时对getInitialListOfServers()
和getUpdatedListOfServers()的具体实现，其实委托给内部定义的ServerList list对象
由构造方法传入的DiscoveryEnabledNIWSServerLIst实现的。
在DiscoveryEnableNIWSServerList中
在obtainServersViaDiscovery()方法中
主要逻辑是，依靠EurekaClient从服务注册中心获取到具体的服务实例InstanceInfo列表，vipAddress可以理解为逻辑上的服务名如USER-SERVICE
然后遍历，找到UP的实例转换成DiscoveryEnabledServer对象 ，返回
返回的结果List到了DomainExtractingServerList类中，将继续通过setZones()方法进行处理
ServerListUpdater
DynamicServerListLoadBalancer类中属性ServerListUpdater中
主要是对ServerList的更新，
而ServerListUpdater的实现类不多，如下
PollingServerListUpdater:动态服务列表更新的默认策略，也就是DynamicServerListLoadBalancer中默认实现，
它通过定时任务实现更新
EurekaNotificationServerListUpdater 需要利用Eureka的事件监听器来驱动服务列表的更新操作
ServerListFilter
回到updateAction.doUpdate()方法，在DynamicServerListLoadBalancer中，调用updateListOfServers()方法
调用之前提到的ServerList.getUpdatedListOfServers()，获取到从Eureka Server中获取服务可用实例的列表。
通过ServerListFilter filter过滤，继承关系如下
AbstractServerListFilter:定义类过滤时需要的一个重要对象LoadBalancerStats，该对象存储了一些属性和统计信息等
ZoneAffinityServerListFilter:该过滤器基于“区域感知（Zone Affinity)”的方式实现服务实例的过滤，源码
过滤后，通过shouldEnableZoneAffinity()方法来判断是否启用“区域感知”功能。
使用LoadBalancerStats.getZoneSnapshot()获取过滤后同区域实例的基础指标（包含实例数量，断路器断开数，活动请求数，实例平均负载等）
根据一系列的算法求出下面的几个评价值并与设置的阈值进行比较，若有一个条件符合，就不启用“区域感知”。
可以实现当集群出现区域故障时，依然可以依靠其他区域的实例进行正常服务的高可用保障。
blackOutServerPercentage:故障实例百分比（断路器断开数/实例数)>=0.8
activeRequestsPerServer:实例平均负载>=0.6
availableSevers: 可用实例数（实例数 - 断路器断开数）<2
DefaultNIWSServerListFilter 完全继承ZoneAffinityServerListFilter，是默认NIWS（Netflix Internal Web Server）过滤器
ServerListSubSetFilter:
ZonePreferenceServerListFilter: Spring Cloud整合时新增的过滤器。若使用Spring Cloud整合Eureka和Ribbon时默认使用该过滤器
根据zone过滤出实例
ZoneAwareLoadBalancer
是对DynamicServerListLoadBalancer的扩展。DynamicServerListLoadBalancer中，没重写chooseServer()方法，所有它
依旧采用BaseLoadBalancer中的算法。使用RoundRobinRule规则，以线性轮询的方式来选择调用的服务实例，该算法实现
简单并没有区域（Zone）的概念，所以它会把所有实例视为一个Zone下的节点来看待，这样就会周期性地产生跨区域（Zone）
访问的情况，由于跨区域会产生更高的延迟，这些实例主要以防止区域性故障实现高可用为目的而不能作为常规访问的实例，
所以在多区域部署的情况下会有一定的性能问题，而该负载均衡则可以避免这样的问题。
在ZoneAwareLoadBalancer中，它没有重写setServersList，说明实现服务实例清单的更新主逻辑没有修改。但是发现它重写了setServerListForZones(Map
List>zoneServersMap)。
在DynamicServerListLoadBalancer中查找这个方法
setServerListForZones()在
setServersList()方法的最后被调用，在父类DynamicServerListLoadBalancer中的作用是根据按区域Zone分组的实例列表，为LoadBalancerStats对象创建ZoneStats并放入Map
zoneStatsMap中，每一个Zone对应一个
ZoneStats,它用于存储每个Zone的一些状态和统计信息。
在ZoneAwareLoadBalancer中setServerListForZones()如下
可以看到，在该实现中创建了一个ConcurentHashMap()类型的balancers对象，它将用来存储每个Zone区域对应的负载均衡器。
其中getLoadBalancer创建如下
在创建负载均衡器的时候会创建它的规则（如果当前实现中没有IRule实例，就创建一个AvailablityFilteringRule：否则克隆）
创建完负载均衡器后有调用setServersList()为其设置对应Zone区域的实例清单。
第二个循环则对Zone区域中实例清单的检查，看看是否有Zone区域下已经没有实例了
现在看一下ZoneAwareLoadBalancer中chooseServer()方法
当zone区域大于1时
①调用ZoneAvoidanceRule中的静态方法createSnapshot(lbStats)，为当前负载均衡器中所有的Zone区域创建快照，
保存在Map zoneSnapshot中
②调用ZoneAvoidancerRule中ZoneAvoidanceRule.getAvailableZones(zoneSnapshot,
triggeringLoad.get(), triggeringBlackoutPercentage.get());
来获取可用的Zone区域集合，通过Zone区域快照中的统计数据来实现可用区
的挑选。