1. 测试环境的变更非终态变更，经常会有代码发布/配置发布导致服务无法启动或者链路有问题的情况。
2. 变更频繁，开发需要联调、测试需要迭代测试，代码需要变更，配置也需要变更，权限控制就比较难做，增加了测试环境不稳定性。
3. 并行需求，同一时间单个应用需要多个分支同时支持多个需求的测试，测试环境资源的抢占和冲突比较明显。

• 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.1 基本思路

1. 服务可以按照流量标把流量路由到相应染色服务上
2. 如果染色标对应染色环境没有此服务，则流量会走到基准环境
3. 如果染色环境服务添加了，没有部署，或者部署了服务进程挂了，则流量会报错而并非走到基准环境（避免一些服务异常问题没有暴露）
4. DB、MQ、Redis等中间件期望用同一套，避免浪费

1. 流量标如何透传？
2. 流量路由如何路由到染色节点？
1. rpc接口如何路由到染色节点？
2. MQ消息如何让染色环境consumer消费？
3. 解决完流量标透传问题，以及染色路由问题后，需要考虑流量发起方如何把染色标带上？

2.2 实现方案

以下方案只做流量隔离，DB数据层不做隔离

1. 流量标如何透传？

x-infr-flowtype:<CE_ColoringEnv> ##CE_是固定前缀，为了和压测标做区分

从流量到网关后，服务链路上面流量标往下透传的方式是通过OpenTracing规范中的baggage能力，从header里面获取染色标，并塞到trace里面向下透传。

这样整个链路里面就都能拿到染色标了

2. 流量路由如何路由到染色节点？

• 服务注册--识别染色节点

• 首先染色环境创建的时候，会定义好染色标：

• 在此染色环境添加服务部署的时候，默认会把染色标注入到环境变量COLORING_ENV
  容器发布配置页面会自动增加COLORING_ENV变量

• 至此，服务启动时已可以读到COLORING_ENV环境标变量了，下一步就看注册中心怎么去区分染色节点了.

染色场服务节点：<COLORING_ENV>:80

其次在服务注册时候，服务节点信息和方法注册会携带染色标<coloring_env>：

至此，注册中心就可以基于染色标识别染色节点，业务服务（基于fusion框架）可以根据Trace中的染色标结合注册中心染色节点做染色流量路由。

• MQ改造--识别和处理MQ消息

基本流程

1. ServiceB_Color1会自动注册GID_Color1_Topic消费组，监听Topic_A。Color2和Color3环境一样。
2. 带Color1的消息由ServiceA_Color1生产，ServiceB_Color1消费。
3. 带Color2的消息由ServiceA_Color2生产，ServiceB消费，因为ServiceB在Color2染色环境没有节点
4. 带Color3的消息由于染色环境Color3没有ServiceA_Color3节点，则带Color3的流量会打到基准环境ServiceA，此时ServiceA会生产带Color3的消息，此消息由ServiceB_Color3消费

配合业务说明：

下面看消息的内容和处理逻辑：

如上图：染色消息属性里面会增加DMQ_ENV_TAG字段，添加染色标，然后对应染色环境订阅组才会消费。

看上面这张图，会发现“貌似”所有染色环境都消费了，其实是其他环境直接返回了ACK，未走具体的消费逻辑，具体可以看日志。

代码说明：基于Message里面染色标msgTag和本地服务染色标envTag进行判断做消费逻辑区分。

3. 染色流量入口携带染色标

入口流量携带染色标相对逻辑比较简单，这里就不做详细技术介绍，只做使用层面介绍

至此整个业务改造基本完成，从染色流量如何构造、流量标如何透传、染色节点如何识别以及识别后重点染色逻辑如何处理等一整套流程就清晰了。

3.1 实施路径

1. 项目立项&中间件改造（4月-6月）
1. 包含基架改造（统一框架、网关、注册中心、配置中心、超时中心、DMQ等）&客户端改造&发布平台改造等等，以及改造完成后基础链路验证
2. 线上灰度&全链路服务适配（7月~8月）
1. 7月初：5个交易&中间件相关服务升级相关jar包带上线进行验证，保证不会对染色改造不会对生产有影响。
2. 8月份：开始推进全域应用进行染色相关jar包升级
3. 独立项目使用（9月）
1. 9月底之前，已经有若干独立项目应用染色环境测试验证完成
4. 业务迭代使用（10月~11月）
1. 10月份开始尝试推进全业务进行染色环境试用排错
2. 试用结束，逐步推进迭代使用染色环境

3.2 业务使用效果

1. 数据隔离：目前已有方案在支持，会涉及少量需求支撑。
2. 前端染色：目前染色环境主要解决了后端染色的需求，部分场景需求依赖前端染色（多前端支持），方案也基本落地，会配合后端染色一起应用。

染色环境现阶段解决了测试环境冲突和测试环境稳定性的问题，并且相较之前多套独立环境的方案，在成本上也有比较大的节省。后续得物也会尝试用染色的能力解决生产灰度发布问题，相信也会有不错的效果。

*文/大地

《2022 年度 OSC 中国开源项目评选》正式启动