写在前面：

• 你好，欢迎你的阅读！
• 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
• 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
• 除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
• 微信公众号：傲骄鹿先生

说明：

1、专栏涉及到的源码已经同步至 https://github.com/SetAlone/springcloud2020（持续更新）

2、springcloud系列博文内容为学习《尚硅谷2020最新版SpringCloud(H版&alibaba)框架开发教程》的记录，此系列课程是目前看来个人觉得非常不错的资源，在此可以与大家进行分享。

3、个人收集到了课程源码和所需的脑图、笔记等资源，如需要私信我即可。查找资源不易，希望可以给个点赞和关注

1.1 Ribbon是什么

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套 客户端负载均衡 工具；

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供 客户端软件的负载均衡和服务调用。Ribbon客户端组件提供一系列完善的配置项，如连接超时，重试等。总之，就是在配置文件中列出 Load Balancer （检查LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们很容易使用Ribbon实现自定义的负载均衡算法。

1.2 Ribbon能干嘛

Ribbon主要是用来做负载均衡，简单的说就是将用户的请求分配到多个服务上，从而达到系统的HA（高可用）。常见的负载均衡软件有：Nginx，LVS和硬件 F5等。

Ribbon本地负载均衡客户端和Nginx服务端负载均衡的区别：

首先了解两个概念：集中式负载均衡和进程内负载均衡

集中式负载均衡：在服务的消费方和服务提供方之间使用独立的LB设施（可以是硬件F5，也可以是软件，如Nginx），由该设施负责把访问请求通过某种策略转发至服务的提供方；

进程内负载均衡：将负载均衡的逻辑 集成到消费方，消费方从服务注册中心获取有哪些地址可以调用，然后自己再从这些地址中选出一个合适的服务器。Ribbon就属于进程内LB，它只是一个类库，集成在消费方进程中，消费方通过它来获取服务提供方的地址。

Nginx是服务端负载均衡，客户端所有的请求都会交给Nginx，然后由Nginx实现请求的转发；即负载均衡是由服务端实现的。

Ribbon的本地负载均衡，是在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后，缓存到JVM本地，从而在本地实现RPC远程服务调用的技术。Ribbon实现负载均衡是通过：@LoadBalanced 和 RestTemplate 实现的

Ribbon的负载均衡机制在工作时分两步：

1、优先选择Eureka Server，它会优先选择同一区域内负载较少的server；

2、然后根据用户指定的策略（如轮询，随机和根据响应时间加权等），从server的服务注册列表中选择一个地址。

总结：Ribbon其实就是一个软负载均衡的客户端组件， 他可以和其他所需请求的客户端结合使用，和eureka结合只是其中一个实例。

1.3 Ribbon整合（pom）

之前我们的Eureka做服务注册和发现的时候，我们已经实现了Ribbon的负载均衡，但是我们的pom文件中，并没有引入Ribbon的坐标。这是因为我们的 ribbon坐标，依赖了eureka client ，所以只要引入了eureka client，也就自动拥有的Ribbon的负载均衡；可以查看eureka client的坐标的依赖关系：

点击查看源码的时候，发现在eureka client依赖中已近引入了ribbon的依赖

这样的依赖关系在maven中看的更加明显：

 

2.1 演示Ribbon的负载均衡

启动我们之前的：cloud-eureka-server7001 和 cloud-eureka-server7002 的Eureka Server ；

然后启动服务提供者：cloud-provider-payment8001 和 cloud-provider-payment8002；

最后启动消费方：cloud-consumer-order80

浏览器访问：http://eureka7001.com:7001/ 和 http://eureka7001.com:7002/ 能看到我们的80，8001和8002都注册到了Eureka Server

然后浏览器多次访问：http://localhost/consumer/payment/get/1 可以看到返回的信息中，端口是8001和8002交替出现的，这说明我们基于轮询的负载均衡已经实现了。

2.2 RestTemplate的getForEntity和postForEntity

之前我们的cloud-consumer-order80的OrderController，我们使用的是RestTemplate的getForObject和postForObject方法，其实RestTemplate还有两个类似的方法：getForEntity和postForEntity方法；

getForObject方法的返回对象为响应体中的数据转化成的对象，可以简单的理解为json对象；

getForEntity方法返回的是ResponseEntity对象，包含了响应中的一些重要信息，比如响应头，响应状态码和响应体等；

postForObject和postForEntity方法的差别也类似，

在cloud-consumer-order80的OrderController中，加上了使用getForEntity和postForEntity调用服务的方法：

@GetMapping("/consumer/payment/getForEntity/{id}")
    public CommonResult<Payment> getPayment2(@PathVariable("id") Long id)
    {
        ResponseEntity<CommonResult> entity = restTemplate.getForEntity(PAYMENT_URL+"/payment/get/"+id,CommonResult.class);

        if(entity.getStatusCode().is2xxSuccessful()){
            return entity.getBody();
        }else{
            return new CommonResult<>(444,"操作失败");
        }
    }

重新启动order80服务，浏览器访问：

http://localhost/consumer/payment/getForEntity/1 和 http://localhost/consumer/payment/get/1 都是成功的

3.1 核心组件IRule

IRule：根据特定算法从服务列表中选取一个要访问的服务；

IRule有以下实现：

com.netflix.loadbalancer.RoundRobinRule：轮询；（默认就是轮询）

com.netflix.loadbalancer.RandomRule：随机；

com.netflix.loadbalancer.RetryRule：先按照RoundRobinRule的策略获取服务，如果获取服务失败，则在指定时间内进行重试，获取可用的服务；

WeightedResponseTimeRule：对RoundRobinRule的扩展，响应速度越快的实例选择权重越多大，越容易被选择；

BestAvailableRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务；

AvailabilityFilteringRule：先过滤掉故障实例，再选择并发较小的实例；

ZoneAvoidanceRule：默认规则，复合判断server所在区域的性能和server的可用性选择服务器；

3.2 如何设置负载均衡算法

Ribbon的默认负载均衡算法是 RoundRobinRule（轮询），如果我们不想使用默认的，那么怎么去设置使用其他的的负载均衡算法呢？

3.2.1 注意配置细节

官方文档明确给出了警告：
这个自定义配置类不能放在@ComponentScan所扫描的当前包以及子包下，否则我们自定义的这个配置 类就会被所有的Ribbon客户端所共享，也就是说达不到特殊化定制的目的了！

添加Ribbon的配置类的时候，注意该类必须配置在**@SpringBootApplication主类以外的包下**。不然的话所有的服务都会按照这个规则来实现。会被所有的RibbonClient共享。主要是主类的主上下文和Ribbon的子上下文起冲突了。父子上下文不能重叠。

• 自定义的负载均衡算法，不能在SpringBoot启动时扫描到，即自定义的负载均衡类，不能放在启动类的子包或启动类所在包中。
• 定义配置类将自定义的负载均衡算法注入Spring容器中。(配置类也不能被启动类扫描到)
• 启动类上添加注解@RibbonClient(name=“微服务名”, configuration=“装载自定义负载均衡算法的配置类”)。

3.2.2 编写自定义的 IRule 配置类

新建一个包，该包不能是主启动的子包

在该包下面创建一个MyRibbonRule 配置类：定义负载均衡的算法是随机；

@Configuration
public class MySelfRule
{
    @Bean
    public IRule myRule()
    {
        return new RandomRule();//定义为随机
    }
}

3.2.3 主启动类上添加注解@RibbonClient

@SpringBootApplication
@EnableEurekaClient  //这是一个Eureka的client端
@EnableDiscoveryClient  //服务发现开启
//在启动该微服务的时候就能去加载我们的自定义Ribbon配置类，从而使配置生效
@RibbonClient(name = "CLOUD-PAYMENT-SERVICE", configuration = MySelfRule.class)
public class OrderMain80 {
    public static void main(String[] args) {
        SpringApplication.run(OrderMain80.class,args);
    }
}

@RibbonClient(name = “CLOUD-PAYMENT-SERVICE”, configuration = MySelfRule.class) ：告诉程序，我们要使用自定义的 随机 的负载算法。

3.2.4 测试

启动7001，7002，8001，8002和order80，然后多次浏览器访问：http://localhost/consumer/payment/get/1

效果是：不再是之前的轮询一样，交替返回8001和8002提供服务，而是随机的，可能是多次都是8001，然后再是8002。

4.1 Ribbon负载均衡算法

4.1.1 iRule源码

package com.netflix.loadbalancer;

public interface IRule {
    Server choose(Object var1);//选择哪个服务处理请求

    void setLoadBalancer(ILoadBalancer var1);//设置ILoadBalancer 类型的变量信息

    ILoadBalancer getLoadBalancer();//获取ILoadBalancer 类型的变量信息
}

IRule接口中有两个类型值得注意：Server和ILoadBalancer。Server封装了是注册进Eureka的微服务信息，也就代表注册进Eureka的微服务。而ILoadBalancer是一个接口，用来获取注册进Eureka的全部或部分或某个微服务信息，如下：

package com.netflix.loadbalancer;

import java.util.List;

public interface ILoadBalancer {
    void addServers(List<Server> var1);

    Server chooseServer(Object var1);

    void markServerDown(Server var1);

    /** @deprecated */
    @Deprecated
    List<Server> getServerList(boolean var1);

    List<Server> getReachableServers();

    List<Server> getAllServers();
}

到这里可以看出，IRule接口是通过ILoadBalancer来获取Server，进而实现负载均衡。下面我们以**RoundRobinRule(轮询)**为例分析IRule如何实现负载均衡，以及我们如何自定义实现负载均衡.

4.1.2 AbstractLoadBalancerRule源码

AbstractLoadBalancerRule 抽象类实现了IRule接口：

package com.netflix.loadbalancer;

import com.netflix.client.IClientConfigAware;

public abstract class AbstractLoadBalancerRule implements IRule, IClientConfigAware {
    private ILoadBalancer lb;

    public AbstractLoadBalancerRule() {
    }

    public void setLoadBalancer(ILoadBalancer lb) {
        this.lb = lb;
    }

    public ILoadBalancer getLoadBalancer() {
        return this.lb;
    }
}

4.1.3 RoundRobinRule轮询算法源码

package com.netflix.loadbalancer;

import com.netflix.client.config.IClientConfig;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class RoundRobinRule extends AbstractLoadBalancerRule {
    private AtomicInteger nextServerCyclicCounter;
    private static final boolean AVAILABLE_ONLY_SERVERS = true;
    private static final boolean ALL_SERVERS = false;
    private static Logger log = LoggerFactory.getLogger(RoundRobinRule.class);

    public RoundRobinRule() {
        this.nextServerCyclicCounter = new AtomicInteger(0);
    }

    public RoundRobinRule(ILoadBalancer lb) {
        this();
        this.setLoadBalancer(lb);
    }

    public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            log.warn("no load balancer");
            return null;
        } else {
            Server server = null;
            int count = 0;

            while(true) {
                if (server == null && count++ < 10) {
                    List<Server> reachableServers = lb.getReachableServers();
                    List<Server> allServers = lb.getAllServers();
                    int upCount = reachableServers.size();
                    int serverCount = allServers.size();
                    if (upCount != 0 && serverCount != 0) {
                        int nextServerIndex = this.incrementAndGetModulo(serverCount);
                        server = (Server)allServers.get(nextServerIndex);
                        if (server == null) {
                            Thread.yield();
                        } else {
                            if (server.isAlive() && server.isReadyToServe()) {
                                return server;
                            }
                            server = null;
                        }
                        continue;
                    }
                    log.warn("No up servers available from load balancer: " + lb);
                    return null;
                }
                if (count >= 10) {
                    log.warn("No available alive servers after 10 tries from load balancer: " + lb);
                }
                return server;
            }
        }
    }

    private int incrementAndGetModulo(int modulo) {
        int current;
        int next;
        do {
            current = this.nextServerCyclicCounter.get();
            next = (current + 1) % modulo;
        } while(!this.nextServerCyclicCounter.compareAndSet(current, next));

        return next;
    }

    public Server choose(Object key) {
        return this.choose(this.getLoadBalancer(), key);
    }

    public void initWithNiwsConfig(IClientConfig clientConfig) {
    }
}

4.2 原理分析

轮询的负载均衡算法：Rest接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标，（每次服务重启后Rest接口计数从1开始）。

//通过服务别名获取服务的实例
List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");

如：List[0] instances = 127.0.0.1:8002

​ List[1] instances = 127.0.0.1:8001

8001+8002组合成为集群，他们共计2台机器，集群总数是2，按照轮询算法的原理：

当总请求数为1：1%2 = 1 对应的下标为1，则获取的服务地址为 127.0.0.1:8001

当总请求数为1：2%2 = 0 对应的下标为0，则获取的服务地址为 127.0.0.1:8002

当总请求数为1：3%2 = 1 对应的下标为1，则获取的服务地址为 127.0.0.1:8001

当总请求数为1：4%2 = 0 对应的下标为0，则获取的服务地址为 127.0.0.1:8002

依此类推…

4.3 自定义轮询负载均衡算法

4.3.1 8001和8002的controller添加下面的测试方法

@GetMapping(value = "/payment/lb")
public String getPaymentLB() {
    return serverPort;
}

4.3.2 注释掉order80的RestTemplate的@LoadBalanced注解

@Configuration
public class OrderConfig {

    /**
     * 注册RestTemplate
     * @return
     */
    @Bean
    //@LoadBalanced  //注释掉，使用自定义的Ribbon负载均衡算法
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

4.3.3 自定义轮询算法

接口：MyLoadBalancer

public interface MyLoadBalancer {
    /**
     * 获取存活的服务实例列表
     * @param serviceInstances
     */
    ServiceInstance instances(List<ServiceInstance> serviceInstances);
}

实现类：MyLoadBalancerImpl

/**
 * Ribbon手写轮询算法
 */
@Component
public class MyLoadBalancerImpl implements MyLoadBalancer {

    private AtomicInteger atomicInteger = new AtomicInteger(0);

    public final int getAndIncrement() {
        int current;
        int next;
        do {
            current = this.atomicInteger.get();
            // 超过最大值,为0,重新计数 2147483647 Integer.MAX_VALUE
            next = current >= 2147483647 ? 0 : current + 1;
            // 自旋锁
        } while (!atomicInteger.compareAndSet(current, next));
        System.out.println("****第几次访问,次数next:" + next);
        return next;
    }

    /**
     * 负载均衡算法:rest接口第几次请求数%服务器集群总数量=实际调用服务器位置下标,每次服务重启动后rest接口计数从1开始.
     *
     * @param serviceInstances
     */
    @Override
    public ServiceInstance instances(List<ServiceInstance> serviceInstances) {
        int index = getAndIncrement() % serviceInstances.size();
        return serviceInstances.get(index);
    }
}

4.3.4 OrderController添加方法

/**
 * 路由规则: 轮询
 * http://localhost/consumer/payment/payment/lb
 */
@GetMapping(value = "/consumer/payment/lb")
public String getPaymentLB() {
    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
    if (instances == null || instances.size() <= 0) {
        return null;
    }
    ServiceInstance serviceInstance = myLoadBalancer.instances(instances);
    //获取服务器端uri
    URI uri = serviceInstance.getUri();
    return restTemplate.getForObject(uri + "/payment/lb", String.class);
}

测试：http://localhost/consumer/payment/lb 也是8001和8002交替出现的，并且控制打印如下：

****第几次访问,次数next:1
****第几次访问,次数next:2
****第几次访问,次数next:3
****第几次访问,次数next:4
****第几次访问,次数next:5
****第几次访问,次数next:6
****第几次访问,次数next:7
****第几次访问,次数next:8
****第几次访问,次数next:9
****第几次访问,次数next:10
****第几次访问,次数next:11
****第几次访问,次数next:12
****第几次访问,次数next:13