Spring Cloud Ribbon

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

客户端负载均衡

　　负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡对系统的高可用，网络压力的缓解和处理能力的扩容的重要手段之一。我们通常所说的负载均衡都是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作。只要是服务端负载均衡都能以类似的下图架构方式搭建起来：

 

 

 　　硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保障清单中都是可以正常访问的服务端节点。当客户端发送请求道负载均衡设备时，该设备按某种算法，比如线性轮询，按权重负载，按流量负载从维护的可用服务清单中取出一天服务端的地址，然后进行转发。

　　而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到的服务清单所出存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己想要访问的服务端清单，而这些服务端的清单来自于服务注册中心，。

 　　通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单，只需要如下两步：

1.服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。

2.服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。

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

 

RestTemplate详解

　　RestTemplate，该对象会使用Ribbon的自动化配置，同时通过配置@LoadBalanced还能够开启客户端负载均衡。

 

GET请求

　　在RestTemplate中，对GET请求可以通过如下两个方法进行调用实现。

 

 

 

 

 

 

POST请求

　　在RestTemplate中，对POST请求时可以通过如下三个方法进行调用实现。

 

 

PUT请求

 

 

 DELETE请求

负载均衡策略

　　

每个ribbon客户端包含：ILoadBalancer,  RestClient,  ServerListFilter, ServerList,IRule。

1. ILoadBalancer：是负载均衡的入口类。
2. ServerList：存储远程服务所有可用节点
3. ServerListFilter：用于过滤非法的远程节点（如：不可用等）
4. IRule：负载算法（策略），用于从可用节点选择一个合适的节点。
5. RestClient：远程调用

　　　　

<dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-ribbon</artifactId>
   </dependency>

 

Ribbon的负载均衡策略

1、RoundRobinRule(轮询模式) public class RoundRobinRule extends AbstractLoadBalancerRule roundRobin方式轮询选择server 轮询index，选择index对应位置的server          该策略也是ribbon的默认策略

2、RandomRule(随机策略) public class RandomRule extends AbstractLoadBalancerRule 随机选择一个server 在index上随机，选择index对应位置的server。

3、BestAvailableRule（并发量） public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule 选择一个最小的并发请求的server 逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的server

4、AvailabilityFilteringRule(服务器状态) public class AvailabilityFilteringRule extends PredicateBasedRule 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值） 使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态

 

5、WeightedResponseTimeRule（根据响应时间） public class WeightedResponseTimeRule extends RoundRobinRule 根据响应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。 一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成statas时，使用roubine策略选择server。

6、RetryRule(根据策略+重试) public class RetryRule extends AbstractLoadBalancerRule 对选定的负载均衡策略机上重试机制。 在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server

7、ZoneAvoidanceRule（Zone状态+服务状态） public class ZoneAvoidanceRule extends PredicateBasedRule 复合判断server所在区域的性能和server的可用性选择server 使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。

 

 自动化配置

由于Ribbon中定义的每一个接口都有多种不同的策略实现，同时这些接口之间又有一定的依赖关系，这使得第一次使用Ribbon的开发者很难上手，不知道如何选择具体的实现策略和以及如何组织他们的关系。Spring Cloud Ribbon中的自动化配置恰恰能够解决这样的痛点，在引入SpringCloudRibbon以来之后，就能够自动化构建下面这些接口的实现。

通过自动化配置的实现，我们可以轻松实现客户端负载均衡，同时，针对一些个性化需求，我们也可以方便的替换上面的这些默认实现。

只需要在SpringBoot应用中创建对应的应用实例就可以覆盖这些默认的配置实现。

 

重试机制