负载均衡分客户端负载均衡和服务端负载均衡，例如nginx，接收到请求之后，在通过负载均衡算法，选择一个服务器，而客户端负载均衡则不同，是在发送请求之前，根据历史的请求统计数据及相关策略选择一个目标服务器，后直接访问目标服务器。服务端负载均衡即所有请求都要全局统筹，而客户端负载均衡，则是每个服务各自维护自己负载均衡。
例如spring cloud中的ribbon，客户端从Euraka中获取到服务器的实例列表，在发送请求前通过负载均衡算法从中选择一个目标服务器。
ribbon中比较核心的接口就是ILoadBalancer,IPing,IRule。
其中ILoadBalancer负责全局调用，其中的chooseServer，则是调用Rule的choose方法。
IPing判断目标的服务能否访问,默认有以下几种实现：
- PingUrl 真实的去ping 某个url，判断其是否alive
- PingConstant 固定返回某服务是否可用，默认返回true，即可用
- NoOpPing 不去ping,直接返回true,即可用。
- DummyPing 直接返回true，并实现了initWithNiwsConfig方法。
- NIWSDiscoveryPing，根据DiscoveryEnabledServer的InstanceInfo的InstanceStatus去判断，如果为InstanceStatus.UP，则为可用，否则不可用。
从baseLoadBalncer的源码是中可以看到,Iping是在负载均衡ILoadBalancer初始化的时候，启动一个定时任务，默认间隔10s执行ping任务，判断服务是否可用。
而IRule则是具体的负载均衡策略,默认实现有以下几种:
- BestAvailableRule 选择最小请求数
- ClientConfigEnabledRoundRobinRule 轮询
- RandomRule 随机选择一个server
- RoundRobinRule 轮询选择server
- RetryRule 根据轮询的方式重试
- WeightedResponseTimeRule 根据响应时间去分配一个weight ，weight越低，被选择的可能性就越低
- ZoneAvoidanceRule 根据server的zone区域和可用性来轮询选择
说到负载均衡策略，还有一个比较重要的类是ServerStats，是统计一个服务的状态，包括总的请求数，当前活动的请求activeRequestsCount（本客户端调用的请求），上次请求时间等等，这些状态是由Ribbon维护的一个当前客户端的请求状态，例如，当发起一个请求时，activeRequestsCount加1，当请求结束时，activeRequestsCount减1。
下面看一下BestAvailableRule的实现，就是简单的遍历serverList的,剔除掉被tripped的服务实例后，从中选择一个activeRequestsCount最小的服务。