在云原生网关升级到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
其中路由名称为a-single，路径前缀为/a，后端服务为sc-a（HTTP协议、端口20001），保持与原标签路由匹配条件一致。
步骤二：验证原有灰度链路不受影响
请求基线
发送不带任何请求头的GET请求至/a，响应链路为A → B → C（均为基线版本）。
请求gray泳道
添加请求头color=gray后，响应链路为Agray → B → Cgray，命中gray灰度环境。
请求blue泳道
添加请求头color=blue后，响应链路为Ablue → B → Cblue，命中blue灰度环境。
步骤三：创建新的全链路灰度泳道
完成网关升级，可以创建新的泳道，泳道规则和之前保持一致。
在路由的常规配置页面填写基本信息（路由名称、Path、Method、Header、后端服务等），泳道规则保持与原配置一致。
回到路由列表页，可以看到没有新的灰度路由被创建，作为基线的单服务路由有全链路灰度标记。
测试老的基线路由/灰度路由，可以正常生效。
其中带color=gray请求头的请求仍命中Agray → B → Cgray链路。
带color=blue请求头的请求命中Ablue → B → Cblue链路。
测试新的基线路由，表现正常。
仅添加migrate=true请求头时，请求经由新基线路由，响应链路为A → B → C（均为基线版本）。
在migrate=true基础上叠加color=gray请求头，响应链路为Agray → B → Cgray，灰度分流仍生效。
在migrate=true基础上叠加color=blue请求头，响应链路为Ablue → B → Cblue，blue泳道分流同样符合预期。
步骤四：路由切流
调整单服务路由的匹配规则，去掉请求Header中migrate=true的条件，发布路由。
此时请求头列表已清空，保存配置后单击发布。
下线原有基线标签路由。
原基线标签路由的状态变更为未发布。
验证灰度，依然正常。
其中color=gray请求响应链路为Agray → B → Cgray。
color=blue请求响应链路为Ablue → B → Cblue。
此时老的标签路由为下线状态，若切流过程中出现问题，可随时通过重新发布原有基线路由来执行回滚。
步骤五：老泳道下线
若验证新的单服务路由正常，可以对老的泳道执行下线操作，彻底清除灰度路由。
回到全链路灰度，删除原有泳道。
在弹出的确认对话框中确认删除操作。
可以观察到灰度路由已被删除。
删除原有基线标签路由，迁移完成。
按比例
泳道迁移
老的按比例泳道中，各泳道的比例配置如下：gray环境分配30%流量，blue环境分配10%流量。
步骤一：创建新的单服务路由
创建一条和原有路由匹配条件完全一致的单服务路由。根据当前的路由匹配规则，当匹配条件一致时，创建时间早的路由会生效，因此保持原有的请求条件会匹配到老的标签路由。
为了临时测试该单服务，为其额外增加一个匹配条件：请求Header中migrate=true
其中路由名称为a-single，路径前缀为/a，后端服务为sc-a（HTTP协议、端口20001）。
步骤二：验证原有灰度链路不受影响
执行测试脚本，分流比例正常。
Total Request: 100
Traffic Distribution: {'gray': 27, 'base': 65, 'blue': 8}查看网关访问日志，可以看到依然匹配到的是基线路由a。
步骤三：创建新的全链路灰度泳道
完成网关升级，可以创建新的泳道，泳道规则和之前保持一致。
在路由的常规配置页面填写基本信息，泳道规则保持与原按比例配置一致。
回到路由列表页，可以看到没有新的灰度路由被创建，作为基线的单服务路由有全链路灰度标记。
使用测试脚本测试，流量比例正常。
Total Request: 100
Traffic Distribution: {'base': 65, 'gray': 29, 'blue': 6}调整测试脚本，在访问路由A时添加请求header migrate=true，使其指向新的单服务路由
执行测试，分流比例符合预期。
Ablue[10.0.23.37][config=base] -> B[10.0.10.21] -> C[10.0.23.34]
Ablue[10.0.23.37][config=base] -> B[10.0.10.21] -> Cblue[10.0.23.35]
Total Request: 100
Traffic Distribution: {'gray': 30, 'base': 58, 'blue': 12}步骤四：路由切流
调整单服务路由的匹配规则，去掉请求Header中migrate=true的条件，发布路由。
此时请求头列表已清空，保存后单击发布使变更生效。
移除测试脚本中的请求header migrate=true，分流比例符合预期。
Total Request: 100
Traffic Distribution: {'base': 63, 'gray': 32, 'blue': 5}下线老的基线标签路由，灰度路由一并被下线。
原标签路由及其关联的灰度路由均显示为未发布。
重新执行测试脚本，分流比例依然符合预期。
Total Request: 100
Traffic Distribution: {'blue': 10, 'base': 64, 'gray': 26}此时老的标签路由为下线状态，若切流过程中出现问题，可随时通过重新发布原有基线路由来执行回滚。
步骤五：老泳道下线
若验证新的单服务路由正常，可以对老的泳道执行下线操作，彻底清除灰度路由
回到全链路灰度，删除原有泳道。
在弹出的确认对话框中确认删除操作。
可以观察到灰度路由已被删除。
删除原有基线标签路由，迁移完成。