1.后台测试环境治理一直是各大公司非常重视的话题。测试环境的稳定性极大地影响着迭代开发测试的效率。综合来看，导致测试环境不稳定的主要原因有：测试环境的变化不是最终状态的变化，经常有代码发布/配置发布导致服务无法启动或者链接有问题。变更频繁，开发需要联调，测试需要迭代测试，代码要改，配置也要改，权限控制比较难做，增加了测试环境的不稳定性。并行需求，单个应用需要多个分支同时支持多个需求的测试，测试环境资源抢占和冲突明显。Dewu测试环境稳定性治理也经历了几个阶段：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消息如何让染色环境消费者消费？解决了流量令牌的透传问题和染色路由问题后，就要考虑流量发起者如何将染色令牌放在上面了。2.2实现方案以下方案只做了流量隔离，但是如何在不隔离流量的情况下透传DB数据层呢？首先在流入口层的http头中的x-infr-flowtype字段中会放置流标记：x-infr-flowtype:##CE_是一个固定的前缀，为了区别于流量到达网关后的压测标记，业务链路上透传流量标记的方法是利用OpenTracing规范中的baggage能力，从header中获取dyemark，塞入trace中进行向下透明传播。这样就可以在整个链路中得到染色标记。如何将流量路由到染色节点？这里有两个考虑：（1）rpc调用，拿到染色标记后如何找到染色节点？这里需要解决的是如何识别染色节点（2）MQ消息，生产者如何发送带有染色标记的消息，消费者如何处理带有染色标记的消息服务注册——先识别染色节点染色环境创建后，会定义染色标记：在该染色环境中添加服务部署时，默认将染色标准注入到环境变量COLORING_ENV中。容器发布配置页面会自动在此处添加COLORING_ENV变量。服务启动时可以读取COLORING_ENV环境变量。接下来就是看注册中心如何区分染色节点了。首先，当一个服务被添加到染色环境中时，该服务会在注册中心染色字段中添加一个节点，表示该服务在染色环境中有一个服务节点。染场要解决的主要问题是：如果染色节点宕机，染色环境流量要判断染色环境中是否应该有染色节点，如果有就报错，去benchmark如果没有染色节点的环境。避免测试未暴露的问题。着色字段：CE_着色字段服务节点：:80其次，服务注册时，服务节点信息和方法注册会携带着色env：此时注册中心可以识别染色节点基于着色env，业务服务（基于融合框架）可以根据Trace中的染色标签和注册中心的染色节点进行染色流量路由。MQTransformation--识别和处理MQ消息MQ主要解决染色环境中消息生产者发送的消息只被染色环境中的消费者消费的问题。如果染色环境没有消费节点，它们将被基准环境中的消费者消费。这里讨论了两种方法：第一种是基于主题的隔离方案。每个染色环境使用不同的主题进行通信，这样隔离性更好，消息不容易丢失。二是话题不是孤立的，所有染色环境共享一个话题。生产者在生产信息时将染色标签贴在信息上，消费者每一种染色环境都有一个。消费者在消费的时候会判断消息中的染色标签和本地的染色标签是否一致，一致则消费，不一致则直接返回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__AAA。下面看消息内容和处理逻辑：如上图所示：在染色消息属性中加入DMQ_ENV_TAG字段，添加染色标签，然后消费对应的染色环境订阅组。看上图你会发现，“看起来”所有的染色环境都消费完了，但实际上其他环境没有按照具体的消费逻辑直接返回ACK。您可以参考日志了解详细信息。代码说明：根据Message中的颜色标签msgTag和本地服务颜色标签envTag来判断和区分消费逻辑。有色流量入口携带染色标签，解决染色标签的透传和染色标签的逻辑处理，剩下的就是如何在流量发起端带上染色标签，其实就是将染色标签插入x-infr-在报头流类型字段中。其中，染色环境榜单的获取由发布平台提供，供各流量入口方选择。在目前的业务推广过程中，遇到的主要入口方大致有以下几种：携带色标的入口流量逻辑比较简单，这里不介绍详细技术，只介绍使用层面。从发布平台获取染色标记列表，选择染色环境后，在所有请求的Header中添加x-infr-flowtype字段，将颜色标记下传到Web端。点击ENV弹窗选择染色标记。同上，飞书Callback回调URL参数增加x-infr-flowtype=字段作业场景目前是半自动方案：染色环境和参考环境注册到同一个作业。默认情况下，作业会随机选择一个节点执行。如果需要指定执行的染色节点，用户可以在作业编辑界面手动添加染色标准目前没有考虑数据隔离的场景。Canal订阅目前是一种半自动的解决方案：染色节点和参考节点消费者订阅同一个主题。默认的MQ消息不会携带染色标记，只会有引用环境消费。如果需要指定染色环境消耗，用户可以在作业编辑界面手动添加染色标记。目前暂不考虑数据隔离场景。至此，整个业务改造基本完成，从如何构建染色流量，如何透传流量标记，如何识别染色节点，识别后如何处理关键染色逻辑。清除。3.业务应用效果3.1实施路径染色项目整个实施路径包括几个阶段：立项&中间件改造（4-6月）包括脚手架改造（统一框架、网关、注册中心、配置中心、超时中心、DMQ、等）&客户端改造&发布平台改造等，改造完成后基础链路验证上线灰度&全链路服务适配（7~8月）7月初：5笔交易&中间件相关jar包相关服务升级上线验证，确保染色改造不影响生产。8月：开始在全球推广应用升级染色相关jar包。在独立项目中使用（9月）。9月底前，多个独立项目完成业务迭代使用，染色环境测试验证（10-11月）。争取在十月推广。全业务染色环境试用结束，试用结束，逐步推进染色环境的迭代使用。3.2业务使用效果独立项目：目前全域独立项目全部切换到染色环境测试。版本迭代：根据最新的版本迭代结果，整个领域95%以上的需求都可以在染色环境中进行测试。其余5%的需求场景主要涉及以下两个方面：数据隔离：目前已有方案在支持，会涉及少量的需求支持。前端染色：目前的染色环境主要解决后端染色的需求，部分场景依赖前端染色（多前端支持）。该方案已基本实施，将与后道染色配套应用。4.染色环境总结这个阶段已经解决了测试环境冲突和测试环境稳定性的问题，而且相比之前多套独立环境的方案，在成本上也有比较大的节省。后续得物也会在生产中尝试利用染色的能力来解决灰度释放问题，相信会有不错的效果。
