微服务体系下的 Spring Cloud Netflix 套件中 Ribbon 的主要用于负载均衡，底层默认使用 RestTemplate 通讯，并提供了 7 种负载均衡策略
前言在微服务中，对服务进行拆分之后，必然会带来微服务之间的通信需求，而每个微服务为了保证高可用性，又会去部署集群，那么面对一个集群微服务进行通信的时候，如何进行负载均衡也是必然需要考虑的问题。那么有需求自然就有供给，由此一大批优秀的开源的负载均衡组件应运而生，本文就让我们一起来分析一下 Spring Cloud Netflix 套件中的负载均衡组件 Ribbon。
一个问题引发的思考首先我们来看一个问题，假如说我们现在有两个微服务，一个 user-center，一个 user-order，我现在需要在 user-center 服务中调用 user-order 服务的一个接口。
这时候我们可以使用 HttpClient，RestTemplate 等发起 http 请求，user-center 服务端口为 8001，如下图所示：
而 user-order 服务中只是简单的定义了一个接口，user-order 服务端口为 8002：
这时候只需要将两个服务启动，访问 http://localhost:8001/user/order 就可以获取到所有的订单信息。
可以看到，这样是可以在两个微服务之间进行通讯的，但是，假如说我们的 user-order 服务是一个集群呢？这时候怎么访问呢？因为 user-order 服务已经是集群，所以必然需要一种算法来决定应该请求到哪个 user-order 服务中，最简单的那么自然就是随机或者轮询机制，轮询或者随机其实就是简单的负载均衡算法，而 Ribbon 就是用来实现负载均衡的一个组件，其内部支持轮询，等算法。
Ribbon的简单使用接下来我们看看 Ribbon 的简单使用。
首先改造 user-order 服务，在 user-order 服务中定义一个服务名配置：
将 user-order 服务中的 UserOrderController 稍微改造一下，新增一个端口的输出来区分：
通过 VM 参数 -Dserver.port=8002 和 -Dserver.port=8003 分别来启动两个 user-order 服务。接下来改造 user-center 服务，在 user-center 服务中引入 Ribbon 的相关依赖： user-center 服务中新增一个 Ribbon 相关配置，列举出需要访问的所有服务： 对 user-center 服务中的 UserController 进行改造：这时候我们再次访问 http://localhost:8001/user/order 就可以看到请求的 user-order 服务会在 8002 和 8003 之间进行切换。
Ribbon 原理分析看了上面 Ribbon 的使用示例，会不会觉得有点麻烦，每次还需要自己去获取 ip 和端口，然后格式化 url，但是其实实际开发过程中我们并不会通过这么原始的方式来编写代码，接下来我们再对上面的示例进行一番改造：
在这个示例中，主要就是一个关键主键起了作用：@LoadBalanced。
@LoadBalanced 注解进入 @LoadBalanced 注解中，我们可以看到，这个注解其实没有任何逻辑，只是加了一个 @Qualifier 注解：
这个注解大家应该很熟悉了，常用语同一个 Bean 有多个不同名称注入的场景。
@Qualifier注解下面我们通过一个例子来演示一下 Qualifier注解的用法。
新建一个空的 TestDemo 类，并新增一个 TestConfiguration 类来创建不同名称的 TestDemo：
这时候我们如果需要注入 TestDemo，那么有很多种办法，具体的使用就需要看业务需要来决定。
方法一：直接使用 @Autowired，并使用 List 集合来接收 Bean，这样所有 TestDemo 类型的 Bean 都会被注入。方法二：通过使用 @Resource(name = "testDemo1") 注解来指定名称，这样就可以只注入一个 Bean。方法三：通过使用 @Resource 和 @Qualifier(value = "testDemo1") 来指定一个 Bean，其实这种方式和方法二的效果基本一致。方法四：使用 @Autowired 和 @Qualifier 注解来注入，不指定任何名称，如下所示：这时候运行之后我们发现不会有任何 Bean 被注入到集合中，这是因为当使用这种方式来注入时，Spring 会认为当前只需要注入被 @Qualifier 注解标记的 Bean，而我们上面定义的两个 TestDemo 都没有被 @Qualifier 修饰。
这时候，我们只需要在 TestConfiguration 稍微改造，在 TestDemo 的定义上加上 @Qualifier 修饰即可：
这时候再去运行，就会发现，testDemo1 和 testDemo2 都会被注入。
LoadBalancerAutoConfiguration 自动装配SpringCloud 是基于 SpringBoot 实现的，所以我们常用的这些分布式组件都会基于 SpringBoot 自动装配来实现，我们进入 LoadBalancerAutoConfiguration 自动装配类可以看到，RestTemplate 的注入加上了 @LoadBalanced，这就是为什么我们前面的例子中加上了 @LoadBalanced 就能被自动注入的原因：
RestTemplateCustomizer上面我们看到，RestTemplate 被包装成为了 RestTemplateCustomizer，而 RestTemplateCustomizer 的注入如下：
可以看到这里面加入了一个拦截器 LoadBalancerInterceptor，事实上即使不看这里，我们也可以猜测到，我们直接使用服务名就可以进行通讯的原因必然是底层有拦截器对其进行转换成 ip 形式，并在底层进行负载均衡选择合适的服务进行通讯。
LoadBalancerInterceptorLoadBalancerInterceptor 是 Ribbon 中默认的一个拦截器，所以当我们调用 RestTemplate 的 getObject 方法时，必然会调用拦截器中的方法。
从源码中可以看到，LoadBalancerInterceptor 中只有一个 intercept() 方法：
RibbonLoadBalancerClient#execute继续跟进 execute 方法会进入到 RibbonLoadBalancerClient 类（由 RibbonAutoConfiguration 自动装配类初始化）中：
这个方法中也比较好理解，首先获取一个负载均衡器，然后再通过 getServer 方法获取一个指定的服务，也就是当我们有多个服务时，到这里就会选出一个服务进行通讯。
进入 getServer 方法：
我们看到，最终会调用 ILoadBalancer 中的 chooseServer 方法，而 ILoadBalancer 是一个顶层接口，这时候具体会调用哪个实现类那么就需要先来看一下类图：
这里直接看类图也无法看出到底会调用哪一个，但是不论调用哪一个，我们猜测他肯定会有一个地方去初始化这个类，而在 Spring 当中一般就是自动装配类中初始化或者 Configuration 中初始化，而 ILoadBalancer 正是在 RibbonClientConfiguration 类中被加载的：
ZoneAwareLoadBalancer 负载均衡器ZoneAwareLoadBalancer 的初始化会调用其父类 DynamicServerListLoadBalancer 进行初始化，然后会调用 restOfInit 方法进行所有服务的初始化。
如何获取所有服务使用 Ribbon 后，我们通讯时并没有指定某一个 ip 和端口，而是通过服务名来调用服务，那么这个服务名就可能对应多个真正的服务，那么我们就必然需要先获取到所有服务的 ip 和端口等信息，然后才能进行负载均衡处理。
获取所有服务有两种方式：
从配置文件获取从 Eureka 注册中心获取（需要引入注册中心）。初始化服务的方式是通过启动一个 Scheduled 定时任务来实现的，默认就是 30s 更新一次，其实在很多源码中都是通过这种方式来定时更新的，因为源码要考虑的使用的简单性所以不太可能引入一个第三方中间件来实现定时器。
具体的源码如下所示：enableAndInitLearnNewServersFeature() 方法启动的定时任务最终仍然你是调用 updateListOfServers() 方法来更新服务。
最终在获取到服务之后会调用父类 BaseLoadBalancer 中的将所有服务设置到 allServerList 集合中（BaseLoadBalancer 类中维护了一些负载均衡需要使用到的服务相关信息）。
如何判断服务是否可用当我们获取到配置文件（或者 Eureka 注册中心）中的所有服务，那么这时候能直接执行负载均衡策略进行服务分发吗？显然是不能的，因为已经配置好的服务可能会宕机（下线），从而导致服务不可用，所以在 BaseLoadBalancer 中除了有一个 allServerList 集合来维护所有服务器，还有一个集合 upServerList 用来维护可用服务集合，那么如何判断一个服务是否可用呢？答案就是通过心跳检测来判断一个服务是否可用。
心跳检测 Task在讲心跳检测之前，我们先看一下 BaseLoadBalancer 中的 setServersList 方法，有一段逻辑比较重要：
这段逻辑我们看到，默认情况下，如果 Ping 的策略是 DummyPing，那么默认 upServerList = allServerList，而实际上，假如我们没有进行进行特殊配置，其实默认的就是 DummyPing，这也是在 RibbonClientConfiguration 类中被加载的：
在 BaseLoadBalancer 初始化过程中，也会启动一个 Scheduled 定时任务去定时更新任务，最终和 forceQuickPing() 方法一样，调用一个默认策略来触发心跳检测，而默认策略就是 DummyPing，也就是默认所有服务都是可用的。
虽然默认不执行真正的心跳检测操作，但是 Netflix 中提供了 PingUrl 等其他策略，PingUrl 其实就是发起一个 http 请求，如果有响应就认为服务可用，没响应就认为服务不可用。
修改心跳检测策略可以通过如下配置切换（user-order-service 为客户端的服务名），既然是可配置的，那么也可以自己实现一个策略，只需要实现 IPing 接口即可。
Ribbon 的负载均衡算法当获取到可用服务之后，那么最后应该选择哪一个服务呢？这就需要使用到负载均衡策略，在 Ribbon 中，可以通过配置修改，也可以自定义负载均衡策略（实现 IRule 接口）。
RandomRule：随机算法RoundRobinRule：轮询算法ZoneAvoidanceRule：结合分区统计信息筛选出合适的分区（默认的负载均衡算法）RetryRule：在 deadline 时间内，如果请求不成功，则重新发起请求知道找到一个可用的服务。WeightedResponseTimeRule：根据服务器的响应时间计算权重值，服务器响应时间越长，这个服务器的权重就越小，会有定时任务对权重值进行更新。AvailabilityFilteringRule：过滤掉短路（连续 3 次连接失败）的服务和高并发的服务。BestAvailableRule：选择并发数最低的服务器负载均衡算法可通过以下配置进行修改：
总结本文主要讲述了微服务体系下的 Spring Cloud Netflix 套件中 Ribbon 的使用，并结合部分源码讲述了 Ribbon 的底层原理，重点讲述了 Ribbon 中是如何获取服务以及如何判定一个服务是否可用，最后也介绍了 Ribbon 中默认提供的 7 种负载均衡策略。
到此这篇关于Spring Cloud之负载均衡组件Ribbon原理分析的文章就介绍到这了,更多相关Spring Cloud负载均衡组件Ribbon内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
