Spring-Cloud开发人员如何解决服务冲突和实例乱窜

5次阅读

共计 2544 个字符,预计需要花费 7 分钟才能阅读完成。

一、背景

在我们开发微服务架构系统时,虽然说每个微服务都是孤立的可以单独开发,但实际上并非如此,要调试和测试你的服务不仅需要您的微服务启动和运行,还需要它的上下文服务、依赖的基础服务等都要运行;但如果你的系统服务数和依赖比较多呢,那就是一个比较棘手的问题!有没有办法能提高开发效率呢?

如上图所示,我们能不能用 服务器把所有的服务都部署 起来,然后开发 只在本地运行自己所负责开发的服务,因为需要依赖其他服务所以本地启动的服务也需要注册到公共的注册中心里;

例子中 业务服务 B 有 3 台实例注册到注册中心里
分别是:服务上的、开发 A 与开发 B 自己本机启动的

但是这样做又会出现新的问题:服务会冲突乱窜 ,意思就是 开发 A 在 debug 自己的 业务服务 B 服务的时候可能请求会跳转到其他人的实例上(服务器、开发 B)

 

二、解决思路

解决这个服务乱窜问题有一个比较优雅的方式就是 自定义负载均衡规则,主要实现以下目标:

  1. 普通用户 访问服务器上的页面时,请求的所有路由只调用 服务器上的实例
  2. 开发 A 访问时,请求的所有路由优先调用 开发 A 本机启动的实例 ,如果没有则调用 服务器上的实例
  3. 开发 B 访问时同上,请求的所有路由优先调用 开发 B 本机启动的实例 ,如果没有则调用 服务器上的实例

 

三、具体实现

要实现上面的目标有两个比较关键的问题需要解决

  1. 区分 不同用户的服务实例
  2. 实现 自定义负载均衡规则

3.1. 区分 不同用户的服务实例

直接使用注册中心的元数据 (metadata) 来区分就可以了

主流的注册中心都带有元数据管理
Nacos为例,只需要在配置文件下添加

spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
        metadata:
          version: zlt

metadata 下的 version 就是我添加的元数据 key 为 version,value为 zlt

启动服务后元数据就会注册上去,如下图

经过元数据区分后,目前是下面这个情况

  • 服务器的实例 version 为空
  • 开发人员自己本地启动的实例 version 为唯一标识(自己的名字)

 

3.2. 自定义负载均衡规则

首先在 Spring Cloud 微服务框架里实例的负载均衡是由 Ribbon 负责。
CustomIsolationRule详细类信息可查看:CustomIsolationRule.java

public class CustomIsolationRule extends RoundRobinRule {
    /**
     * 优先根据版本号取实例
     */
    @Override
    public Server choose(ILoadBalancer lb, Object key) {if (lb == null) {return null;}
        String version = LbIsolationContextHolder.getVersion();
        List<Server> targetList = null;
        List<Server> upList = lb.getReachableServers();
        if (StrUtil.isNotEmpty(version)) {
            // 取指定版本号的实例
            targetList = upList.stream().filter(
                    server -> version.equals(((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION)
                    )
            ).collect(Collectors.toList());
        }

        if (CollUtil.isEmpty(targetList)) {
            // 只取无版本号的实例
            targetList = upList.stream().filter(
                    server -> {String metadataVersion = ((NacosServer) server).getMetadata().get(CommonConstant.METADATA_VERSION);
                        return StrUtil.isEmpty(metadataVersion);
                    }
            ).collect(Collectors.toList());
        }

        if (CollUtil.isNotEmpty(targetList)) {return getServer(targetList);
        }
        return super.choose(lb, key);
    }

    /**
     * 随机取一个实例
     */
    private Server getServer(List<Server> upList) {int nextInt = RandomUtil.randomInt(upList.size());
        return upList.get(nextInt);
    }
}

集成轮询规则 RoundRobinRule 来实现,主要的逻辑为

  1. 根据上游输入的版本号 version,有值的话则取 服务元信息 version值一样的实例
  2. 上游的版本号 version 没值或者该版本号匹配不到任何服务,则只取 服务元信息 version值为空的实例

 
并通过配置开关控制是否开启自定义负载规则

@Configuration
@ConditionalOnProperty(value = "zlt.ribbon.isolation.enabled", havingValue = "true")
@RibbonClients(defaultConfiguration = {RuleConfigure.class})
public class LbIsolationConfig {}

 

四、总结

上面提到的 区分服务实例 自定义负载规则 为整个解决思路的核心点,基本实现了服务实例的隔离,剩下要做的就是 上游的 version 怎样传递呢?,下面我提供两个思路

  • 开发人员自己启动前端工程,通过配置参数,统一在前端工程传递version
  • 通过 postman 调用接口的时候在 header 参数中添加

 
参考
https://github.com/Nepxion/Discovery

 
推荐阅读

  • 日志排查问题困难?分布式日志链路跟踪来帮你
  • zuul 集成 Sentinel 最新的网关流控组件
  • 阿里注册中心 Nacos 生产部署方案
  • Spring Boot 自定义配置项在 IDE 里面实现自动提示
  • Spring Cloud Zuul 的动态路由怎样做?集成 Nacos 实现很简单

 

正文完
 0