使用Ribbon实现客户端负载均衡

• 关于Ribbon
• Ribbon实现负载均衡
• 使用属性自定义Ribbon配置
• 负载均衡策略介绍

上篇已经实现了Eureka Server的高可用，理论上已经使得微服务更加完美，但依旧存在些许问题。例如，来自服务消费者的请求如何分摊到部署了多个实例的服务提供者？分摊规则如何取？本篇即揭开Ribbon面纱。

1、Ribbon简介

Ribbon是Netflix发布的负载均衡器，它可以控制HTTP和TCP客户端的行为规则。Ribbon支持多种负载均衡规则帮助服务消费者根据指定规则分摊请求到服务提供者，如轮询、随机、加权响应时间、区域感知轮询等。Ribbon配合Eureka使用更加的高效，配置也得到的极大的简化，大致架构图如下：

2、Ribbon实现负载均衡

由上面的架构图可以清晰的看出，Ribbon配置在服务消费者端。下面开始配置

复制项目microservice-springcloud-ticket-consumer，修改ArtifactId为 microservice-consumer-ribbon；

pom文件中添加ribbon依赖: eureka中已包含ribbon依赖的jar了，故不再重复引入;

启动类ConsumerTicketApplication类中的RestTemplate上加上@LoadBalanced注解即可

@LoadBalanced@Beanpublic RestTemplate restTemplate() {    return new RestTemplate();}

修改TicketController类:

@GetMapping("/ribbon/{id}")public UserActivityInfo findById(@PathVariable Long id) {    return this.restTemplate.getForObject("http://microservice-springcloud-eureka-provider/"; + id, UserActivityInfo.class);}

注意: microservice-springcloud-eureka-provider是用户微服务实例中spring.application.name定义的服务提供者名称，一个名称可对应多个服务提供者实例

测试:

启动microservice-springcloud-eureka服务

启动microservice-consumer-ribbon服务

启动两个或更多microservice-springcloud-eureka-provider实例，每个实例端口要不一致

浏览器多次访问: http://localhost:8888/ribbon/1405050  

可以发现，每访问一次，控制台依次输出一次，也就是每次请求均匀分配到了各个实例上，默认负载规则为轮询，上述代码已实现

项目代码：microservice-consumer-ribbon

3、使用属性配置自定义Ribbon配置

特定场景下，需要修改负载均衡规则，如不再使用轮询，改为随机，那么结合属性配置的方式这些将变得很简单

在项目microservice-consumer-ribbon中的application.yml中添加服务提供者的ribbon负载均衡规则

microservice-springcloud-eureka-provider:   ribbon:      NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

microservice-springcloud-eureka-provider同上面的注意点的含义一致，这样便将负载均衡规则改为了随机

测试步骤同上，依次访问，依次观察两个用户微服务实例控制台的log，可以发现负载规则已经不再是轮询，而是随机了

4、Ribbon提供以下7种负载均衡策略(此表格借阅自他人博客)

策略名策略声明策略描述实现说明BestAvailableRulepublic class BestAvailableRule extends ClientConfigEnabledRoundRobinRule选择一个最小的并发请求的server逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的serverAvailabilityFilteringRulepublic class AvailabilityFilteringRule extends PredicateBasedRule过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态WeightedResponseTimeRulepublic class WeightedResponseTimeRule extends RoundRobinRule根据相应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成statas时，使用roubine策略选择server。RetryRulepublic class RetryRule extends AbstractLoadBalancerRule对选定的负载均衡策略机上重试机制。在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的serverRoundRobinRulepublic class RoundRobinRule extends AbstractLoadBalancerRuleroundRobin方式轮询选择server轮询index，选择index对应位置的serverRandomRulepublic class RandomRule extends AbstractLoadBalancerRule随机选择一个server在index上随机，选择index对应位置的serverZoneAvoidanceRulepublic class ZoneAvoidanceRule extends PredicateBasedRule复合判断server所在区域的性能和server的可用性选择server使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。