阅读完需：约 7 分钟
RestTemplate的工作过程，在分析的过程中，我们遇到过一个ILoadBalancer接口，这个接口中有一个chooseServer方法是我们选择服务实例的方法，这个也是整个负载均衡中最最核心的部分，那么它到底是采用了什么样的策略从服务提供者列表中选出了一个服务供服务消费者去调用的?
关于 RestTemplate 笔记：
负载均衡器
首先我们来看一张上篇文章中的旧图：
这是ILoadBalancer接口的一张类关系图，我们就从这张图里看起吧。
AbstractLoadBalancer
AbstractLoadBalancer类的定义如下：
public abstract class AbstractLoadBalancer implements ILoadBalancer {
public enum ServerGroup{
ALL,
STATUS_UP,
STATUS_NOT_UP
}
public Server chooseServer() {
return chooseServer(null);
}
public abstract List<Server> getServerList(ServerGroup serverGroup);
public abstract LoadBalancerStats getLoadBalancerStats();
}关于这个类我说以下几点：
1. AbstractLoadBalancer实现了ILoadBalancer接口，但它是一个抽象类，它里边定义了一个关于服务实例的分组枚举类，包含了三种类型的服务：ALL表示所有服务，STATUS_UP表示正常运行的服务，STATUS_NOT_UP表示下线的服务。
2. chooseServer方法毫无疑问是用来选取一个服务实例，但是要怎么选这里并没有说，我们以后在它的实现类里边寻找选取策略。
3. getServerList方法用来获取某一个分组中所有的的服务实例。
4. getLoadBalancerStats方法用来获取LoadBalancerStats对象，LoadBalancerStats对象中保存了每一个服务的所有细节信息。
BaseLoadBalancer
BaseLoadBalancer是AbstractLoadBalancer的一个实现类，源码比较长就不贴出来的，我们在这里主要来说说BaseLoadBalancer提供了哪些功能：
1. 首先这个类中有两个List集合中放的Server对象，一个List集合用来保存所有的服务实例，还有一个List集合用来保存当前有效的服务实例。
2. BaseLoadBalancer中定义了一个IPingStrategy，用来描述服务检查策略，IPingStrategy默认实现采用了SerialPingStrategy实现，SerialPingStrategy中的pingServers方法就是遍历所有的服务实例，一个一个发送请求，查看这些服务实例是否还有效，如果网络环境不好的话，这种检查策略效率会很低，如果我们想自定义检查策略的话，可以重写SerialPingStrategy的pingServers方法。
3. 在BaseLoadBalancer的chooseServer方法中(负载均衡的核心方法)，我们发现最终调用了IRule中的choose方法来找到一个具体的服务实例，IRule是一个接口，在BaseLoadBalancer它的默认实现是RoundRobinRule类，RoundRobinRule类中采用了最常用的线性负载均衡规则，也就是所有有效的服务端轮流调用。
4. 在BaseLoadBalancer的构造方法中会启动一个PingTask，这个PingTask用来检查Server是否有效，PingTask的默认执行时间间隔为10秒。
5. markServerDown方法用来标记一个服务是否有效，标记方式为调用Server对象的setAlive方法设置isAliveFlag属性为false。
6. getReachableServers方法用来获取所有有效的服务实例列表。
7. getAllServers方法用来获取所有服务的实例列表。
8. addServers方法表示向负载均衡器中添加一个新的服务实例列表。
BaseLoadBalancer的功能大概就这么多。
DynamicServerListLoadBalancer
DynamicServerListLoadBalancer是BaseLoadBalancer的一个子类，在DynamicServerListLoadBalancer中对基础负载均衡器的功能做了进一步的扩展，我们来看看。
1. 首先DynamicServerListLoadBalancer类一开始就声明了一个变量serverListImpl，serverListImpl变量的类型是一个ServerList<T extends Server>，这里的泛型得是Server的子类，ServerList是一个接口，里边定义了两个方法：一个getInitialListOfServers用来获取初始化的服务实例清单；另一个getUpdatedListOfServers用于获取更新的服务实例清单。
2. ServerList接口有很多实现类，DynamicServerListLoadBalancer默认使用了DomainExtractingServerList类作为ServerList的实现，但是在DomainExtractingServerList的构造方法中又传入了DiscoveryEnabledNIWSServerList对象，查看源码发现最终两个清单的获取方式是由DiscoveryEnabledNIWSServerList类来提供的。
3. DomainExtractingServerList类中的obtainServersViaDiscovery方法是用来发现服务实例并获取的，obtainServersViaDiscovery方法的主要逻辑是这样：首先依靠EurekaClient从服务注册中心获取到具体的服务实例InstanceInfo列表，然后对这个列表进行遍历，将状态为UP的实例转换成DiscoveryEnabledServer对象并放到一个集合中，最后将这个集合返回。
4. DynamicServerListLoadBalancer中还定义了一个ServerListUpdater.UpdateAction类型的服务更新器，Spring Cloud提供了两种服务更新策略：一种是PollingServerListUpdater，表示定时更新；另一种是EurekaNotificationServerListUpdater表示由Eureka的事件监听来驱动服务列表的更新操作，默认的实现策略是第一种，即定时更新，定时的方式很简单，创建Runnable，调用DynamicServerListLoadBalancer中updateAction对象的doUpdate方法，Runnable延迟启动时间为1秒，重复周期为30秒。
5. 在更新服务清单的时候，调用了我们在第一点提到的getUpdatedListOfServers方法，拿到实例清单之后，又调用了一个过滤器中的方法进行过滤。过滤器的类型有好几种，默认是DefaultNIWSServerListFilter，这是一个继承自ZoneAffinityServerListFilter的过滤器，具有区域感知功能。即它会对服务提供者所处的Zone和服务消费者所处的Zone进行比较，过滤掉哪些不是同一个区域的实例。
综上，DynamicServerListLoadBalancer主要是实现了服务实例清单在运行期间的动态更新能力，同时提供了对服务实例清单的过滤功能。
ZoneAwareLoadBalancer
ZoneAwareLoadBalancer是DynamicServerListLoadBalancer的子类，ZoneAwareLoadBalancer的出现主要是为了弥补DynamicServerListLoadBalancer的不足。由于DynamicServerListLoadBalancer中并没有重写chooseServer方法，所以DynamicServerListLoadBalancer中负责均衡的策略依然是我们在BaseLoadBalancer中分析出来的线性轮询策略，这种策略不具备区域感知功能，这样当需要跨区域调用时，可能会产生高延迟。ZoneAwareLoadBalancer重写了setServerListForZones方法，该方法在其父类中的功能主要是根据区域Zone分组的实例列表，为负载均衡器中的LoadBalancerStats对象创建ZoneStats并存入集合中，ZoneStats是一个用来存储每个Zone的状态和统计信息。重写之后的setServerListForZones方法主要做了两件事：一件是调用getLoadBalancer方法来创建负载均衡器，同时创建服务选择策略；另一件是对Zone区域中的实例清单进行检查，如果对应的Zone下已经没有实例了，则将Zone区域的实例列表清空，防止节点选择时出现异常。
