[亲测]SpringCloud之均衡Ribbon

冷不防 2022-04-08 10:44 151阅读 0赞

# 一.负载均衡Ribbon #

什么是Ribbon：  
![在这里插入图片描述][20181210154458922.png]

接下来，我们就来使用Ribbon实现负载均衡。

## 1.1.启动两个服务实例 ##

首先我们启动两个user-service实例，一个8090，一个8092。

![在这里插入图片描述][20181210155418264.png]

Eureka监控面板：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70]

## 1.2.开启负载均衡 ##

因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。直接修改代码：

在RestTemplate的配置方法上添加`@LoadBalanced`注解：

@Bean
    @LoadBalanced
    public RestTemplate restTemplate() { 
        return new RestTemplate();
    }

修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：

@Service
    public class UserService { 
    
        @Autowired
        private RestTemplate restTemplate;
    
        @Autowired
        private DiscoveryClient discoveryClient;
    
        public List<User> queryUserByIds(List<Long> ids) { 
            List<User> users = new ArrayList<>();
            // 地址直接写服务名称即可
            String baseUrl = "http://user-service/user/";
            ids.forEach(id -> { 
                // 我们测试多次查询，
                users.add(this.restTemplate.getForObject(baseUrl + id, User.class));
                // 每次间隔500毫秒
                try { 
                    Thread.sleep(500);
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                }
            });
            return users;
        }
    }

访问页面，查看结果：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 1]

完美！

## 1.3.源码跟踪 ##

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是`LoadBalancerInterceptor`

我们进行源码跟踪：（Debug运行user-consumer-demo项目）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 2]

继续跟入execute方法：发现获取了8082端口的服务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 3]

再跟下一次，发现获取的是8081：

![在这里插入图片描述][20181210155326520.png]

## 1.4.负载均衡策略 ##

Ribbon默认的负载均衡策略是简单的轮询，我们可以测试一下：

编写测试类，在刚才的源码中我们看到拦截中是使用RibbonLoadBalanceClient来进行负载均衡的，其中有一个choose方法，是这样介绍的：

![在这里插入图片描述][20181210155316840.png]

现在这个就是负载均衡获取实例的方法。

我们对注入这个类的对象，然后对其测试：

@RunWith(SpringRunner.class)
    @SpringBootTest(classes = UserConsumerDemoApplication.class)
    public class LoadBalanceTest { 
    
        @Autowired
        RibbonLoadBalancerClient client;
    
        @Test
        public void test(){ 
            for (int i = 0; i < 100; i++) { 
                ServiceInstance instance = this.client.choose("user-service");
                System.out.println(instance.getHost() + ":" + instance.getPort());
            }
        }
    }

结果：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 4]

符合了我们的预期推测，确实是轮询方式。

我们是否可以修改负载均衡的策略呢？

继续跟踪源码，发现这么一段代码：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 5]

我们看看这个rule是谁：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 6]

这里的rule默认值是一个`RoundRobinRule`，看类的介绍：  
![在这里插入图片描述][20181210155225239.png]

这不就是轮询的意思嘛。

我们注意到，这个类其实是实现了接口IRule的，查看一下：  
![在这里插入图片描述][20190304093517597.png]

定义负载均衡的规则接口。

它有以下实现：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 7]

SpringBoot也帮我们提供了修改负载均衡规则的配置入口：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 8]

user-service:
      ribbon:
        NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

格式是：`{服务名称}.ribbon.NFLoadBalancerRuleClassName`，值就是IRule的实现类。

再次测试，发现结果变成了随机：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 9]

## 1.5.CAP ##

CAP原则：CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得

### 1.5.1 分区容错性 ###

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 10]

上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

### 1.5.2 一致性 ###

Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 11]

接下来，用户的读操作就会得到 v1。这就叫一致性。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 12]

问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有来得及发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 13]

为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 14]

这样的话，用户向 G2 发起读操作，也能得到 v1。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 15]

### 1.5.3 可用性 ###

Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

### 1.5.4 一致性和可用性的矛盾 ###

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

## 1.6.重试机制 ##

Eureka的服务治理强调了CAP原则中的AP，即可用性和分区容错。它与Zookeeper这一类强调CP（一致性，分区容错）的服务治理框架最大的区别在于：Eureka为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下它宁愿接收故障实例也不愿丢掉健康实例，正如我们上面所说的自我保护机制。

但是，此时如果我们调用了这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！这显然不是我们愿意看到的。

我们现在关闭一个user-service实例：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 16]

因为服务剔除的延迟，consumer并不会立即得到最新的服务列表，此时再次访问你会得到错误提示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 17]

但是此时，8081服务其实是正常的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力，当一次服务调用失败后，不会立即抛出异常，而是再次重试另一个服务。

只需要（user-consumer）简单配置即可实现Ribbon的重试：

spring:
      cloud:
        loadbalancer:
          retry:
            enabled: true # 开启Spring Cloud的重试功能
    user-service:
      ribbon:
        ConnectTimeout: 250 # Ribbon的连接超时时间
        ReadTimeout: 1000 # Ribbon的数据读取超时时间
        OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
        MaxAutoRetriesNextServer: 1 # 切换实例的重试次数
        MaxAutoRetries: 1 # 对当前实例的重试次数

根据如上配置，当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。切换次数取决于`MaxAutoRetriesNextServer`参数的值

引入spring-retry依赖

<dependency>
        <groupId>org.springframework.retry</groupId>
        <artifactId>spring-retry</artifactId>
    </dependency>

我们重启user-consumer-demo，测试，发现即使user-service2宕机，也能通过另一台服务实例获取到结果！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 18]

再给大家推荐本人的另外一篇文章：  
[SpringCloud之熔断器Hystrix+实践][SpringCloud_Hystrix]

[20181210154458922.png]: /images/20220406/2d718539826f45ba8ba9202abff2daa6.png
[20181210155418264.png]: /images/20220406/f090245d8cbf47a59dad5a579abce2a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70]: /images/20220406/5152b2d0f34a4fe0ba0846a3ed566aa8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 1]: /images/20220406/63ec8d3dfa674da690261c5b1c13b557.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 2]: /images/20220406/3313927b5efe4ce58fd64d32c831e821.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 3]: /images/20220406/c61681f6733c4fe3afd48c116c286152.png
[20181210155326520.png]: /images/20220406/68f36ac5241148dd96e396dcc2fb6fd1.png
[20181210155316840.png]: /images/20220406/64ec4b40af9e4297a16562b635879389.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 4]: /images/20220406/99b98ffe485b4b6199e9f2c95b856159.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 5]: /images/20220406/fbee2081c8d84e1f85849799c216888e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 6]: /images/20220406/a2b0f87bfbd4476eb4406f87eecaf50c.png
[20181210155225239.png]: /images/20220406/835d5ef3cff04097b4d60e8897aba401.png
[20190304093517597.png]: /images/20220406/51009dce05904d8d873668f7de516e6d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 7]: /images/20220406/326c5c7d45be4beea9a6d94f70e84d99.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 8]: /images/20220406/8d415b21d384404e81f67f511ae77a1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 9]: /images/20220406/edfbd23e369c442ebb238d5631b3294e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 10]: /images/20220406/1f249ffac474411c83d45bded8e2d45c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 11]: /images/20220406/6e8fc4bcf5e74d42b57917849c490a91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 12]: /images/20220406/3b082c2e705749229f66627778d8463b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 13]: /images/20220406/738825d65e2a431dab1e30eebc597977.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 14]: /images/20220406/92ca4e828f5849d4bdf50e44621b97a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 15]: /images/20220406/4431d2d0a64140d78f35736a77e8e7c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 16]: /images/20220406/43e55ebd2f524ec6885e34879b13919c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 17]: /images/20220406/17070e9b792341f3b5c66f2ef3d9ac2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNjUyNTA5_size_16_color_FFFFFF_t_70 18]: /images/20220406/fad1999ca96a4fbd81698ceade16795b.png
[SpringCloud_Hystrix]: https://blog.csdn.net/qq_43652509/article/details/84941739