基于 nacos/灰度发布 实现减少本地启动微服务数量的实践

一、背景

后台框架是基于 spring cloud 的微服务体系, 当开发同学在自己电脑上进行开发工作时, 比如开发订单模块, 除了需要启动订单模块外, 还需要启动网关模块、权限校验模块、公共服务模块等依赖模块, 非常消耗开发同学的本地电脑的资源, 也及其浪费时间.

二、解决方案

2.1 目标和关键问题

能不能开发同学本地只需要启动需要开发的模块:订单模块, 其他模块均适用测试环境中正在运行的服务.

既然要实现的目标有了, 我们就开始研究可行性和关键问题

1. 开发环境和测试环境要在同一个 nacos 的 namespace 中, 这样才有可能让开发环境调用到测试环境的服务.
2. 测试环境只能调用测试环境的微服务, 实现和开发环境的服务隔离
3. 开发同学之间的微服务也要实现服务隔离

2.2 思路

既要在同一个 namespace 下, 又要能够实现不同人访问不同的副本, 很容易想到可以利用灰度发布来实现:

1. 测试环境设置 metadata lemes-env=product 来标识测试环境副本, 用于区分开发环境的微服务测测试环境的微服务
2. 开发同学本地启动注册开发环境副本, 都会携带唯一IP, 则我们可以通过IP来区分不同开发同学的副本

假设我们需要开发的 API 的后台服务调用链条如下:

我们需要开发的 API 为 /addMo, 打算写在 Order 这个微服务里面, 并且他会调用 common 这个微服务的 /getDict 获取一个字典数据, /getDict 是现成的, 不需要开发, 如果是之前的情况, 开发本地至少需要启动5个微服务才能进行调试.

三、具体实现

3.1 测试环境设置 metadata

由于测试环境都是通过容器部署的, 那么启动方式就是下面容器中的 CMD, 我们在其中加入 -Dspring.cloud.nacos.discovery.metadata.lemes-env=product, 用于区分开发环境的微服务测测试环境的微服务

# 说明：Dockerfile 过程分为两部分。第一次用来解压 jar 包，并不会在目标镜像内产生 history/layer。第二部分将解压内容分 layer 拷贝到目标镜像内
# 目的：更新镜像时，只需要传输代码部分，依赖没有变动则不更新，节省发包时的网络传输量
# 原理：在第二部分中，每次 copy 就会在目标镜像内产生一层 layer，将依赖和代码分开，
#      绝大部分更新都不会动到依赖，所以只需更新代码几十k左右的代码层即可

FROM 10.176.66.20:5000/library/amazoncorretto:11.0.11  as builder
WORKDIR /build
ARG ARTIFACT_ID
COPY target/${ARTIFACT_ID}.jar app.jar
RUN java -Djarmode=layertools -jar app.jar extract && rm app.jar

FROM 10.176.66.20:5000/library/amazoncorretto:11.0.11
LABEL maintainer="yangyj13@lenovo.com"
WORKDIR /data
ARG ARTIFACT_ID
ENV ARTIFACT_ID ${ARTIFACT_ID}

# 依赖
COPY --from=build