一、前言
接下来是开展一系列的 SpringCloud 的学习之旅，从传统的模块之间调用，一步步的升级为 SpringCloud 模块之间的调用，此篇文章为第三篇，即介绍 Ribbon 负载均衡服务调用
二、概述
2.1 Ribbon 是什么
Spring Cloud Ribbon 是基于 Netflix Ribbon 实现的一套客户端负载均衡的工具。
简单的说，Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon 客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出 Load Balancer（简称 LB）后面所有的机器，Ribbon 会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们很容易使用 Ribbon 实现自定义的负载均衡算法。
2.2 Ribbon 资料
可以进入官网，查看该工具的使用方式，github 源码的地址在这，不过到目前为止， Ribbon 也进入了维护模式，如下图
2.3 Ribbon 用途
Ribbon 可以实现负载均衡（Load Balance）的功能。
2.3.1 负载均衡是什么
简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的 HA（高可用）。常见的负载均衡有软件 Nginx，LVS，硬件 F5 等。
2.3.2 Ribbon 和 Nginx 区别
Ribbon 本地负载均衡客户端 和 Nginx 服务端负载均衡有什么区别呢？
Nginx 是服务器负载均衡，客户端所有请求都会交给 nginx，然后由 nginx 实现转发请求。即负载均衡是由服务端实现的。
Ribbon 本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到 JVM 本地，从而在本地实现 RPC 远程服务调用技术。
2.3.3 总结
前面第二篇文章我们通过配置订单模块的负载均衡，轮询的去访问我们的两个支付模块 8001 和 8002 ，采用的技术就是 负载均衡+ RestTemplate 调用。
三、Ribbon 负载均衡演示
3.1 架构说明
Ribbon 在工作时分成两步，第一步先选择 EurekaServer，它优先选择在同一个区域内负载较少的 server。第二步再根据用户指定的策略，在从 server 取到的服务注册列表中选择一个地址。
Ribbon 提供了多种策略：比如轮询、随机和根据响应时间加权。
3.2 pom 说明
之前在 cloud-consumer-order80 订单模块我们并没有引入 Ribbon 的依赖也可以使用它，那是因为 spring-cloud-starter-netflix-eureka-client 自带了 spring-cloud-starter-ribbon 引用，如下图：
3.3 RestTemplate
在没有使用 OpenFeign 组件之前，我们还是使用 RestTemplate 来进行远程服务的调用，其主要使用的方法就是 getForObject/getForEntity、postForObject/postForEntity 如下所示：
@RestController
@Slf4j
public class OrderController {
@Resource
private RestTemplate restTemplate;
// public static final String PaymentSrv_URL = "http://localhost:8001";
public static final String PAYMENT_SRV = "http://CLOUD-PAYMENT-SERVICE";
@GetMapping("/consumer/payment/create")
public CommonResult create(Payment payment){
// 客户端用浏览器是get请求，但是底层实质发送post调用服务端8001
// return restTemplate.postForObject(PAYMENT_SRV+"/payment/create",payment,CommonResult.class);
return restTemplate.postForEntity(PAYMENT_SRV+"/payment/create",payment,CommonResult.class).getBody();
}
// 返回对象为响应体中数据转化成的对象，基本上可以理解为Json
@GetMapping("/consumer/payment/get/{id}")
public CommonResult getPayment(@PathVariable Long id)
{
return restTemplate.getForObject(PAYMENT_SRV + "/payment/get/"+id, CommonResult.class, id);
}
// 返回对象为 ResponseEntity 对象，包含了响应中的一些重要信息，比如响应头、响应状态码、响应体等
@GetMapping("/consumer/payment/getForEntity/{id}")
public CommonResult getPayment2(@PathVariable Long id)
{
ResponseEntity<CommonResult> entity = restTemplate.getForEntity(PAYMENT_SRV + "/payment/get/" + id, CommonResult.class, id);
if(entity.getStatusCode().is2xxSuccessful()){
return entity.getBody();
}else{
return new CommonResult(444,"操作失败");
}
}
}四、Ribbon 核心组件 IRule
4.1 默认的负载均衡算法
IRule 是负载均衡顶级的父接口，它会根据特定的算法从服务列表中选取一个要访问的服务，它的实现类，它的类图如下所示：
IRule 接口现有的实现类，即默认存在的负载均衡策略如下：
1、com.netflix.loadbalancer.RoundRobinRule，轮询（默认）
2、com.netflix.loadbalancer.RandomRule，随机
3、com.netflix.loadbalancer.RetryRule，先按照 RoundRobinRule 的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务。
4、WeightedResponseTimeRule，对 RoundRobinRule 的扩展，响应速度越快的实例选择权重越大，越容易被选择。
5、BestAvailableRule，会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。
6、AvailabilityFilteringRule，先过滤掉故障实例，再选择并发较小的实例
7、ZoneAvoidanceRule，默认规则，复合判断 server 所在区域的性能和 server 的可用性选择服务器。
4.2 替换默认负载均衡算法
4.2.1 配置细节
我们需要新建一个自定义配置类来替换默认的负载均衡算法，但是官方文档明确给出了警告，这个自定义配置类不能放在 @ComponentScan 所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的 Ribbon 客户端所共享，达不到特殊化定制的目的了。
我们在 cloud-consumer-order80 模块上进行配置，现在的项目结构如下所示：
我们如果想要自定义一个配置类，就需要重新创建一个包，且这个包不被 Spring 扫描到，如下图：
4.2.2 创建配置类
在 myrule 包下，创建自定义配置类 MySelfRule，代码如下所示：
@Configuration
public class MySelfRule {
@Bean
public IRule myRule(){
// 定义一个随机类型的负载均衡算法
return new RandomRule();
}
}
4.2.3 修改主启动类
在主启动类上，添加注解，并指定负载均衡的类型和服务的名称，如下：
@SpringBootApplication
@EnableEurekaClient
@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration= MySelfRule.class)
public class OrderMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderMain80.class,args);
}
}4.2.4 测试
分别启动 cloud-eureka-server7001、cloud-eureka-server7002、cloud-provider-payment8001、cloud-provider-payment8002 和 cloud-consumer-order80 模块，然后不断的刷新请求地址 http://localhost/consumer/payment/get/1，如下图：
五、Ribbon 负载均衡算法
5.1 原理
轮询负载均衡算法：rest 接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标 ，每次服务重启动后 rest 接口计数从 1 开始。
以 8081 和 8082 组合成集群为例，一共两台机器，集群总数量为 2 ，按照轮询的算法原理：
1、当总请求数为 1 时： 1 % 2 =1 对应下标位置为 1 ，则获得服务地址为 127.0.0.1:8001
2、当总请求数位 2 时： 2 % 2 =0 对应下标位置为 0 ，则获得服务地址为 127.0.0.1:8002
3、当总请求数位 3 时： 3 % 2 =1 对应下标位置为 1 ，则获得服务地址为 127.0.0.1:8001
4、 当总请求数位 4 时： 4 % 2 =0 对应下标位置为 0 ，则获得服务地址为 127.0.0.1:8002
以此类推。
5.2 手写负载均衡算法
接下来我们手写一个轮询类型的负载均衡算法。
首先在 cloud-provider-payment8001 和 cloud-provider-payment8002 模块的 PaymentController 类中添加如下的方法用于后续的测试：
@GetMapping(value = "/payment/lb")
public String getPaymentLB()
{
return serverPort;
}然后把 cloud-consumer-order80 模块的 ApplicationContextConfig 类的负载均衡的注解注释掉，如下：
@Configuration
public class ApplicationContextConfig {
@Bean
//使用@LoadBalanced注解赋予RestTemplate负载均衡的能力
// @LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
在 cloud-consumer-order80 模块中创建一个接口和实现类，用来实现轮询的负载均衡，如下：
package com.springcloud.lb;
import org.springframework.cloud.client.ServiceInstance;
import java.util.List;
public interface LoadBalancer {
// 从服务器集群中选择一台来处理请求
ServiceInstance instances(List<ServiceInstance> serviceInstances);
}
package com.springcloud.lb;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.stereotype.Component;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
@Component
public class MyLB implements LoadBalancer{
// 创建一个原子类来记录服务调用的次数
private AtomicInteger atomicInteger = new AtomicInteger(0);
public final int getAndIncrement(){
int current;
int next;
do{
// 获取当前的调用次数的值
current = this.atomicInteger.get();
// 获取下一次调用次数的值，若值大于 Integer 的最大值则重新开启计数
next = current > 2147483647 ? 0 : current +1;
// 自旋锁,current 为当前值，next 为期望值，如果不满足这个条件则一直自旋，使用 CAS 保证线程安全
}while(!this.atomicInteger.compareAndSet(current,next));
System.out.println("***********next 第几次调用："+next);
return next;
}
@Override
public ServiceInstance instances(List<ServiceInstance> serviceInstances) {
// 用当前调用次数的下标除以集群的数量，然后取余数
int index = getAndIncrement() % serviceInstances.size();
// 最终确定由集群的哪台机器处理请求
return serviceInstances.get(index);
}
}
修改 cloud-consumer-order80 模块的 OrderController 类的代码，使其调用方法时采用我们指定的负载均衡的策略，代码如下：
@RestController
@Slf4j
public class OrderController {
@Resource
private RestTemplate restTemplate;
// public static final String PaymentSrv_URL = "http://localhost:8001";
public static final String PAYMENT_SRV = "http://CLOUD-PAYMENT-SERVICE";
@GetMapping("/consumer/payment/create")
public CommonResult create(Payment payment){
// 客户端用浏览器是get请求，但是底层实质发送post调用服务端8001
return restTemplate.postForObject(PAYMENT_SRV+"/payment/create",payment,CommonResult.class);
}
// 返回对象为响应体中数据转化成的对象，基本上可以理解为Json
@GetMapping("/consumer/payment/get/{id}")
public CommonResult getPayment(@PathVariable Long id)
{
return restTemplate.getForObject(PAYMENT_SRV + "/payment/get/"+id, CommonResult.class, id);
}
@Resource
private LoadBalancer loadBalancer;
@Resource
private DiscoveryClient discoveryClient;
@GetMapping("/consumer/payment/lb")
public String getPaymentLB(){
// 获取集群上所有可用的节点
List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
if(instances == null || instances.size()<=0) {
return null;
}
// 选择具体由哪台机器干活
ServiceInstance serviceInstance = loadBalancer.instances(instances);
URI uri = serviceInstance.getUri();
// 干活
return restTemplate.getForObject(uri+"/payment/lb",String.class);
}
}接下来进行测试，启动各个模块，在浏览器输入 http://localhost/consumer/payment/lb，如下图，可以看到刷新一次浏览器，界面显示的都会发生有规则的变化。
控制台的后台打印内容如下：
