springcloud之Ribbon负载均衡简介

一、概述

       Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。简单点说，其主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接，权重等）去连接这些机器。

GitHub网址：Netflix/ribbon

SpringCloud 原有的客户端负载均衡方案 Ribbon 已经被废弃，取而代之的是LoadBalancer ,LoadBalancer 是Spring Cloud Commons 的一个子项目，点此查看官网。它属于上述的第二种方式，是将负载均衡的逻辑封装到客户端上，并且运行在客户端的进程里。
在Spring Cloud 构件微服务系统中，LoadBalancer 作为服务消费者的负载均衡器，有两种使用方式，一种是和RestTemplate 相结合，另一种是是和Feign 相结合。Feign 已经默认集成了 LoadBanlancer。

1、LB负载均衡（Load Balance）是什么

简单的说就是将用户的请求平摊的分配到多个服务器上，从而达到系统的HA(高可用)。常见的负载均衡的软件有Nginx、LVS和硬件F5等。

2、Ribbon与Nginx的区别？

• Nginx是服务器负载均衡，客户端所有请求都会交给nginx,然后由nginx实现转发请求，即负载均衡是由服务端实现的。即集中式LB。在服务端消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如nginx）,由该设施负责把访问请求通过某种策略转发至服务的提供方。

• Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到本地JVM中，从而在本地实现RPC远程服务调用技术。即进程内LB。将LB逻辑集成到消费方，消费方从服务服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

3、总结

Ribbon其实就是一个软负载均衡的客户端组件，他可以和其他所需请求的客户端结合使用，和eureka结合只是其中的一个实例。我们理解成负载均衡+RestTemplate调用即可。

二、Ribbon负载均衡

1、架构说明

Ribbon在工作时分成两步：

1. 先选择 EurekaServer ,它优先选择在同一个区域内负载较少的server。
2. 再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。

2、pom文件

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-netflix-ribbonartifactId>
dependency>

如果引入了spring-cloud-starter-netflix-eureka-client依赖，就不需要加spring-cloud-starter-ribbon引用，因为spring-cloud-starter-netflix-eureka-client自带了spring-cloud-starter-ribbon引用。
证明如下： 可以看到spring-cloud-starter-netflix-eureka-client 确实引入了Ribbon。

3、RestTemplate的使用

1、官网

RestTemplate官网

这里我们注意这两个方法的区别就行：

2、getForObject方法/getForEntity方法

getForObject ：返回对象为响应体中数据转化成的对象，基本上可以理解为Json。

getForEntity ：返回对象为ResponseEntity对象，包含了响应中的一些重要信息，比如响应头、响应状态码、响应体等。

3、GET请求方法

4、Post请求方法

5、其他方法

还有PUT、DELETE请求等自己去RestTemplate官网看，这里不赘述。

三、Ribbon核心组件IRule

1、IRule组件及自带策略

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

实现类及规则策略如图所示：

• com.netflix.loadbalancer.RoundRobinRule 轮询
• com.netflix.loadbalancer.RandomRule 随机
• com.netflix.loadbalancer.RetryRule
  先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务
• WeightedResponseTimeRule 对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择
• BestAvailableRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务
• AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例
• ZoneAvoidanceRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器

根据官网描述，这三个规则比较常用，分别是

具体策略内部可以参考这篇文章：netflix.loadbalance 的策略

2、自定义规则策略

注意细节配置：

官方文档（最新文档似乎已经没有了，从讲解视频中摘出来的）明确给出了警告：这个自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，达不到特殊化定制的目的了。

上面包下新建MySelfRult规则类

package com.atguigu.myrule;

import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RandomRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @auther zzyy
 * @create 2020-02-19 19:00
 */
@Configuration
public class MySelfRule
{
    @Bean
    public IRule myRule()
    {
        return new RandomRule();//定义为随机
    }
}

主启动类添加@RibbonClient

package com.atguigu.springcloud;

import com.atguigu.myrule.MySelfRule;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.ribbon.RibbonClient;

/**
 * @auther zzyy
 * @create 2020-01-28 16:18
 * 在启动该微服务的时候就能去加载我们的自定义Ribbon配置类，从而使配置生效，形如：
 */
@SpringBootApplication
@EnableEurekaClient
//@RibbonClient注解是重点 
@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration=MySelfRule.class)
public class OrderMain80
{
    public static void main(String[] args)
    {
        SpringApplication.run(OrderMain80.class,args);
    }
}

四、Ribbon默认策略：轮询

负载均衡算法：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
当总请求数位2时： 2 % 2 =0 对应下标位置为0 ，则获得服务地址为127.0.0.1:8002
当总请求数位3时： 3 % 2 =1 对应下标位置为1 ，则获得服务地址为127.0.0.1:8001
当总请求数位4时： 4 % 2 =0 对应下标位置为0 ，则获得服务地址为127.0.0.1:8002
如此类推…