问题

▶️新上线一个功能如何切流怎么做比较稳妥？

▶️旧系统拆分出多个新系统时，如何设计切流方案？

新上线一个功能如何切流怎么做比较稳妥？

新功能上线的过程中，在我所处的发布环境中会经历这么几个阶段。首先推上预发环境->灰度环境->生产环境。其中灰度环境和生产环境都是beta发布过程。

beta发布过程且未切流之前

既然是beta发布过程就会存在旧代码和新代码功能运行的现象。针对这种现象，我们需要在一开始设计新功能点时，就要将新功能对原有系统的影响点评估到位。并考虑兼容性。通过切流开关或代码层面设计来做到新功能上线后，在没有切流前做到新老代码共存。但是整个业务语意表象依旧是新功能没上线前的业务语意。

白名单验证

需要考虑的切流步骤一般按如下步骤验证。每一步均在新功能设计之后反复交叉考虑是否想到了此种情况下的兼容性。这样才可以做到新功能点上线后，不会出现不兼容，也不会出现切流后部分数据验证的线上问题。

1）验证beta发布完成之后，此时机器上均为新代码（即包含新功能点的系统）。观察业务语意是否和未发布之前保持一致。（此处特殊重要业务场景可能验证不到位，所以才有了第二步）

2）验证新功能之前要做的第一件事情，即使用存量用户数据验证已有功能。验证已有功能是否依旧和未发布新功能点之前保持一致。（针对特殊且重要业务需要推送存量用户数据做验证。若不存在此种情况，可以直接跳到下一步）

3）推送单个白名单存量数据。验证存量数据在新代码下运行已有业务链路是否符合已有业务语意。

4）推送单个白名单存量数据。验证存量数据在新代码下运行新业务链路是否符合预期业务语意。

5）推送单个白名单新用户数据。验证新数据在新代码下运行已有和新业务业务链路是否符合业务语意。

以上为白名单验证过程，是一个不可以跳过的阶段。跳过白名单直接进入百分比验证，一旦出现问题就会被放大到较大用户范围。切流是直接作用于生产环境的高风险操作。跳步导致的线上问题将按生产故障追责、直接影响绩效。因此必须严格按流程逐步执行、每步留痕。

百分比切流验证

一般白名单验证阶段已经将各种可能不兼容的场景均已经验证通过。接下来就是直接推送百分比验证。

1）推送1% -> 3% -> 10% -> 30% -> 50% -> 99% -> 100%

灰度发布节奏（权威阶梯）

百分比切流不是"一次推到 100%"，而是沿一个逐步放量的阶梯推进。每一档都是用小流量验证确定性的机会，常用阶梯与各档观察要点如下：

档位	目的	观察要点
1%	最小真实流量探路	核心链路错误率/P99 是否抖动；日志有无新增异常栈；新代码的兼容/兜底逻辑是否按预期生效
3%	排除偶发	1% 档的指标表现是否持续稳定；错误是否集中在特定用户群、机型或地域
10%	小规模放量	下游依赖（DB/缓存/RPC）容量水位；缓存命中率；监控告警是否保持静默
30%	半数以下最大档	中间件与连接池压力；新老代码并存期间的数据一致性比对（双写/读旧写新等）
50%	新旧对半	全链路 trace 对比新旧路径性能；灰度分流是否均匀（避免某类用户被打满）
99%	收尾前最后一道闸	仅剩长尾流量走老代码；观察依赖老路径的特殊场景（定时任务、异步补偿）是否切换到位
100%	全量	切流开关状态归档；确认回滚预案作废与老代码下线计划

推进纪律：每一档指标稳定（错误率、P99、业务指标均无劣化）。再观察一个完整业务周期后，才进入下一档。任一档出现异常，立即回滚到上一稳定档，而不是在异常状态下原地修复。

边界说明：本篇讲的是功能级/服务级切流的通用方案。发布工程侧的灰度体系（发布窗口、批次设计、发布卡点与自动化回滚）见 发布工程与灰度体系。机房级/单元级切流（多活容灾场景下的流量调配）见 多活容灾与单元化。