在云原生网关升级到2.0.2版本后，您可以使用新版的全链路灰度能力，本文介绍从各种不同场景切换到新版全链路灰度的迁移路径。
背景
在云原生网关2.0.2版本上线前，您使用云原生网关作为入口进行全链路灰度时，必须使用指向单版本的标签路由作为基线路由。
在云原生网关升级到2.0.2版本后，您可以使用新版的全链路灰度能力，无需创建灰度路由，在大规模入口路由的场景下可以获得更好的性能与体验。
限制条件
云原生网关版本大于等于2.0.2。
需要将原有的标签路由改为完全条件一致的单服务路由。
环境准备
本文以下图中的微服务应用作为例子进行演示。应用中包含A、B、C三个应用，调用链路为 A -> B -> C，云原生网关访问入口应用A。
迁移路径
本文描述对于当前存在的泳道，如何平滑迁移到新的全链路灰度实现。
按内容
泳道迁移
老的泳道中，各泳道的比例配置如下图： header中color=gray时指向gray环境；color=blue时指向blue环境。
步骤一：创建新的单服务路由
创建一条和原有路由匹配条件完全一致的单服务路由。根据当前的路由匹配规则，当匹配条件一致时，创建时间早的路由会生效，因此保持原有的请求条件会匹配到老的标签路由。
为了临时测试该单服务路由，为其额外增加一个匹配条件：请求Header中migrate=true
步骤二：验证原有灰度链路不受影响
请求基线
请求gray泳道
请求blue泳道
步骤三：创建新的全链路灰度泳道
完成网关升级，可以创建新的泳道，泳道规则和之前保持一致。
回到路由列表页，可以看到没有新的灰度路由被创建，作为基线的单服务路由有全链路灰度标记。
测试老的基线路由/灰度路由，可以正常生效。
测试新的基线路由，表现正常。
步骤四：路由切流
调整单服务路由的匹配规则，去掉请求Header中migrate=true的条件，发布路由。
下线原有基线标签路由。
验证灰度，依然正常。
此时老的标签路由为下线状态，若切流过程中出现问题，可随时通过重新发布原有基线路由来执行回滚。
步骤五：老泳道下线
若验证新的单服务路由正常，可以对老的泳道执行下线操作，彻底清除灰度路由。
回到全链路灰度，删除原有泳道。
可以观察到灰度路由已被删除。
删除原有基线标签路由，迁移完成。
按比例
泳道迁移
老的按比例泳道中，各泳道的比例配置如下图：gray环境分配30%流量，blue环境分配10%流量。
步骤一：创建新的单服务路由
创建一条和原有路由匹配条件完全一致的单服务路由。根据当前的路由匹配规则，当匹配条件一致时，创建时间早的路由会生效，因此保持原有的请求条件会匹配到老的标签路由。
为了临时测试该单服务，为其额外增加一个匹配条件：请求Header中migrate=true
步骤二：验证原有灰度链路不受影响
执行测试脚本，分流比例正常。
查看网关访问日志，可以看到依然匹配到的是基线路由a。
步骤三：创建新的全链路灰度泳道
完成网关升级，可以创建新的泳道，泳道规则和之前保持一致。
回到路由列表页，可以看到没有新的灰度路由被创建，作为基线的单服务路由有全链路灰度标记。
使用测试脚本测试，流量比例正常。
调整测试脚本，在访问路由A时添加请求header migrate=true，使其指向新的单服务路由
执行测试，分流比例符合预期。
步骤四：路由切流
调整单服务路由的匹配规则，去掉请求Header中migrate=true的条件，发布路由。
移除测试脚本中的请求header migrate=true，分流比例符合预期。
下线老的基线标签路由，灰度路由一并被下线。
重新执行测试脚本，分流比例依然符合预期。
此时老的标签路由为下线状态，若切流过程中出现问题，可随时通过重新发布原有基线路由来执行回滚。
步骤五：老泳道下线
若验证新的单服务路由正常，可以对老的泳道执行下线操作，彻底清除灰度路由
回到全链路灰度，删除原有泳道。
可以观察到灰度路由已被删除。
删除原有基线标签路由，迁移完成。
