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

这篇具有很好参考价值的文章主要介绍了【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

在上文的基础上,通过压测的结果可以看出,使用DiscoveryManager下线服务之后进行压测是不会出现异常情况的,但唯一缺点就是下线服务的方式是取消注册与续约,之后并没有结束进程。也就使得在调用api下线后的服务其实是还存在处理请求的能力的。加之eureka三种级别的缓存同步需要一定时间,Eureka-Client从三级缓存中拉取的并不是实时的服务列表,进而使得Ribbon从Eureka-Client拉取的也不是实时的服务列表。最终导致Ribbon负载均衡到了已经下线的服务实例,并且此时该实例(进程还未关闭)刚好能处理请求!就造成了下线了两个端口的服务实例,但是却还是被负载均衡到来处理请求!
按照这个思路,再去看这张图:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
可不可以通过某种手段,当服务下线后去越过三级缓存直接去更新Ribbon缓存来缩短感知时间?

我先说答案——是可以的

1.第一次尝试

1.1服务被调用方更新

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

在之前分析Ribbon源码的时候,说到了接口路径从http://服务名称/接口路径——>http://服务地址/接口路径,这个过程中调用方的请求被Ribbon拦截器拦截,并且通过负载均衡最终被改写成为了一个准确的服务地址,其中有一个非常重要的方法,getLoadBalancer(“服务名称”)
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
可见,他通过服务名称就拿到了该服务名称下的所有服务列表(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后压测,压测的接口即为一个普通的跨服务调用接口
下线服务:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
下线服务的15S:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
此时,观察控制台的日志输出可以发现,已经下线的服务实例还是被负载均衡到了(已下线但进程未退出),好像更新了缓存没有任何效果诶。
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
下线服务的30S:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
情况和15S如出一辙,并且请求负载均衡到了已下线但进程未退出的服务上。

下线服务的45S:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
可见调用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,看看服务下线后到底拿到的是什么服务列表:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
意外发现,曾经天真以为可以拿到的实时的服务列表,到头来确实一场空,小丑竟是我自己。明明8083已经下线可为什么还在可用服务列表里,并且还set到了Ribbon缓存中

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

这个一致性难道真的不能解决了吗?
其实我还有一招
同时结合Eureka-Ribbon架构的服务调用链路,其实在服务调用方去更新Ribbon缓存才能更好保证Ribbon负载均衡的服务列表是我所控制的!
PS:(这里节省了一次尝试,即在服务被调用方去引入过滤操作,尝试过压测结果还是和以前一样,所以就忽略了。直接去服务调用方尝试)
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka

图析:
关于Eureka-Client,Eureka-Server,Ribbon三者间的关系补充:Eureka-Client会定时向Eureka-Server发送心跳注册续约,并且会定时向Eureka-Server拉取服务列表(可以通过registry-fetch-interval-seconds属性来配置时间间隔),与此同时Ribbon也会定时同步Eureka-Client那里来的服务信息存储到Ribbon缓存中。也就是说,Ribbon的服务列表是从Eureka-Server间接获取的。

2.第二次尝试

2.1调用方过滤下线服务

从拿到的服务列表中过滤下线服务,并且在调用方执行:
在调用方执行?那被调用方下线的端口信息怎么让调用方知道呢,跨进程通信你选择MQ?还是Redis?这里我选择Redis
在上述更新缓存的操作中稍作更改,把更新操作移动到服务调用方,并且引入Redis来作为通信支持(这里采用hash的数据结结构),那么被调用方现在所需要的就是更新下线的端口信息到redis中:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka

    @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缓存:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka

2.2压测第二次尝试

当下线完服务,立即进行压测,可以看到所有的跨服务调用请求都落在了还未下线的实例上,并且已下线但进程未关闭的服务实例没有再处理请求,并且测试结果完全没有异常:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
并且15S,30S的时间节点上,也没有任何异常:
【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题,SpringCloud体系,Eureka,缓存,架构,redis,ribbon,eureka
可见通过此种方式来主动更新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等其他保险措施,总而言之也欢迎大家提出建议,共同精进,一起解决这一难题!文章来源地址https://www.toymoban.com/news/detail-752030.html

到了这里,关于【SpringCloud】通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【业务功能篇87】微服务-springcloud-本地缓存-redis-分布式缓存-缓存穿透-雪崩-击穿

      缓存的作用是减低对数据源的访问频率。从而提高我们系统的性能。 缓存的流程图 2.1 本地缓存   其实就是把缓存数据存储在内存中(Map String,Object ).在单体架构中肯定没有问题。 单体架构下的缓存处理 2.2 分布式缓存   在分布式环境下,我们原来的本地缓存就不是

    2024年02月10日
    浏览(54)
  • Redis缓存问题与缓存更新机制

    目录 ​编辑  一、缓存问题  1.1 缓存穿透  1.1.1 问题来源  1.1.2 解决方案  1.1.2.1 缓存空对象  1.1.2.2 使用布隆过滤器  1.2 缓存击穿  1.2.1 问题来源  1.2.2 解决方案  1.2.2.1 设置热点数据永远不过期  1.2.2.2 新增后台定时更新缓存线程(逻辑不过期)  1.2.2.3 使用分布式互斥锁

    2024年02月12日
    浏览(31)
  • Redis缓存更新策略以及常见缓存问题

    缓存就是数据交换的缓冲区(Cache),是存储数据的临时地方,一般读写性能较好,常见缓存: Web应用中缓存有什么作用呢? 降低后端负载 提高读写效率,降低响应时间 缓存的成本: 数据的一致性成本 代码维护成本 运维成本 缓存作用模型: 给一段Redis作为缓存的具体案例代

    2024年02月16日
    浏览(47)
  • Redis实战(3)——缓存模型与缓存更新策略

    1 什么是缓存? 缓存 就是数据交换的缓冲区, 是存贮数据的临时区,一般读写性能较高 textcolor{red}{是存贮数据的临时区,一般读写性能较高} 是存贮数据的临时区,一般读写性能较高 。缓存可在多个场景下使用 以一次 w e b 请求为例,演示不同阶段的缓存作用 textcolor{blue}

    2024年02月15日
    浏览(41)
  • redis的缓存更新策略

    目录 三种缓存更新策略 业务场景:  主动更新的三种实现 操作缓存和数据库时有三个问题   1.删除缓存还是更新缓存?   2.如何保证缓存与数据库的操作的同时成功或失败?   3.先操作缓存还是先操作数据库? 缓存更新策略的最佳实践方案: 内存淘汰(Eviction)策略:Re

    2024年02月14日
    浏览(41)
  • Redis缓存更新策略

    缓存更新是redis为了节约内存而设计出来的一个东西,主要是因为内存数据宝贵,当我们向redis插入太多数据,此时就可能会导致缓存中的数据过多,所以redis会对部分数据进行更新,或者把他叫为淘汰更合适。 内存淘汰 :redis自动进行,当redis内存达到咱们设定的max-memery的时

    2023年04月26日
    浏览(36)
  • redis 三种缓存更新策略

    今天聊聊redis 三种缓存更新策略分别是: Cache Aside(旁路缓存)策略; Read/Write Through(读穿 / 写穿)策略; Write Back(写回)策略; 其中 Cache Aside策略是redis和Mysql使用的更新策略,另外两种策略主要使用在计算机系统上。 Cache Aside(旁路缓存)策略是最常用的策略,应用程

    2024年02月15日
    浏览(38)
  • Redis实战案例4-缓存更新策略

    缓存中的数据一致性问题(数据库更新数据,而Redis存的是旧数据) 内存淘汰策略:当内存很充足时,很长时间无法淘汰数据,所以很难控制淘汰,一致性差; 超时剔除:取决于TTL大小,可以达到控制目的,但是在TTL时间内也可能存在数据库更新从而Redis中变成旧数据; 主动

    2024年02月10日
    浏览(41)
  • Redis篇:缓存更新策略最佳实践

            缓存更新是redis为了节约内存而设计出来的一个东西,主要是因为内存数据宝贵,当我们向redis插入太多数据,此时就可能会导致 缓存中的数据过多 ,所以redis会对部分数据进行更新,或者把他叫为淘汰更合适,一般有以下三种淘汰策略。 内存淘汰: redis自动进行

    2024年04月24日
    浏览(34)
  • Springcloud Alibaba使用Canal将Mysql数据实时同步到Redis保证缓存的一致性

    目录   1. 背景 2. Windows系统安装canal 3.Mysql准备工作 4. 公共依赖包 5. Redis缓存设计 6. mall-canal-service   canal [kə\\\'næl] ,译意为水道/管道/沟渠,主要用途是 基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费 。其诞生的背景是早期阿里巴巴因为杭州和美国双机房部署,存

    2024年02月03日
    浏览(54)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包