1. 背景
测试环境治理一直是各大公司非常重要的一个课题，测试环境稳定性很大程度影响迭代开发&测试效率。
综合来看，测试环境不稳定的原因主要有以下几点：
- 测试环境的变更非终态变更，经常会有代码发布/配置发布导致服务无法启动或者链路有问题的情况。
- 变更频繁，开发需要联调、测试需要迭代测试，代码需要变更，配置也需要变更，权限控制就比较难做，增加了测试环境不稳定性。
- 并行需求，同一时间单个应用需要多个分支同时支持多个需求的测试，测试环境资源的抢占和冲突比较明显。
得物测试环境稳定性治理也经历了几个阶段：
2020~2021：多套物理环境隔离方案（基于ECS）
T0、T1、T2三套测试环境，每套环境物理隔离，无资源冲突和共享。
规划T1用于迭代测试、T0用于集成回归、T2用于独立项目分配使用，但在实际使用过程中，业务测试并行太多，冲突比较明显，环境就开始乱用了，谁有需求就随便占用一套环境使用了。结果就是没有一套稳定的环境，测试有效性无法保障，并行项目环境冲突也无法解决。
2021~2022：MF全链路容器环境方案（基于容器）
随着业务增长，3套测试环境已明显不能满足业务需求，因此去年得物基于容器快速搭建了10套MF环境用于支撑独立项目的测试。
MF环境基于T0搭建，DB和T0共享，其他所有资源均独立，目的是做到业务只需保障T0的稳定性，所有MF环境可快速基于T0同步最新服务和最新配置，做到环境随用随取，解决并行项目环境冲突问题。
实际实施过程中，项目环境冲突的问题解决了，但是MF环境的稳定性问题依旧比较严重，维护成本巨大，主要原因集中在：
T0环境稳定性，并非所有域都在T0集成回归，导致T0稳定性无法保障
MF同步了T0之后会因为各种各样的原因需要二次调试验收（新增服务丢失、配置不全/错乱等）
MF环境使用过程中，基础服务（sso、网关、中间件）等相关变更无法及时更新到MF环境，影响业务测试
因此在2022年下半年，开始尝试用染色环境解决环境稳定性问题。
2022年：染色环境方案（基于流量隔离）
染色环境是基于流量隔离的方案，通过流量标透传的方式，把基准环境流量和染色环境流量隔离开，实现多环境的方案，支持并行测试互不影响。
相较于MF环境而言，不需要维护多套全链路环境，维护成本降低了。所有变更的服务都在染色环境部署的话，基准环境稳定性就会提升，相当于所有环境的稳定性都提升了。
下面主要介绍得物染色环境是如何做的
2.染色环境方案
2.1 基本思路
如下图所示，最初的设想是：
- 服务可以按照流量标把流量路由到相应染色服务上
- 如果染色标对应染色环境没有此服务，则流量会走到基准环境
- 如果染色环境服务添加了，没有部署，或者部署了服务进程挂了，则流量会报错而并非走到基准环境（避免一些服务异常问题没有暴露）
- DB、MQ、Redis等中间件期望用同一套，避免浪费
基于此设想，需要从哪些地方入手去改造以支持染色环境呢？可以从设想拆解去解决：
- 流量标如何透传？
- 流量路由如何路由到染色节点？
- rpc接口如何路由到染色节点？
- MQ消息如何让染色环境consumer消费？
- 解决完流量标透传问题，以及染色路由问题后，需要考虑流量发起方如何把染色标带上？
2.2 实现方案
以下方案只做流量隔离，DB数据层不做隔离
1.流量标如何透传？
首先流量标在流量入口层会放到http header里面的x-infr-flowtype字段：
x-infr-flowtype: ##CE_是固定前缀，为了和压测标做区分 从流量到网关后，服务链路上面流量标往下透传的方式是通过OpenTracing规范中的baggage能力，从header里面获取染色标，并塞到trace里面向下透传。
这样整个链路里面就都能拿到染色标了
2.流量路由如何路由到染色节点？
这里分两块考虑：
（1）rpc调用，拿到染色标之后，如何找到染色节点？这里要解决的是怎么识别染色节点
（2）MQ消息，producer如何发送带染色标的消息，consumer如何处理带染色标的消息
服务注册--识别染色节点
- 首先染色环境创建的时候，会定义好染色标：
在此染色环境添加服务部署的时候，默认会把染色标注入到环境变量COLORING_ENV
容器发布配置页面会自动增加COLORING_ENV变量
至此，服务启动时已可以读到COLORING_ENV环境标变量了，下一步就看注册中心怎么去区分染色节点了.
首先服务在添加到染色环境的时候，服务会在注册中心染色场增加一个节点，标明该服务在此染色环境是有服务节点存在的。
染色场主要解决的问题是：如果染色节点挂了，染色环境流量应该判断该染色环境是否应该有染色节点，有的话就报错，没有的话才会走到基准环境。避免测试问题未暴露。
染色场：CE_< ServiceName>
染色场服务节点：
其次在服务注册时候，服务节点信息和方法注册会携带染色标
至此，注册中心就可以基于染色标识别染色节点，业务服务（基于fusion框架）可以根据Trace中的染色标结合注册中心染色节点做染色流量路由。
- MQ改造--识别和处理MQ消息
MQ主要解决的是，染色环境的消息生产者producer发送的消息，只被染色环境的消费者消费，染色环境如果没有消费节点，则由基准环境消费者消费。
这里之前讨论了两种做法：
第一种是基于Topic隔离的方案，每套染色环境使用不同的topic进行通信，这样隔离性比较好，消息不容易串掉。
第二种是Topic不隔离，所有染色环境共用一个topic，生产者Producer在生产消息时候把染色标带上，consumer每套染色环境有一个，consumer在做消费时候会判断消息里面的染色标和本地染色标是否一致，如果一致则消费，如果不一致则直接返回ACK不走具体消费逻辑。
目前选择的是第二种方案，下面基于第二种方案做详细介绍：
基本流程
如图所示：
- ServiceB_Color1会自动注册GID_Color1_Topic消费组，监听Topic_A。Color2和Color3环境一样。
- 带Color1的消息由ServiceA_Color1生产，ServiceB_Color1消费。
- 带Color2的消息由ServiceA_Color2生产，ServiceB消费，因为ServiceB在Color2染色环境没有节点
- 带Color3的消息由于染色环境Color3没有ServiceA_Color3节点，则带Color3的流量会打到基准环境ServiceA，此时ServiceA会生产带Color3的消息，此消息由ServiceB_Color3消费
配合业务说明：
染色环境在启动时候，带染色标的GID会自动创建，eg：原GID是GID_AAA，染色自动创建的GID为GID_
下面看消息的内容和处理逻辑：
如上图：染色消息属性里面会增加DMQ_ENV_TAG字段，添加染色标，然后对应染色环境订阅组才会消费。
看上面这张图，会发现“貌似”所有染色环境都消费了，其实是其他环境直接返回了ACK，未走具体的消费逻辑，具体可以看日志。
代码说明：基于Message里面染色标msgTag和本地服务染色标envTag进行判断做消费逻辑区分。
3.染色流量入口携带染色标
解决完染色标透传，以及染色标逻辑处理后，剩下就是如何在流量发起方把染色标给带上了，其实就是把染色标塞到header里面的x-infr-flowtype字段。
其中染色环境列表的获取由发布平台提供接口给到各流量入口方去选择。
目前业务推广过程中，主要遇到的入口方大致有以下几种：
入口流量携带染色标相对逻辑比较简单，这里就不做详细技术介绍，只做使用层面介绍
至此整个业务改造基本完成，从染色流量如何构造、流量标如何透传、染色节点如何识别以及识别后重点染色逻辑如何处理等一整套流程就清晰了。
3.业务应用效果
3.1 实施路径
染色项目整个实施路径包含几个阶段：
项目立项&中间件改造（4月-6月）
包含基架改造（统一框架、网关、注册中心、配置中心、超时中心、DMQ等）&客户端改造&发布平台改造等等，以及改造完成后基础链路验证
线上灰度&全链路服务适配（7月~8月）
7月初：5个交易&中间件相关服务升级相关jar包带上线进行验证，保证不会对染色改造不会对生产有影响。
8月份：开始推进全域应用进行染色相关jar包升级
独立项目使用（9月）
9月底之前，已经有若干独立项目应用染色环境测试验证完成
业务迭代使用（10月~11月）
10月份开始尝试推进全业务进行染色环境试用排错
试用结束，逐步推进迭代使用染色环境
3.2 业务使用效果
独立项目：目前全域的独立项目已全量切换至染色环境测试。
版本迭代：就最新的版本迭代使用结果来看，全域95%以上的需求都可以使用染色环境测试。
剩余5%的需求场景主要是涉及以下两个方面：
- 数据隔离：目前已有方案在支持，会涉及少量需求支撑。
- 前端染色：目前染色环境主要解决了后端染色的需求，部分场景需求依赖前端染色（多前端支持），方案也基本落地，会配合后端染色一起应用。
4.总结
染色环境现阶段解决了测试环境冲突和测试环境稳定性的问题，并且相较之前多套独立环境的方案，在成本上也有比较大的节省。后续得物也会尝试用染色的能力解决生产灰度发布问题，相信也会有不错的效果。
*文/大地
关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～