1. 介绍

1.1 解决的问题

独立环境是个抽象的概念；

主要解决的问题：开发过程中，往往多个任务并行，并且一个项目可能由多人进行维护；

如果同时部署到QA环境，不仅会产生代码冲突、还有可能因为业务的关联性，导致与预想结果不符合；

注：核心解决的问题是这个，往大了搞，可以整一个灰度环境，用于灰度测试

1.2 实现的核心逻辑

核心实现思想：以需求创建项目代码分支，创建独立的需求测试环境，即将涉及此需求改动的项目部署到一个环境中，其他不变的项目使用公共QA;

实现前提：

1）服务部署时，携带对应的环境标识；

2）面向前端提供的服务，要有相应的api网关服务；

实现逻辑：

1）从客户端携带当前测试的环境编号（header 中添加相应的环境变量）；

2）网关（nginx）透传 ；

3）api网关根据环境变量选择 对应环境的api服务（没有走默认负载均衡策略）；

4）api服务在请求 微服务、mq等中间件是携带环境变量；

整体流程如下：

2. 核心代码解读

开始解读前，思考一下几个问题？

1）服务的灰度范围，哪些服务需要，哪些不需要？

2）服务本身是否要带灰度标识？

3）如何服务本身不携带标识，那服务灰度标识存到哪里？

4）后端架构中间件的负载均衡组件是否一致，能不能抽离出一套公用的？

2.0 eureka 服务注册灰度环境适配

eureka 作为注册中心，本身就是存储服务元信息的，因此作为服务标识存储位置再合适不过了。

改造就完事了；

经过研究哈，自定义这个：
eureka.instance.instance-id ，就了；

处理后服务注册到eureka 的效果如下：

2.1 api 网关灰度环境适配

这里我们以spring-cloud-gateway为例搞一哈；

对spring-cloud-gateway不了解的，可以参见这个：gateway 学习

改造前，先思考我们需要在哪一步改造，，当然是转发请求，选择服务的时候进行了；

下面是gateway 请求链路图：

选哪个作为切入点了？ 自然是 LoadBlancedClientFilter 了，这个看着就很亲切；

我们自定义LoadBlancedClientFilter 将灰度标识存入threadlocal;

因为底层选择服务是ribbon，我们自定义ruler即可完成 服务选择规则的重定义；

自定义LoadBlancedClientFilter：

@Component@ConditionalOnProperty(name="enable_gray_env"