几种灰度发布方案

Posted 2022-12-01 第三眼的思绪

方案一

业务层通过参数进行逻辑业务选择，将指定参数分发到新逻辑，另一部分依旧使用旧逻辑，动态调整算法逻辑参数来实现灰度比例。如：对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.业务逻辑耦合较高，代码侵入较大，开发和验证成本都较高，上线后版本要去删除该逻辑代码；
2.如果一次性全量服务上线，可能上线服务存在其他隐藏BUG（如：误修改到老逻辑等）；

方案三

微服务场景下，通过命名空间等措施将生产环境隔离成相互独立但运行逻辑相同的两套环境。
前后变更不兼容或数据连贯性要求高的场景：
通过nginx+Lua进行参数、IP或PATH等路由分发，将指定参数（如：userId）、IP或PATH流量分发到A3/B3（灰度）环境进行灰度验证，旨在将同一客户端流量始终分发到同一环境，通过控制Nginx内分发策略来调整比重。
前后变更兼容且数据连贯性要求不高的场景：
可以纯粹通过权重随机分发流量到灰度环境验证。

优点：
1.对业务代码和前端无侵入
2.策略更新上相对较快
缺点：
1.Nginx配置逻辑控制和工作量偏重
2.需要运维参与
3.灰度独立环境时，如果灰度环境资源不够情况下，可能不适合流量比重逐步放大到100%

方案四

微服务场景下，通过命名空间等措施将生产环境隔离成相互独立但运行逻辑相同的两套环境。
通过前后端定制策略，也可以结合CDN资源策略数据，统一进行前端域名前缀控制，通过nginx根据域名不同进行路由，将grey-bus.xx.com请求路由到灰度环境。

优点：
1.方式简单，降低nginx控制复杂度和后端业务代码基础信息保持的消耗
2.可以作为备用域名使用，当主域名受到攻击时可以进行相对快速切换
缺点：
1.路由策略相对固定，策略更新调整成本和灵活度相对较低，需要更新前端
2.灰度独立环境时，如果灰度环境资源不够情况下，可能不适合流量比重逐步放大到100%
3.多客户端时带来控制逻辑分散，维护成本上升问题

方案五

微服务场景下，通过命名空间等措施将生产环境隔离成相互独立但运行逻辑相同的两套环境。
引入网关层，可以结合配置中心，在网关层进行策略选择，将欲分发的流量控制分发到灰度环境即可。

优点：
1.对业务层代码和前端无侵入
2.策略更新上相对较快，灵活性上有一定限制
缺点：
1.Nginx配置逻辑控制和工作量偏重
2.灰度独立环境时，如果灰度环境资源不够情况下，可能不适合流量比重逐步放大到100%