几种灰度发布方案

方案一

业务层通过参数进行逻辑业务选择，将指定参数分发到新逻辑，另一部分依旧使用旧逻辑，动态调整算法逻辑参数来实现灰度比例。如：对userId取模（即L=userId%10）,L<N(N=1)的流量走新逻辑（即10%流量），动态配置+缓存实现，逐步调大N的值。

缺点：
1.业务逻辑耦合较高，代码侵入较大，开发和验证成本都较高，上线后版本要去删除该逻辑代码；
2.这种模式下

2.1 如果一次性全量服务上线，再进行参数计算流量控制，可能上线服务存在其他隐藏BUG；
2.2 如果仅上线替换一部分服务，分布式微服务集群中可能对业务的灰度连贯性不友好。如：期望同一用户请求始终在灰度（->A3->B3->C3->..）环境，实际可能变成->A3-B1->C2。

方案二

引入接口版本号，新老版本接口并存，比如 /v1/api 和 /v2/api。前端使用/v2/api版本，当过去一段稳定期后（可以是登录态时间失效后），就可下掉/v1/api版本。

优点：
1.不存在兼容性问题，风险较低
缺点：
1.业务逻辑耦合较高，代码侵入较大，开发和验证成本都较高&#x