本来想写私人学习笔记的，但是觉得写博客作为学习笔记好一点，因为自己写笔记错了坑的是自己，所以不会很认真，但是博客写错了让人看到就像公开处刑（笑）一样，所以会认真一点，但是因为我菜，错误肯定会有，有大佬看不下去了的话欢迎指出。
负载均衡分为两种，一种是服务端负载均衡，一种是客户端负载均衡。
服务端负载均衡：分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，文中举例为F5。但是我这种菜鸡怎么可能知道F5是什么，然后在度娘的帮助下得到：F5负载均衡器是应用交付网络的全球领导者F5 Networks公司提供的一个负载均衡器专用设备，F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
重点看软件负载均衡：主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡，常见的就是Nginx。简单总结一下Nginx，Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。Nginx采用的是反向代理技术，代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
------------------------------------------------------------------------------拓展分割线----------------------------------------------------------------------------
那么在这里先学习总结一下反向代理，先说一下正向代理，我是一个用户,我访问不了某网站,但是我能访问一个代理服务器这个代理服务器呢,他能访问那个我不能访问的网站于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容。代理服务器去取回来,然后返回给我。从网站的角度,只在代理服务器来取内容的时候有一次记录。正向代理 是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。 反向代理正好相反，用户访问 http://ooxx.me/readme，但ooxx.me上并不存在readme页面，他是偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户。对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理 的命名空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容 原本就是它自己的一样。反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。
再来对比一下两者特点：
硬件：硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来 得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）
软件：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。负载能力受服务器本身性能的影响，性能越好，负载能力越大。
-------------------------------------------------------------------------------拓展完成------------------------------------------------------------------------------
无论是硬件负载均衡还是软件负载均衡都会维护一个可用的服务端清单，然后通过心跳机制来删除故障的服务端节点以保证清单中都是可以正常访问的服务端节点，此时当客户端的请求到达负载均衡服务器时，负载均衡服务器按照某种配置好的规则从可用服务端清单中选出一台服务器去处理客户端的请求。这就是服务端负载均衡。
接下来说一下客户端负载均衡，Ribbo是一个基于HTTP和TCP的客户端负载均衡器，当我们将Ribbon和Eureka一起使用时，Ribbon会从Eureka注册中心去获取服务端列表，然后进行轮询访问以到达负载均衡的作用，服务端是否在线这些问题则交由Eureka去维护。那么这个时候发现这两者的机制差不多，都是通过心跳维护有效服务清单列表，不同之处在于清单列表的存储位置。在Spring Cloud中我们如果想要使用客户端负载均衡，方法很简单，开启@LoadBalanced注解即可，这样客户端在发起请求的时候会先自行选择一个服务端，向该服务端发起请求，从而实现负载均衡。
接下来看一下@LoadBalanced，这个注解是用来给RestTemplate做标记，以使用LoadBalancerClient来配置它。那我们来看看LoadBalancerClient是什么,LoadBalancerClient是一个接口，
public interface ServiceInstanceChooser {
ServiceInstance choose(String serviceId);
}
public interface LoadBalancerClient extends ServiceInstanceChooser {
<T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException;
<T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException;
URI reconstructURI(ServiceInstance instance, URI original);
}
该接口中有四个方法，我们来大概看一下这几个方法的作用：
1.ServiceInstance choose(String serviceId)根据传入的服务名serviceId从客户端负载均衡器中挑选一个对应服务的实例。
2.T execute() ,使用从负载均衡器中挑选出来的服务实例来执行请求。
3.URI reconstructURI(ServiceInstance instance, URI original)表示为系统构建一个合适的URI，服务的逻辑名称(http://HELLO-SERVICE/hello)不是具体的服务地址，在reconstructURI方法中，第一个参数ServiceInstance实例是一个带有host和port的具体服务实例，第二个参数URI则是使用逻辑服务名定义为host和port的URI，而返回的URI则是通过ServiceInstance的服务实例详情拼接出的具体的host:port形式的请求地址。一言以蔽之，就是把类似于http://HELLO-SERVICE/hello这种地址转为类似于http://195.124.207.128/hello地址（IP地址也可能是域名）。
LoadBalancerAutoConfiguration是客户端负载均衡服务器的自动化配置类，根据源码认识到，@ConditionalOnClass(RestTemplate.class)和@ConditionalOnBean(LoadBalancerClient.class),说明Ribbon如果想要实现负载均衡的自动化配置需要满足两个条件：第一个，RestTemplate类必须存在于当前工程的环境中；第二个，在Spring容器中必须有LoadBalancerClient的实现Bean。
2.ribbonInterceptor方法返回了一个拦截器叫做LoadBalancerInterceptor，这个拦截器的作用主要是在客户端发起请求时进行拦截，进而实现客户端负载均衡功能。
那么我们发现实现客户端负载均衡功能就在这个拦截器上了，这个拦截器中注入了LoadBalancerClient的实现，当一个被@LoadBalanced注解修饰的RestTemplate对象向外发起HTTP请求时，会被LoadBalancerInterceptor类的intercept方法拦
LoadBalancerClient只有一个实现类---RibbonLoadBalancerClient。源码如下
public class RibbonLoadBalancerClient implements LoadBalancerClient {
@Override
public <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException {
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
Server server = getServer(loadBalancer);
if (server == null) {
throw new IllegalStateException("No instances available for " + serviceId);
}
RibbonServer ribbonServer = new RibbonServer(serviceId, server, isSecure(server,
serviceId), serverIntrospector(serviceId).getMetadata(server));
return execute(serviceId, ribbonServer, request);
}
@Override
public <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> request) throws IOException {
Server server = null;
if(serviceInstance instanceof RibbonServer) {
server = ((RibbonServer)serviceInstance).getServer();
}
if (server == null) {
throw new IllegalStateException("No instances available for " + serviceId);
}
RibbonLoadBalancerContext context = this.clientFactory
.getLoadBalancerContext(serviceId);
RibbonStatsRecorder statsRecorder = new RibbonStatsRecorder(context, server);
try {
T returnVal = request.apply(serviceInstance);
statsRecorder.recordStats(returnVal);
return returnVal;
}
// catch IOException and rethrow so RestTemplate behaves correctly
catch (IOException ex) {
statsRecorder.recordStats(ex);
throw ex;
}
catch (Exception ex) {
statsRecorder.recordStats(ex);
ReflectionUtils.rethrowRuntimeException(ex);
}
return null;
}
protected Server getServer(ILoadBalancer loadBalancer) {
if (loadBalancer == null) {
return null;
}
return loadBalancer.chooseServer("default"); // TODO: better handling of key
}
protected ILoadBalancer getLoadBalancer(String serviceId) {
return this.clientFactory.getLoadBalancer(serviceId);
}
}
在execute方法中，首先根据serviceId获取一个ILoadBalancer，然后调用getServer方法去获取一个服务实例，但是在getServer方法中，我们看到并没有调用LoadBalancerClient中的choose方法，而是调用了另一个叫做ILoadBalancer的中定义的chooseServer方法。那这个接口又是什么呢？我们来看看：
public interface ILoadBalancer {
public void addServers(List<Server> newServers);
public Server chooseServer(Object key);
public void markServerDown(Server server);
public List<Server> getReachableServers();
public List<Server> getAllServers();
}
1.addServers表示向负载均衡器中维护的实例列表增加服务实例
2.chooseServer表示通过某种策略，从负载均衡服务器中挑选出一个具体的服务实例
3.markServerDown表示用来通知和标识负载均衡器中某个具体实例已经停止服务，否则负载均衡器在下一次获取服务实例清单前都会认为这个服务实例是正常工作的
4.getReachableServers表示获取当前正常工作的服务实例列表
5.getAllServers表示获取所有的服务实例列表，包括正常的服务和停止工作的服务
该接口实现所有类中BaseLoadBalancer类实现了基础的负载均衡，而DynamicServerListLoadBalancer和ZoneAwareLoadBalancer则在负载均衡的策略上做了一些功能的扩展。Spring Cloud默认采用ZoneAwareLoadBalancer。
上面的内容在下觉得有点绕，在下觉得主线任务就是：@LoadBalanced->LoadBalancerClient.execute()->RibbonLoadBalancerClient.execute()->ILoadBalancer.chooseServer()
那么接下来的重点就是ILoadBalancer.chooseServer()。
看一下ILoadBalancer的实现抽象类--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区域的实例列表清空，防止节点选择时出现异常。
在BaseLoadBalancer它的默认实现是RoundRobinRule类，RoundRobinRule类中采用了最常用的线性负载均衡规则，也就是所有有效的服务端轮流调用。这个类的choose(ILoadBalancer lb, Object key)函数整体逻辑是这样的：开启一个计数器count，在while循环中遍历服务清单，获取清单之前先通过incrementAndGetModulo方法获取一个下标，这个下标是一个不断自增长的数先加1然后和服务清单总数取模之后获取到的（所以这个下标从来不会越界），拿着下标再去服务清单列表中取服务，每次循环计数器都会加1，如果连续10次都没有取到服务，则会报一个警告No available alive servers after 10 tries from load balancer: XXXX。
最后说一下其他AbstractLoadBalancerRule的子类。
RandomRule：这种负载均衡策略就是随机选择一个服务实例。
RetryRule：这种负载均衡策略带有重试功能。在失效时间deadline之前不断的进行重试（重试时获取服务的策略还是RoundRobinRule中定义的策略），如果超过了deadline还是没取到则会返回一个null。
WeightedResponseTimeRule：是RoundRobinRule的一个子类，会根据每一个实例的运行情况来给计算出该实例的一个权重，然后在挑选实例的时候则根据权重进行挑选，这样能够实现更优的实例调用。
BestAvailableRule：是ClientConfigEnabledRoundRobinRule的一个子类，根据loadBalancerStats中保存的服务实例的状态信息来过滤掉失效的服务实例的功能，然后顺便找出并发请求最小的服务实例来使用。然而loadBalancerStats有可能为null，如果loadBalancerStats为null，则BestAvailableRule将采用它的父类即ClientConfigEnabledRoundRobinRule的服务选取策略（线性轮询）。
PredicateBasedRule：是ClientConfigEnabledRoundRobinRule的一个子类，它先通过内部定义的一个过滤器过滤出一部分服务实例清单，然后再采用线性轮询的方式从过滤出来的结果中选取一个服务实例。
ZoneAvoidanceRule:是PredicateBasedRule的一个实现类,ZoneAvoidanceRule中的过滤条件是以ZoneAvoidancePredicate为主过滤条件和以AvailabilityPredicate为次过滤条件组成的一个叫做CompositePredicate的组合过滤条件，过滤成功之后，继续采用线性轮询的方式从过滤结果中选择一个出来。
参考：https://blog.csdn.net/u012702547/article/details/77961438