前言

多泳道听过吗？它为了解决什么问题？它又长什么样子？具体实现是怎么做的？

多泳道样子

多泳道，顾名思义，就是像游泳一样，有多个游泳道，他们互相不影响。 测试环境多泳道，其实是有一个主泳道，多条次泳道，主泳道是作为稳定的泳道，它可以访问其他泳道的服务，其他泳道是不稳定的，这样的话，可以保证测试环境的稳定性。

多泳道解决什么问题

背景：在测试阶段，我们经常会听到测试同学经常抱怨，测试进度被某个流程卡住，某某背锅开发同学在排查。有时会导致多个测试任务卡住，影响整个流程正常运作，所以我们需要保证测试环境的稳定性。

其次在同一时间，有多个需求同时进行，那么如果A同学改了一个代码，导致test环境炸了，是不是我们也需要等卑微的小A同学修完bug才能继续。多泳道可以解决抢占问题，提高开发效率，就是测试同学通过自己的泳道访问那条修改的代码。而其他同学访问稳定的test环境。

如上图所示，测试环境作为稳定泳道来运作，这样就不会由于开发代码一直卡流程。如果我们只是特定的服务做更新的话，其他服务都是稳定的，我们只需要在特定节点路由到那个需要测试的服务，这样提高测试环境的稳定性。

完整步骤

泳道创建：工单实现不同泳道的快速创建，比如说有个需求A，同一时间有个需求B，可以通过工单快速将dev1、dev2 开放平台两个版本跑起来 (稳定泳道：权限，经常变动泳道：开放平台..)
流量打标：网关进行改造，在工单创建泳道的时候顺便有个域名，dev1.com,dev2.com，同时指向稳定网关test环境，网关对流量进行打标tag。负载到对应环境的服务。
RPC层负载：由于我们链路非常短，看不出这一层的负载，网关在调用权限模块之后，再调用开放平台服务，具体到哪个服务，这个也算rpc层负载。
数据隔离： dev1.com -> dev1 pod - >dev1数据库

为啥需要通过工单来创建？我们可以看下腾讯云方案，资源的自动化，弹性扩展。理想的话，我们也需要实现运维资源的自动化。

在二三点的时候，其实在上一篇文章讲过，大家感兴趣可以去看看~

数据隔离方面，可以做影子表、影子库。或者我们物理隔离统一5个环境，对应5个mysql实例。

测试流程

现在需求A、需求B来了，我们拉了两个分支，现在都提测了
创建工单，新建dev1、dev2环境，它会生成对应的域名指向test网关，然后我们通过全链路灰度，实现test网关通过域名维度，指向对应的服务。
测试同事通过不同域名，来验证不同的逻辑，然后去不同的数据库验证数据准确性。
测试通过之后，将分支合并到test，构建test环境
泳道删除，资源回收。

我们来对比下两个方案的优缺点，这样会有直观的比较。

形式	优点	缺点
多物理环境	物理隔离，操作快捷	资源浪费，测试环境会有不稳定的开发代码
多泳道	逻辑隔离，工单快速创建泳道，减少资源消耗	需要对中间件进行改造，比如说dev1、dev2 redis、mq、数据库都需要隔离

本文借鉴以下文章：