Spring Cloud_Day03_Ribbon负载均衡

一、认识Ribbon

1.1 什么是Ribbon

Ribbon 是一个基于 HTTP 和 TCP 的客服端负载均衡工具，它是基于 Netflix Ribbon 实现的。它不像 Spring Cloud 服务注册中心、配置中心、API 网关那样独立部署，但是它几乎存在于每个 Spring Cloud 微服务中。包括 Feign 提供的声明式服务调用也是基于该 Ribbon 实现的。

1.2 为什么使用Ribbon

Ribbon 提供了一套微服务的负载均衡解决方案。目前业界主流的负载均衡方案可分成两类：

序号	类别
1	集中式负载均衡（服务器负载均衡），即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件，如 F5，也可以是软件，如 nginx)，由该设施负责把访问请求通过某种策略转发至 provider；
2	进程内负载均衡（客户端负载均衡），将负载均衡逻辑集成到 consumer，consumer 从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider。Ribbon 属于后者，它只是一个类库，集成于 consumer 进程，consumer 通过它来获取 provider 的地址。

二、Ribbon入门案例

我们接下来的所有操作均是在**Eureka** day01-day02 完成的工程上进行操作.

2.1 添加服务提供者

既然我们要做服务的负载均衡，那肯定需要有很多服务，一个服务再怎么负载均衡还是他自己，因此，我们需要在原工程的基础上在添加一个服务提供者，配置基本和service-provider差不多，只不过端口不一样而已，接下来会给出具体不一样的配置。

2.1.1 右键New Module

2.1.2 选择SpringBoot项目

2.1.3 修改项目名称

2.1.4 添加依赖

2.1.5 修改yml配置文件

server:
  port: 8002

spring:
  application:
    #该名称在集群模式下应该保持一致
    name: service-provider

eureka:
  instance:
    #是否使用 ip 地址注册
    prefer-ip-address: true
    #该实例注册到服务中心的唯一ID
    instance-id: ${spring.cloud.client.ip-address}:${server.port}
  client:
    #设置服务注册中心地址
    service-url:
      defaultZone: http://localhost:7001/eureka/,http://localhost:7002/eureka/

2.1.6 分别修改两个service-provider的Controller

都加入一个新的方法：代码如下：

在端口为 8001 中添加：

@RequestMapping("/provider/item/getById")
    public String getById(@RequestParam("id") Integer id){
    return "8001 getById ...";
}

在端口为 8002 中添加：

@RequestMapping("/provider/item/getById")
    public String getById(@RequestParam("id") Integer id){
    return "8002 getById ...";
}

2.1.7 启动注册中心，服务提供者

1. 启动eureka-server7001
2. 启动eureka-server7002
3. 启动service-provider8001
4. 启动service-provider8002

2.2 修改服务消费者

2.2.1 方式一：LoadBalancerClient

（1）修改service-consumer的ItemController控制器代码，在里边新增以下代码

// Ribbon 负载均衡器
// import org.springframework.cloud.client.loadbalancer.LoadBalancerClient;
    @Autowired
    private LoadBalancerClient loadBalancerClient;

    @RequestMapping("/consumer/item/getById")
    public String findByPid(@RequestParam("id") Integer id) {
        //从注册中心获取一个SERVICE-PROVIDER服务的实例对象
        ServiceInstance si = loadBalancerClient.choose("SERVICE-PROVIDER");
        if (si == null) {
            return null;
        }

        String getByIdUrl = si.getUri() + "/provider/item/getById" + "?id=" + id;
        String product = restTemplate.getForObject(getByIdUrl, String.class);
        return product;
        //这里只是做模拟返回了一个字符串，当然你也可以返回一个商品对象，这取决于你
    }

（2）启动消费者 请求
http://localhost:9001/consumer/item/getById?id=1
重复刷新，会发现每次会在8001-8002 来回调用

2.2.2 方式二：@LoadBalanced

（1）修改service-consumer的主启动类代码，修改后代码如下：

（2）在ItemController控制器代码中添加如下方法

@RequestMapping("/consumer/item/getById2")
    public String findByPid2(@RequestParam("id") Integer id) {
        String findByPidUrl = "http://SERVICE-PROVIDER/provider/item/getById" + "?id=" + id;
        String product = restTemplate.getForObject(findByPidUrl, String.class);
        System.out.println(product);
        return product;
    }

（3）重启消费者，进行访问测试

http://localhost:9001/consumer/item/getById2?id=1
效果会和方式一效果相同

三、Ribbon负载均衡策略

3.1 轮询策略（默认）

实现原理：

• 轮询策略表示每次都顺序取下一个 provider，比如一共有 5 个 provider，第 1 次取第 1 个，第 2 次取第 2 个，第 3 次取第 3 个，以此类推。

3.2 权重轮询策略

实现原理：

• 根据每个 provider 的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
• 原理：一开始为轮询策略，并开启一个计时器，每 30 秒收集一次每个 provider 的平均响应时间，当信息足够时，给每个 provider 附上一个权重，并按权重随机选择 provider，高权越重的 provider 会被高概率选中。

3.3 随机策略

实现原理：

• 从 provider 列表中随机选择一个。

3.4 最少并发数策略

实现原理：

• 选择正在请求中的并发数最小的 provider，除非这个 provider 在熔断中。

3.5、重试策略

实现原理：

• 其实就是轮询策略的增强版，轮询策略服务不可用时不做处理，重试策略服务不可用时会重新尝试集群中的其他节点。

3.6、可用性敏感策略

实现原理： 过滤性能差的 provider

• 第一种：过滤掉在 Eureka 中处于一直连接失败的 provider。
• 第二种：过滤掉高并发（繁忙）的 provider。

3.7、区域敏感性策略

实现原理：

• 以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的 provider。
• 如果这个 ip 区域内有一个或多个实例不可达或响应变慢，都会降低该 ip 区域内其他 ip 被选中的权重。