大厂常用的几种灰度发布方案

编辑导语：灰度，就是存在于黑与白之间的一个平滑过渡的区域。对于互联网产品来说，上线和未上线就是黑与白之分，而实现未上线功能平稳过渡的一种方式就叫做灰度发布。不少大厂在产品上线前都会进行灰度测试，本文作者为大家总结了大厂常用的几种灰度发布方案。

什么是灰度发布？百度百科的解释是这样的：

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。

AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

从上述可以看出，灰度发布的作用有以下几点：

结合工作中使用到的灰度发布实践和对其他大厂的灰度发布调研，总结了以下灰度发布方案。

一、灰度发布的划分

灰度发布如果按照端来分的话，可以分为web前端、客户端、服务端灰度。

无论是哪种灰度，一般需要满足以下2点要求：

1. 需要一个放量配置，给产品/运营等工作人员配置放量策略；
2. 需要做到同一个用户始终访问的是同一个版本的代码，如果同个用户上个请求访问的是A版本，下个请求访问的是B版本，就可能会出问题。

1. web前端灰度

假设我们的前端资源存放在CDN上面：我们每次发布一个新版本，就把资源增量式地上传到CDN，然后给它分配一个唯一的版本号，再把所有的版本号存储起来。当处理请求时，根据动态配置的分流策略来决定用户使用哪个版本。

比如分流策略是放量10%，即新版本随机放量给10%的用户使用，当用户首次命中资源版本号时，需要把用户id和版本号的映射关系存储起来（可存到cookie），这样就能保证同个用户上次请求和下次请求访问到的都是同个版本的代码。

那如果线上有紧急bug需要修复，又要重新发布新版本，该如何处理当前灰度的状态？是赶紧结束上一个灰度然后全量发布还是一起发上去同时灰度？一般来说，再有新版本发布或者放量策略发生变化时，应该重新分流灰度。

2. 服务端灰度

服务端灰度分为兼容变更灰度和不兼容变更灰度。

1）兼容变更

兼容变更又可分为物理灰度和逻辑灰度。

• 物理灰度：物理灰度比较简单，根据机器维度进行灰度，直接部署新老版本在不同机器，流量均匀地打在新老版本上面。这种方式虽然简单，但不适用于不兼容变更；
• 逻辑灰度：逻辑灰度就是根据更精确的流量策略来控制流量，这种灰度一般要写一定的灰度代码。这种方式能比较精确地控制流量，但是增加了一定的灰度代码，灰度完成后要删除相关灰度代码，有点麻烦。

2）不兼容变更

不兼容变更指的是更改了当前功能，即接口逻辑跟之前版本发生很大变化，必须要前后端同时发布，否则会有一段时间服务不可用。

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

3. 客户端灰度

web前端和服务端灰度发布可以在客户无感知的情况下平滑进行，遇到问题也可以快速回滚，但是移动客户端涉及到用户的主动安装行为，所以上述的方式已经不适用。

如果一个带有bug的安装包全量发布出去，一旦有问题，我们只能快速定位问题来提醒用户安装新版本，是否安装取决于用户，所以客户端灰度发布是非常有必要的。

客户端在启动时，会向灰度系统发起请求，灰度系统根据客户端传过来的参数和当前的放量策略来决定是否要给客户端升级提醒。一般会根据以下几种策略来决定给予用户升级提醒：

1. 根据用户设备的系统和应用版本；
2. 根据渠道：发布到不同应用市场的app都会被打上渠道标签，所以可以根据渠道来区分用户；
3. 根据设备ID和用户ID。

通过设备ID主要是为了控制提醒频率，用户ID主要是为了区分出特性用户，比如对活跃用户发送提醒。

二、灰度放量策略

流量策略一般分为以下几种：

1. 按流量百分比

先到先得的方式比如限制10%的用户体验的是新版本，90%的用户体验的是老版本。先访问网站的用户就优先命中新版本，直到流量用完为止。

2. 按人群划分

1. 按用户id、用户ip、设备类型比如可通过平时的埋点上报数据得知用户的pv、uv、页面平均访问时长等数据，根据用户活跃度来让用户优先体验新版本，进而快速观察使用效果。
2. 按地域、性别、年龄等用户画像比如可通过用户的性别、年龄等做下新老版本的对比效果来看看目标用户在新版本的使用年龄段，性别范围是多少。

3. 按渠道划分

比如根据用户的注册来源来放量。

三、灰度发布的代价

通过上面的讲解，可以看到一个完整的灰度发布，包括前端、后台都需要额外的代码量去实现，如果只有几万的用户，要去实现这样一套灰度发布，代价是比较高的。

但如果是百万～亿级用户，灰度发布是很值得的，它不仅能降低新版本bug的风险，还能通过版本对比，推出最好效果的版本应用。