【SpringCloud】Eureka基于Ribbon负载均衡的调用链路流程分析

缺乏、安全感 2024-02-17 08:20 29阅读 0赞

#### 文章目录 ####

*   *  前言
     *  1.调用形式
     *  2.LoadBalancerInterceptor
     *  3.负载均衡流程分析
     *   *  3.1 调用流程图
         *  3.2 intercept（）方法
         *  3.3 execute（）方法
         *  3.4 getServer()方法
         *  3.4 子类的chooseServer（）方法
         *  3.5 getLoadBalancerStats().getAvailableZones().size() <= 1
         *  3.6 父类的chooseServer()方法
         *  3.7 IRule接口下的实例
         *  3.8 最终的choose()方法—return server
         *  3.9 choose()方法内部分析
     *  4. 彩蛋

### 前言 ###

微服务间相互调用的基础上，服务间的调用更多是以调用某多实例服务下的某个实例的形式。而这就需要用到负载均衡技术。对于开发者而言，只要通过@LoadBalance注解就开启了负载均衡。如此简单的操作底层究竟是什么样的，我想你也很想知道。

### 1.调用形式 ###

在《[SpringCloud集成Eureka并实现负载均衡][SpringCloud_Eureka]》的基础之上，我们可以进行一个小小的实验，debug运行程序，通过postman发起一个请求，A服务会去远程调用B服务，debug发现发送的url为：http://user-service/user/1，毫无疑问的是，这就是A调用B的途径  
![在这里插入图片描述][ceee080b80b54ac1b34185b0507e8e85.png]  
同样地，拿到这个url我们去postman里发送请求：  
![在这里插入图片描述][c0bb562bb0d943b88246e22e3d74f59c.png]  
发现请求无法发送出去，路径出了问题。观察路径中的参数user-service发现他是B服务的服务名称，那为什么在A服务里向B服务发送“服务名称-接口路径-参数”形式的请求就能够正常响应？  
结合集成负载均衡的过程，这一定是Ribbon在发挥作用

### 2.LoadBalancerInterceptor ###

负载均衡的前提不是传递一个具体的url，肯定是Ribbon做了某种解析，通过服务名称得到了服务下的实例列表，从而拉取Eureka-Server中的服务注册表来将请求映射到指定的某个实例上。  
结合曾经前后端分离的web开发经验，后端经常会在拦截器中拦截前端发来的请求来对请求做一些操作，比如校验、拼接、鉴权…调用方发送请求和接收方收到的请求并不一致，这其中会不会也是有一个类似于拦截器的东西拦截了请求，并且转换了请求呢？  
**答案是必然的，那是谁——LoadBalancerInterceptor**  
![在这里插入图片描述][68a97e8041644c12b24d250ef2533092.png]  
可以看到的是，他实现了ClientHttpRequestInterceptor接口，具体用法细节直接去看接口中声明的方法  
直观的看出接口中声明了一个intercept()方法并且接受了HttpRequest参数来拦截了客户端的http请求，并且修改的请求体！这么一看URL更改的谜底就在此处揭晓了，那么方法底层具体是怎么实现的呢：

### 3.负载均衡流程分析 ###

#### 3.1 调用流程图 ####

Debug源码之前先来看一下源码中的调用链路总体流程图（手图）：  
![在这里插入图片描述][f2cace40b21b489eb4b4365360a6183c.png]  
概括来看则是：拦截请求—读取服务—拉取服务列表—选择规则—返回服务实例

#### 3.2 intercept（）方法 ####

下面我们开始Debug:  
1.当发送请求使得服务间发生调用关系，调用请求会先传递到**拦截器中的intercept方法**，可以看到的是目前还和发送是保持一致  
![在这里插入图片描述][3625b241a170479e95d8861ee7d3e913.png]  
2.继续向下执行，开始解析请求，拿到了请求中的URI——通过getHost()方法拿到了主机地址（服务的名称）  
![在这里插入图片描述][96916baf3ca94b6facf7d67141607146.png]

#### 3.3 execute（）方法 ####

3.Ribbon开始做负载均衡处理  
![在这里插入图片描述][df4d154d4fe74292a65ca598cb628b8f.png]  
4.两次步入之后进入到execute（）方法内部，发现传递进来的服务名称作为服务Id进入到了getLoadBalance（）方法，并且得到了一个**ILoadbalance接口对象**，而在该对象中封装了很多的信息：  
![在这里插入图片描述][c9c0b9b191854636bced8272406519c4.png]  
这里记住服务实例id的值：**host.docker.internal:8084**，这就是Eureka客户端接收到的实例信息

#### 3.4 getServer()方法 ####

5.接口对象作为参数传递到了getServer()方法,得到了一个server对象进入到方法内部。发现与此同时传递了一个Object类型的对象用于指定服务器的规则或条件，不过到目前为止，这个参数一直都是null作为传递，即loadBalancer.chooseServer（）方法采用的是‘default’的方式进行选择  
![在这里插入图片描述][39e4c94337bb49e3a42b7f7bf5d547ea.png]

#### 3.4 子类的chooseServer（）方法 ####

6.再次步入到chooseServer（）方法，发现是在一个名为BaseLoadBalancer类（这个类是负载均衡器的具体实现后面会具体分析）下重写的父类方法  
此时：可以判断的是getLoadBalancerStats().getAvailableZones().size() <= 1为TRUE  
![在这里插入图片描述][91880df12e0f4ed5b7a695f8b92db76f.png]

#### 3.5 getLoadBalancerStats().getAvailableZones().size() <= 1 ####

对于表达式：getLoadBalancerStats().getAvailableZones().size() <= 1进行分析  
发现在BaseLoadBalancer类中通过继承抽象类AbstractLoadBalancer并重写getLoadBalancerStats()抽象方法，获取到了一个**loadbalancer统计信息集合LoadBalancerStats**  
![在这里插入图片描述][95f63ed5623f40418ce422304a1e1794.png]  
![在这里插入图片描述][fa1b530bda994c51a97a1107f2347a25.png]  
而封装在LoadBalancerStats中的信息里有一个ConcurrentHashMap类型的集合属性，即

volatile Map<String, List<? extends Server>> upServerListZoneMap = new ConcurrentHashMap<String, List<? extends Server>>();

用于**存储可用的服务列表**，这个集合中的每个条目都代表一个区域，键是区域名称，值是该区域下可用服务器的列表。  
![在这里插入图片描述][65f9af7d32294a49a68ee071adc0516f.png]  
后续的.getAvailableZones()方法则是获取这一属性值中所有的键，也就是可用的服务区域，并作为Set集合返回来进行判断  
![在这里插入图片描述][1244b081e6484a97ac996824bf422b3a.png]  
很显然，这里进一步论证getLoadBalancerStats().getAvailableZones().size() <= 1是为true的，后续就会去调用父类的chooseServer()方法

#### 3.6 父类的chooseServer()方法 ####

7.步入到父类的chooseServer()方法中，发现最后返回了一个Server类型的对象，这肯定就是具体的服务实例信息了。  
![在这里插入图片描述][1208c3193d76439b82a967355b110457.png]

#### 3.7 IRule接口下的实例 ####

去追踪rule变量，发现是一个IRule接口的实例，即为负载均衡提供规则的接口  
![在这里插入图片描述][7a93f2642f6c4663a95032370f49005f.png]  
并且此接口下有大量的规则实现，而**默认的规则方式则为轮询调度**：  
![在这里插入图片描述][f349cee6a8ac46a3b0ad185e9016991d.png]  
可是看到上图在debug时，rule变量右侧灰色显示的是`rule：RandomRule@12045`这是因为我通过配置IRule类型的Bean指定了负载均衡的规则：

@Bean
        public IRule randomRule() {
        
            return new RandomRule();
        }

只要把他注释掉，程序就会继续去采用默认的规则即**RoundRobinRule**

#### 3.8 最终的choose()方法—return server ####

8.了解了IRule接口的rule实例，再去看他最终调用的choose()方法。同样地步入进去，由于是默认规则，则按照流程进入到了RoundRobinRule规则实现中的choose方法（其实IRule接口下的每一个规则实现类都有choose方法）  
![在这里插入图片描述][a058391d35d1467587f24c8c56e91b20.png]  
实现了`ILoadBalancer`接口的负载均衡器对象作为参数传递到了方法中，与此同时key为default。开始为随机选择预热。

#### 3.9 choose()方法内部分析 ####

9.进入到while循环中，不断选择服务器，直到找到一个可用的服务器。随后会**判断线程是否中断**，如果中断了，则直接返回null。  
![在这里插入图片描述][973e3bc2509e49a99f502faaa9a16b3e.png]  
这样的情况出现频率还是很高，由此可见，这个小设计会减少很多不必要计算，提升了程序运行的效率。  
而后这是分别获取两个服务列表![在这里插入图片描述][3679c847eb2948878f7ad8c4adb1c581.png]  
从列表中选择一个  
![在这里插入图片描述][4a2a9d3cdfa34751a30abeeb101eb2c0.png]  
兜底操作，对选择的做判断![在这里插入图片描述][d013078e974d4cce8b130f5d15423861.png]  
最后成功返回Server实例给chooseServer（）方法，服务发起者发送http：//user-service/user请求通过Ribbon最后轮询到了localhost:8084服务实例上

### 4. 彩蛋 ###

现在有很多公司都在用Nacos替换Eureka，因为感知服务列表的变化不够敏感，感知下线服务太过迟钝，就像下面这种情况：  
![在这里插入图片描述][fca52618faaa40d8bbf583222d371674.png]  
**服务实例已经下线，时间大约过了一分钟，却还是把下线的服务加载到了可用服务列表里（upList）,其实这并不怪Ribbon，都是Eureka的错**  
针对这种情况我们留个彩蛋,下次再来talk about~

[SpringCloud_Eureka]: https://blog.csdn.net/weixin_57535055/article/details/134391818?spm=1001.2014.3001.5501
[ceee080b80b54ac1b34185b0507e8e85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/09a82555978a4ef488a0ab1b1e153273.png
[c0bb562bb0d943b88246e22e3d74f59c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/6aab23c0b85f42e098635702ab450494.png
[68a97e8041644c12b24d250ef2533092.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/44af8ee6f8884393bd9aedd561e960d9.png
[f2cace40b21b489eb4b4365360a6183c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/af1f887ef5c545bb8103ac8d18881cc8.png
[3625b241a170479e95d8861ee7d3e913.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/31eff8738b3042e8b5091d2e4a17b691.png
[96916baf3ca94b6facf7d67141607146.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/72dea6cf6579474c8507de38e029866e.png
[df4d154d4fe74292a65ca598cb628b8f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/6d1da83a09e6403e81954b750c4ca6cd.png
[c9c0b9b191854636bced8272406519c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/b73c6e4bafb84d34a321af4bbdbb374f.png
[39e4c94337bb49e3a42b7f7bf5d547ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/2d86cfd551d64dbda97d1a2b5f46d901.png
[91880df12e0f4ed5b7a695f8b92db76f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/77e05433a25b44a0bf567792e0556cbe.png
[95f63ed5623f40418ce422304a1e1794.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/f46127d0c1c6470fb2a8098a3437fddb.png
[fa1b530bda994c51a97a1107f2347a25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/865fae3fb29d4f76bdff5beb657bfc03.png
[65f9af7d32294a49a68ee071adc0516f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/4c7cb00120c9453fa637d6c9040d49f2.png
[1244b081e6484a97ac996824bf422b3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/8ca634d655e2450d8139ab7a9afa9874.png
[1208c3193d76439b82a967355b110457.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/d986a84f5e9d4c69a29dfde20f914594.png
[7a93f2642f6c4663a95032370f49005f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/f2baa24e58534c8583c7906b69101b8f.png
[f349cee6a8ac46a3b0ad185e9016991d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/ab9b3ebb58c244dd98d359c93186b316.png
[a058391d35d1467587f24c8c56e91b20.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/2718ee2b6d694a7cba79cd5c4518fe93.png
[973e3bc2509e49a99f502faaa9a16b3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/92e1f35781e048fda4d60c14d3c851dd.png
[3679c847eb2948878f7ad8c4adb1c581.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/91e0abc5ce3c4a7f89e1a66a076405c6.png
[4a2a9d3cdfa34751a30abeeb101eb2c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/5bccccb523144474a21f99cc0243ab35.png
[d013078e974d4cce8b130f5d15423861.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/cd47bc8fc4404e4fa7fa64520d308128.png
[fca52618faaa40d8bbf583222d371674.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/6cab69d1110b40a1adc37e3bdd365411.png