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更新技能干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
