客户端负载均衡介绍（ribbon）

客户端负载均衡介绍（ribbon）

学习中笔记

---

一、什么是负载均衡

LB（Load Balance，负载均衡）是一种集群技术，它将特定的业务（网络服务、网络流量等）分担给多台网络设备（包括服务器、防火墙等）或多条链路，从而提高了业务处理能力，保证了业务的高可靠性。
负载均衡技术具有一下优势：

• 高性能：负载均衡技术将业务较均衡的分担到多台设备或链路上，从而提高了整个系统的性能；
• 可扩展性：负载均衡技术可以方便的增加集群中设备或链路的数量，在不降低业务质量的前提下满足不断增长的业务需求；
• 高可靠性：单个甚至多个设备或链路法神故障也不会导致业务中断，提高了整个系统的可靠性
• 可管理性：大量的管理共组都集中在使用负载均衡技术的设备上，设备集群或链路集群只需要维护通过的配置即可；
• 透明性：对用户而言，集群等于一个或多个高可靠性、高性能的设备或链路，用户感知不到，也不关心具体的网络结构，增加或减少设备或链路数量都不会影响正常的业务。

二、目前负载均衡主要分为两大类

• 集中式：
  即在服务的消费方和提供方之间使用独立的LB设施，可以是硬件，如F5,也可以是软件，如nginx，由该设施负责把访问请求通过某种策略转发至服务的提供方；
• 进程内（客户端）：
  将LB逻辑集成到消费方，消费方从服务注册中心获取可用服务列表，然后根据指定负载均衡策略选择合适的服务器。Ribbon就属于该方式。

三、客户端负载均衡

客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端端清单来自于服务注册中心，比如nacos服务端。同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，
通过Spring Cloud Ribbon的封装，在微服务架构中使用客户端负载均衡调用非常简单，只需要如下两步：

• 服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
• 服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。

这样，我们就可以将服务提供者的高可用以及服务消费者的负载均衡调用一起实现了。

四、ribbon介绍

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括Feign，它也是基于Ribbon实现的工具。

五、Ribbon六大组件

• IRule：从服务器列表中决定用哪个服务器
• IPing ：后台运行的任务，用来验证服务器是否可用
• ServerList：可以是静态也可以是动态，如果是动态，那么就要有一个后台线程定时去刷新和过滤列表。微服务基于服务发现的情况，服务器列表肯定都是动态增减的。
• ServerListFilter：对ServerList服务器列表进行二次过滤
• ServerListUpdater：定义服务更新策略
• ILoadBalancer：软件负载平衡器入口，整合以上所有的组件实现负载功能
  组件分工：
  ServerList和ServerListFilter生成客户端可以访问的服务列表
  ServerListUpdater和IPing：根据服务的状态更新服务列表
  IRule：服务的选择策略
  ILoadBalancer：将以上组件组合到这个类中一起工作

六、IRule ribbon的负载均衡规则

• RoundRobinRule 轮询默认使用：轮询服务列表List的index，选择index对应位置的服务。
• RandomRule 随机：随机服务列表List的index，选择index对应位置的服务。
• RetryRule 重试：指定时间内，重试(请求)某个服务不成功达到指定次数，则不再请求该服务。
• BestAvailableRule 最小并发：逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的server
• AvailabilityFilteringRule 可利用性： 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）。使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态
• WeightedResponseTimeRule 加权响应时间：根据响应时间分配一个weight，响应时间越长，weight越小，被选中的可能性越低。一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成status时，使用roubine策略选择server。
• ZoneAvoidanceRule 区域回避：复合判断server所在区域的性能和server的可用性选择server。使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。

七、iping方式

• DummyPing：虚设的iping，继承AbstractLoadBalancerPing，永远返回true
• NoOpPing：直接返回true
• PingConstant：只要常量参数为true，则表示服务存活，否则都是失效的服务实例。
• PingUrl：通过request访问服务返回的状态码来判定服务是否存活。
• NIWSDiscoveryPing：通过服务发现来判定服务实例是否存活。

八、服务器列表serverList

• StaticServerList：通过静态配置来维护服务列表。
• ConfigurationBasedServerList：基于读取Archaius配置文件来维护ServerList
• DomainExtractingServerList：这是一个代理类 服务列表获取逻辑是由DiscoveryEnabledNiWSServerList来实现，旨在从其服务列表中提取zone，是SpringCloud默认的获取服务列表的类。
• DiscoveryEnabledNIWSServerList：通过服务发现获取服务器信息的服务器列表类

九、ServerListFilter

• AbstractServerListFilter：负责从负载均衡器中过滤出当前可用的服务器列表的类
• ZoneAffinityServerListFilter: 过滤掉所有的不和客户端在相同zone的服务过滤掉所有的不和客户端在相同zone的服务，如果和客户端相同的zone不存在，才不过滤不同zone有服务
• ServerListSubsetFilter: 在第一个类的基础上，只返回所有服务的子集此过滤器确保客户端仅看到由ServerList实现返回的整个服务器的固定子集。 它还可以定期用新服务器替代可用性差的子集中的服务器。 如果服务器场很大，这很有用。在成百上千的情况下，使用它们中的每一个，并保持http客户端连接池中的连接是不必要的。它还可以通过比较总的网络故障和并发连接来驱逐相对不健康的服务器
• ZonePreferenceServerListFilter：在ZoneAffinityServerListFilter的基础上，再增根据消费者配置预设的区域Zone来进行过滤(默认配置)
• DefaultNUWSServerListFilter：通过服务发现获取

十、ServerListUpdater: 定义服务更新策略

• PollingServerListUpdater：定时更新(默认配置)
• EurekaNotificationServerListUpdater：监听Eureka的事件更新服务列表由Eureka的事件监听来驱动服务列表的更新操作

十一、ILoadBalancer：将以上组件组合到这个类中一起工作

• NoOpLoadBalancer：没有处理
• BaseLoadBalancer：负载均衡器的基本实现。此类内部维护一个存储所有服务实例列表和一个当前活着的服务实例列表。默认使用轮询策略选择一个服务实例做为请求对象。定义一个定时器，根据IPingStrategy定时轮询ping服务实例，用于判断服务列表是否活着。默认的ping策略为SerialPingStrategy
• DynamicServerListLoadBalancer：DynamicServerListLoadBalancer是BaseLoadBalancer的一个子类，对基础负载均衡器的功能做了进一步的扩展。增加了服务实例列表动态更新的功能，同时增加对服务实例列表过滤的功能此类内部依靠DomainExtractingServerList从EurekaClient从注册中心获取服务实例列表，将状态为UP的服务实例组成新的服务列表，使用ZoneAffinityServerListFilter再对这个列表进行过滤。此类内部默认使用PollingServerListUpdater对服务实例列表进行定时更新，保证服务的有效性
• ZoneAwareLoadBalancer：ZoneAwareLoadBalancer是DynamicServerListLoadBalancer的子类，增加zone策略。DynamicServerListLoadBalancer默认使用轮询策略，但是此策略在进行跨区域调用时，可能会产生高延迟。此类使用ZoneStats存储每个Zone的状态和平均请求情况，当一个zone的平均请求达到阈值或请求超时的比例达到阈值或zone不可用，则将该zone的服务实例中删除。此类使用AvailabilityFilteringRule选择一个服务实例。