这里是weihubeats ,觉得文章不错可以关注公众号小奏技术，文章首发。拒绝营销号，拒绝标题党
背景
随着公司的发展，研发的系统和开发人员会变得越来越多。但是测试环境却始终只有一个，所以久而久之，我们就发现研发经常遇到如下问题:
- 测试环境太少开发人员太多，一个人服务bug影响所有人测试
- 代码冲突增加，许多人同事代码合并到一个测试环境分支，经常存在很多代码冲突，需要花大量时间解决
- 有冲突的需求无法再一个测试环境进行测试，需要多个测试环境
解决思路
解决上面的问题很简单，就是部署多套测试环境，但是在在微服务系统架构下不同服务(比如我们有库存服务、商品服务、订单服务)可能是由多个团队进行开发维护的。
如果每个团队有单独的一套开发联调环境，那么每个团队不仅需要维护自己环境的微服务应用，还需要维护其他团队环境的自身所属微服务应用，效率大大降低。同时，每个团队都需要部署完整的一套微服务架构应用，成本也随着团队数的增加而大大上升
比如 订单服务需要部署的自己的测试环境，可能需要部署 product、order、pay等服务多个服务
实际上订单小组可能只关心order服务，其他服务自己不关心，也不用去维护。
只需要自己在测试调用其他服务的接口的时候稳定不报错，不影响自己测试就好。
然后如果商品小组也想要自己的测试环境，也需要再部署一套如下系统
product、order、pay等服务多个服务
总体成本是非常高的，那么有没有其他更省事实力的方案呢？
多测试路由架构
此时可以使用测试环境路由的架构来帮助部署一套运维简单且成本较低开发联调环境。测试环境路由是一种基于服务路由的环境治理策略，核心是维护一个稳定的基线环境作为基础环境，测试环境仅需要部署需要变更的微服务 多测试环境有两个基础概念，如下所示：
- 基线环境（Baseline Environment）: 完整稳定的基础环境，是作为同类型下其他环境流量通路的一个兜底可用环境，用户应该尽量保证基线环境的完整性、稳定性。
- 测试环境（Feature Environment）: 一种临时环境，仅可能为开发/测试环境类型，测试环境不需要部署全链路完整的服务，而是仅部署本次有变更的服务，其他服务通过服务路由的方式复用基线环境服务资源
各个小组需要自己的测试环境只需要关心自己系统的多测试环境，在调用其他系统的时候调用他们稳定的基线环境 ，所有服务只需要维护一套基线环境，其他小组想要增加自己的测试环境只需要自己多部署几个自己的特性环境，而不用管其他小组的服务。
实现原理
总体实现思路如下:
我们大致实现的就是pay1调用的就是order1,如果order1不存在，则调用基线环境，即pay。这样我们就是想要多少个测试环境，就有多少个，相互依赖的服务如果没有对应的测试环境就会调用基线环境
实现技术支持
要实现上面路由我们需要如下技术支持
- 网关支持通过不同的标签选用不同的服务
- 网关和所有业务系统需要支持全链路标签传递
- 所有业务系统需要支持打标签
网关路由这一块我们需要通过扩展spring cloud loadbalacer的接口DelegatingServiceInstanceListSupplier来支持自定义服务路由
全链路标签透传我们需要通过skywalking进行全链路标签透传
服务pod打标我们需要通过k8s的服务发现对服务进行打标
总结
总得来说我们基于服务编排、流量染色、动态自定义路由实现了http的多测试环境。
如果我们要实现全链路，还需要实现MQ、xxl-job等三方中间件的多测试环境隔离