Spring Cloud如何解决开发人员调试过程服务冲突和实例乱窜？

凛冬王昭君 2021年10月21日 94次浏览

一、背景

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

交互流程.jpg

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

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

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

二、解决思路

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

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

三、具体实现

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

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

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

直接使用注册中心的元数据(metadata)来区分就可以了
主流的注册中心都带有元数据管理
以Nacos为例，只需要在配置文件下添加

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

metadata下的request-version就是我添加的元数据key为request-version，value为1.0.0

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

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

服务器的实例request-version为空
开发人员自己本地启动的实例request-version为唯一标识(自己的名字或者版本号)

交互流程示例.png

3.2. 自定义负载均衡规则

首先在Spring Cloud微服务框架里实例的负载均衡是由Ribbon负责。
自定义实现负载均衡规则

package com.github.sparkzxl.distributed.cloud.loadbalancer;

import cn.hutool.core.collection.CollUtil;
import cn.hutool.core.util.RandomUtil;
import cn.hutool.core.util.StrUtil;
import com.alibaba.cloud.nacos.ribbon.NacosServer;
import com.github.sparkzxl.constant.BaseContextConstants;
import com.github.sparkzxl.core.context.BaseContextHolder;
import com.netflix.loadbalancer.ILoadBalancer;
import com.netflix.loadbalancer.RoundRobinRule;
import com.netflix.loadbalancer.Server;
import lombok.extern.slf4j.Slf4j;

import java.util.List;
import java.util.stream.Collectors;

/**
 * description: 版本优先选择负载均衡规则
 * 开发A访问时，请求的所有路由优先调用开发A本机启动的实例，如果没有则调用服务器上的实例
 * 开发B访问时同上，请求的所有路由优先调用开发B本机启动的实例，如果没有则调用服务器上的实例
 *
 * @author zhouxinlei
 * @date 2021-10-21 14:52:49
 */
@Slf4j
public class TopChoiceVersionIsolationRule extends RoundRobinRule {

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

        if (CollUtil.isEmpty(targetList)) {
            //只取无版本号的实例
            targetList = upList.stream().filter(
                    server -> {
                        String metadataVersion = ((NacosServer) server).getMetadata().get(BaseContextConstants.REQUEST_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());
        Server server = upList.get(nextInt);
        log.info("请求服务实例ip:{}", server.getHostPort());
        return server;
    }
}

继承轮询规则RoundRobinRule来实现，主要的逻辑为

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

四、使用

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

开发人员自己启动前端工程，通过配置参数，统一在前端工程传递request-version

通过postman调用接口的时候在header参数中添加

上一篇：前面没有了下一篇： MongoDB 快速入门，掌握这些就够了