【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题

旧城等待， 2024-02-17 12:43 13阅读 0赞

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

*   *  前言
     *  1.第一次尝试
     *   *  1.1服务被调用方更新
         *  1.2压测第一次尝试
         *  1.3 问题分析
         *  1.4 同步的不是最新列表
     *  2.第二次尝试
     *   *  2.1调用方过滤下线服务
         *  2.2压测第二次尝试
         *  2.3优化
     *  写到最后

### 前言 ###

在上文的基础上，通过压测的结果可以看出，使用DiscoveryManager下线服务之后进行压测是不会出现异常情况的，但唯一缺点就是下线服务的方式是取消注册与续约，之后并没有结束进程。也就**使得在调用api下线后的服务其实是还存在处理请求的能力的**。加之eureka三种级别的缓存同步需要一定时间，Eureka-Client从三级缓存中拉取的并不是实时的服务列表，进而使得Ribbon从Eureka-Client拉取的也不是实时的服务列表。**最终导致Ribbon负载均衡到了已经下线的服务实例，并且此时该实例（进程还未关闭）刚好能处理请求！就造成了下线了两个端口的服务实例，但是却还是被负载均衡到来处理请求！**  
按照这个思路，再去看这张图：  
![在这里插入图片描述][0037db88047a4eb08348f0ef03909568.png]  
**可不可以通过某种手段，当服务下线后去越过三级缓存直接去更新Ribbon缓存来缩短感知时间？**

我先说答案——是可以的

### 1.第一次尝试 ###

#### 1.1服务被调用方更新 ####

手动从Eureka-Client同步服务缓存信息：

在之前分析Ribbon源码的时候，说到了接口路径从http://服务名称/接口路径——>http://服务地址/接口路径，这个过程中调用方的请求被Ribbon拦截器拦截，并且通过负载均衡最终被改写成为了一个准确的服务地址，其中有一个非常重要的方法，getLoadBalancer(“服务名称”)  
![在这里插入图片描述][42fcdb423b4144f09b384ab7d865ee42.png]  
可见，他通过服务名称就拿到了该服务名称下的所有服务列表（allServerList）和可用服务列表(upServerList)，我们通过这个操作可不可以直接获取到最新一手的可用服务列表并且手动去set进Ribbon的可用服务列表缓存里，让他不再去每过30S同步？

**Tips:在我们的SpringCloud项目中有一个非常重要的组件`SpringClientFactory`是Spring Cloud中用于管理和获取客户端实例的工厂类。在这里面可以获取特定服务的负载均衡器（即`ILoadBalancer`）**

于是，便有了下面的操作，专门配置一个Bean去更新Ribbon缓存，每当调用服务下线接口去下线指定服务后就去自动同步Ribbon缓存，不用再Ribbon每隔30S去自动同步：

@Configuration
    @Slf4j
    public class ClearRibbonCache {
        
    
        public void clearRibbonCache(SpringClientFactory clientFactory, List<Integer> portParams) {
        
            // 获取指定服务的负载均衡器
            ILoadBalancer loadBalancer = clientFactory.getLoadBalancer("user-service");
            //在主动拉取可用列表，而不是走拦截器被动的方式——这里
            List<Server> reachableServers = loadBalancer.getReachableServers();//这里从客户端获取，会等待客户端同步三级缓存
            // 在某个时机需要清除Ribbon缓存
            ((BaseLoadBalancer) loadBalancer).setServersList(ableServers); // 清除Ribbon负载均衡器的缓存
        }
    }

于是在下线服务的接口中，就多了一步自动更新缓存的操作（不熟悉这个接口的可以去看上一篇文章）：

@GetMapping(value = "/service-down-list")
        public String offLine(@RequestParam List<Integer> portParams) {
        
            List<Integer> successList = new ArrayList<>();
            //得到服务信息
            List<InstanceInfo> instances = eurekaClient.getInstancesByVipAddress(appName, false);
            List<Integer> servicePorts = instances.stream().map(InstanceInfo::getPort).collect(Collectors.toList());
    
            //去服务列表里挨个下线
            OkHttpClient client = new OkHttpClient();
            log.error("开始时间：{}", System.currentTimeMillis());
            portParams.parallelStream().forEach(temp -> {
        
                if (servicePorts.contains(temp)) {
        
                    String url = "http://" + ipAddress + ":" + temp + "/control/service-down";
                    try {
        
                        Response response = client.newCall(new Request.Builder().url(url).build()).execute();
                        if (response.code() == 200) {
        
                            log.debug(temp + "服务下线成功");
                            successList.add(temp);
                        } else {
        
                            log.debug(temp + "服务下线失败");
                        }
                    } catch (IOException e) {
        
                        log.error(e.toString());
                    }
                }
            });
            log.debug("开始清除Ribbon缓存");
            clearRibbonCache.clearRibbonCache(clientFactory,portParams);
            return successList + "优雅下线成功";
        }

#### 1.2压测第一次尝试 ####

同样我们采用(100线程-3S)的JMeter压测模型去在调用服务下线接口后的15S,30S后压测，压测的接口即为一个普通的跨服务调用接口  
下线服务：  
![在这里插入图片描述][340a8ea9778d4e929c3b5c43637f0524.png]  
下线服务的15S：  
![在这里插入图片描述][082a8a79c7fc4dc3901a12ce809cb360.png]  
此时,观察控制台的日志输出可以发现，已经下线的两个服务实例还是被负载均衡到了（已下线但进程未退出），好像更新了缓存没有任何效果诶。  
![在这里插入图片描述][07a7348eb88346cea57076b17cc01747.png]  
下线服务的30S：  
![在这里插入图片描述][8fef8be4e7a344e3acb49cfd2d8c17ef.png]  
情况和15S如出一辙，并且请求负载均衡到了已下线但进程未退出的服务上。

下线服务的45S：  
![在这里插入图片描述][f9b3eb71b8f44022995d0658365f6832.png]  
![在这里插入图片描述][1b5d0fd9ef2d4044a1c7efe1ba43e92e.png]  
可见调用api下线服务直到45S左右，已经下线的服务才从每层缓存信息中完全清除，这个时间是非常致命的！

#### 1.3 问题分析 ####

在服务发布的场景就会出现这样一个业务问题：**开发调用api下线了某两个服务，通知运维可以去关闭这两个服务进程了，运维kill-9杀掉了这两个进程准备发布新服务。但此时客户端（用户）向服务端发送了请求，刚好该请求涉及跨服务调用，并且由于Ribbon同步Eureka-Client缓存，Eureka-Client同步Eurek-Server中的三级缓存需要一定时间，Ribbon缓存中的可用服务列表不是最新的，同步过来已下线（进程也被kill）的服务。最后请求受到Ribbon负载均衡落到了一个开发通过api下线的服务实例，分发到了一个运维kill-9的服务实例上，造成接口返回500、404、connect time out、connect refused…等错误，造成频繁告警。**

#### 1.4 同步的不是最新列表 ####

透过现象看本质：

为什么手动同步Ribbon缓存没有起到效果？是不是同步的内容出了问题？下面打断点开启debug，看看服务下线后到底拿到的是什么服务列表：  
![在这里插入图片描述][5b0253a8d2764498856c53fdb635e11f.png]  
意外发现，曾经天真以为可以拿到的实时的服务列表，到头来确实一场空，小丑竟是我自己。**明明8083,8084已经下线可为什么还在可用服务列表里，并且还set到了Ribbon缓存中**

原来啊，通过那个方法获取服务列表是从Eureka-client拿的，而这其实就是client去三级缓存那里同步的问题。 你说到为什么手动更新了缓存还是会有一段同步时间？ 那就是client从三级缓存同步来的服务列表还存在没下线的服务，所以导致手动更新到ribbon缓存里的列表也还存在没下线的服务。看到这里，**Eureka的“牺牲一致性保证高可用”是不是体现的淋漓尽致呢？**

这个一致性难道真的不能解决了吗？  
其实我还有一招  
同时结合Eureka-Ribbon架构的服务调用链路，其实在服务调用方去更新Ribbon缓存才能更好保证Ribbon负载均衡的服务列表是我所控制的  
**PS：（这里节省了一次尝试，即在服务被调用方去引入过滤操作，尝试过压测结果还是和以前一样，所以就忽略了。直接去服务调用方尝试）**  
![在这里插入图片描述][32d175d9cd25453a8c601618b3fe8934.png]

### 2.第二次尝试 ###

#### 2.1调用方过滤下线服务 ####

从拿到的服务列表中过滤下线服务，并且在调用方执行：  
在调用方执行？那被调用方下线的端口信息怎么让调用方知道呢，跨进程通信你选择MQ？还是Redis？这里我选择Redis  
在上述更新缓存的操作中稍作更改，把更新操作移动到服务调用方，并且引入Redis来作为通信支持（这里采用hash的数据结结构），那么被调用方现在所需要的就是更新下线的端口信息到redis中：  
![在这里插入图片描述][dbcdcd62307e4fa5a34038acdb146c02.png]

@GetMapping(value = "/service-down-list")
        public String offLine(@RequestParam List<Integer> portParams) {
        
            List<Integer> successList = new ArrayList<>();
            //得到服务信息
            List<InstanceInfo> instances = eurekaClient.getInstancesByVipAddress(appName, false);
            List<Integer> servicePorts = instances.stream().map(InstanceInfo::getPort).collect(Collectors.toList());
    
            //去服务列表里挨个下线
            OkHttpClient client = new OkHttpClient();
            log.error("开始时间：{}", System.currentTimeMillis());
            portParams.parallelStream().forEach(temp -> {
        
                if (servicePorts.contains(temp)) {
        
                    String url = "http://" + ipAddress + ":" + temp + "/control/service-down";
                    try {
        
                        Response response = client.newCall(new Request.Builder().url(url).build()).execute();
                        if (response.code() == 200) {
        
                            log.debug(temp + "服务下线成功");
                            successList.add(temp);
                        } else {
        
                            log.debug(temp + "服务下线失败");
                        }
                    } catch (IOException e) {
        
                        log.error(e.toString());
                    }
                }
            });
            // todo Redis通知
            stringRedisTemplate.opsForHash().put("port-map","down-ports",portParams.toString());
            return successList + "优雅下线成功";
        }

并且以前更新Ribbon可用服务列表操作也有稍微变化，即新增了一个手动过滤操作：

@Configuration
    @Slf4j
    public class ClearRibbonCache {
        
        /**
         * 削减
         */
        public static boolean cutDown(List<Integer> ports, Server index) {
        
            return ports.contains(index.getPort());
        }
    
       public void clearRibbonCache(SpringClientFactory clientFactory, String portParams) {
        
            // 获取指定服务的负载均衡器
            ILoadBalancer loadBalancer = clientFactory.getLoadBalancer("user-service");
            //在主动拉取可用列表，而不是走拦截器被动的方式——这里
            List<Server> reachableServers = loadBalancer.getReachableServers();//这里从客户端获取，会等待客户端同步三级缓存
            //过滤掉已经下线的端口，符合条件端口的服务过滤出来
            List<Integer> portList = StringChange.stringToList(portParams);
            List<Server> ableServers = reachableServers.stream().filter(temp -> !cutDown(portList, temp)).collect(Collectors.toList());
            log.debug("可用服务列表：{}", ableServers);
            // 在某个时机需要清除Ribbon缓存
            ((BaseLoadBalancer) loadBalancer).setServersList(ableServers); // 清除Ribbon负载均衡器的缓存
        }
    }

在服务调用方，每次进行跨服务调用前都去从Redis中获取出实时下线的端口并且去更新Ribbon缓存：  
![在这里插入图片描述][6b30712dd9784035aab12c0afc1c66ea.png]

#### 2.2压测第二次尝试 ####

当下线完服务，立即进行压测，可以看到所有的跨服务调用请求都落在了还未下线的实例上，并且已下线但进程未关闭的服务实例没有再处理请求：  
![在这里插入图片描述][a0374dc25f1442bbb461b5f0c4b2daf1.png]  
![在这里插入图片描述][3c474be209cc4fda936bdeb9b3eb7646.png]  
并且15S，30S的时间节点上，也没有任何异常：  
![在这里插入图片描述][d229291142464f03910f2d7874139c78.png]  
可见通过此种方式来主动更新Ribbon可用服务列表确实可行，**特别是在运维那边发布新服务的一个特定场景下可以解决Eureka感知下线服务迟钝从而影响Ribbon负载到不可用的服务实例上这一问题。**

#### 2.3优化 ####

其实，如果每次在新发布服务的场景下告警的接口都可以精确定位到，并且数量不多的情况我觉得在那几个业务接口里去手动同步一下Ribbon缓存没有什么大问题也可以解决问题。但是如果每次告警的接口有很多，并且不固定那上述的方法就显得有些许臃肿。而且这也是一种入侵式编程，我其实是不推荐的！  
**说起入侵式编程不禁就会想到无入侵式编程——Aop**  
直接把出现错误的模块作为切面，并把更新Ribbon的操作作为切入点写到表达式里，就完美做到了不改变已有业务而实现了更新功能，就像这样：

@Aspect
    @Component
    @Slf4j
    public class RequestAspect {
        
    
        @Resource
        SpringClientFactory springClientFactory;
        @Resource
        ClearRibbonCacheBean clearRibbonCacheBean;
        @Resource
        private StringRedisTemplate stringRedisTemplate;
    
        @Before(value = "execution(* com.yu7.order.web.*.*(..))")
        public void refreshBefore(JoinPoint joinPoint) {
        
            String ports = (String) stringRedisTemplate.opsForHash().get("port-map", "down-ports");
            log.debug("从Redis获取的端口为：{}", ports);
            //下线了才会有值，没有值说明没下线不用更新
            if (ObjectUtils.isNotEmpty(ports)) {
        
                clearRibbonCacheBean.clearRibbonCache(springClientFactory, ports);
            }
        }
    }

进行压测，结果和预期完全一致~

### 写到最后 ###

我想说：其实我的方案只是相当于提出了一个大体框架和构想，粗略地实现了基于Eureka的微服务架构中服务状态感知的问题，当业务里存在不止一种调用关系，下线服务类型不一致，服务断断续续下线会造成value值丢失…方案就需要进一步细化（还存在硬编码问题，嘻嘻），并且为了切面不影响业务还应该给存到Redis的数据加上TTL等其他保险措施，总而言之也欢迎大家提出建议，共同精进，一起解决这一难题！

[0037db88047a4eb08348f0ef03909568.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/6406bc39ea6c4889acb2537593784943.png
[42fcdb423b4144f09b384ab7d865ee42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/2a2157f13a864c7d97f1c8f823460878.png
[340a8ea9778d4e929c3b5c43637f0524.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/9e8174d5521943b79b05a03ed8ee5508.png
[082a8a79c7fc4dc3901a12ce809cb360.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/9468991210cb4648a428537f530c4417.png
[07a7348eb88346cea57076b17cc01747.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/49dde1c0461c493d978f19728304e188.png
[8fef8be4e7a344e3acb49cfd2d8c17ef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/eff68969ade74f2bb6d3bee59447c5f2.png
[f9b3eb71b8f44022995d0658365f6832.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/bb6f1918f31f4592a08e461fd862fe6e.png
[1b5d0fd9ef2d4044a1c7efe1ba43e92e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/a14d35d5e22f4414b9a320cfa253c739.png
[5b0253a8d2764498856c53fdb635e11f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/0f5ffebd0ab4475a86ea02a3473a49a0.png
[32d175d9cd25453a8c601618b3fe8934.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/96ddc010eb8f4e808cbd081dca2bc019.png
[dbcdcd62307e4fa5a34038acdb146c02.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/38b003d6a1674e7e9c0c81b8405c02cb.png
[6b30712dd9784035aab12c0afc1c66ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/e7acfdb48f9f4719ba5fb17bf5a1641e.png
[a0374dc25f1442bbb461b5f0c4b2daf1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/4d11886f4322489c8a8f86ed2a5a167f.png
[3c474be209cc4fda936bdeb9b3eb7646.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/058d99e8e9c34161887db735d2977fc2.png
[d229291142464f03910f2d7874139c78.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/a310de7f3a1b482fb537c6a0a33b07ee.png