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_ColoringEnv> ##CE_是固定前缀，为了和压测标做辨别从流量到网关后，服务链路下面流量标往下透传的形式是通过OpenTracing标准中的baggage能力，从header外面获取染色标，并塞到trace外面向下透传。
这样整个链路外面就都能拿到染色标了
2.流量路由如何路由到染色节点？
这里分两块思考：
（1）rpc调用，拿到染色标之后，如何找到染色节点？这里要解决的是怎么辨认染色节点
（2）MQ音讯，producer如何发送带染色标的音讯，consumer如何解决带染色标的音讯
服务注册--辨认染色节点
- 首先染色环境创立的时候，会定义好染色标：
在此染色环境增加服务部署的时候，默认会把染色标注入到环境变量COLORING_ENV
容器公布配置页面会主动减少COLORING_ENV变量
至此，服务启动时已能够读到COLORING_ENV环境标变量了，下一步就看注册核心怎么去辨别染色节点了.
首先服务在增加到染色环境的时候，服务会在注册核心染色场减少一个节点，表明该服务在此染色环境是有服务节点存在的。
染色场次要解决的问题是：如果染色节点挂了，染色环境流量应该判断该染色环境是否应该有染色节点，有的话就报错，没有的话才会走到基准环境。防止测试问题未裸露。
染色场：CE_< ServiceName>
染色场服务节点：<COLORING_ENV>:80
其次在服务注册时候，服务节点信息和办法注册会携带染色标<coloring_env>：
至此，注册核心就能够基于染色标识别染色节点，业务服务（基于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_<coloring_env>_AAA
上面看音讯的内容和解决逻辑：
如上图：染色音讯属性外面会减少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更新技术干货
要是感觉文章对你有帮忙的话，欢送评论转发点赞～