软件架构与思考

👉 所有文章
高性能 高性能设计模式
数据库 数据库分库分表指南 MySQL 建表参考 MySQL 初始化数据的一些方案 数据版本号
分布式 ID 分布式 ID 生成方案探讨
缓存 缓存 使用数据版本号保证缓存是最新数据 基于redis的二级缓存
微服务 如何实现远程调用 RPC 协议中的数据签名验签和加解密方案探讨 关于服务间调用循环依赖的一些思考 我所理解的负载均衡 一致性哈希 基于Redis的分布式会话管理系统 如何部署服务 灰度发布 如何区分上游和下游 日志级别
算法与协议 一个可扩展的 MQ 消息设计 Dynamo涉及的算法和协议 写时复制
任务分发 Gearman入门 如何使用redis构建异步任务处理程序
安全 关于对账的一些理解 一个简单可靠的 Dubbo 请求/响应数据签名方案
其他 使用卫语句减少 if else 嵌套

灰度发布


什么是灰度发布

灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。 -- 百度百科

灰度发布,可以在下面两个阶段进行:

  1. 部署服务新版本
  2. 发布新功能

部署服务新版本

假设该某服务有10个实例,有新功能要发布,流程如下:

  1. 旧版本的10个实例保持运行状态
  2. 为新版本生成10个实例
  3. 将旧版本的流量逐步切换到新版本,比如以5%的步长进行切换,切换过程中注意观察服务

或者是:

  1. 旧版本的10个实例保持运行状态
  2. 为新版本生成1个实例
  3. 将旧版本的部分流量切换到新版本服务的实例中,观察无问题,则继续为新版本生成实例、切换流量,至旧版本无流量位置。

发布新功能

部署服务新版本后,我们的新功能也可以逐步灰度。

一个常见的灰度模式:白名单+百分比灰度

假设现在有一款 App,在后台每个用户都有一个唯一的数字标识,我们称之为 user id。现在该app开发了一个新功能,很多用户都安装了新版本的app。

该 App 每天会定时去后端服务查询当前登录用户是否可以用这个新功能(当然也可以是后台服务将是否可以使用新功能推送给每个用户)。

假设按照百分比灰度,整个流程如下:

  1. 后台添加若干白名单用户,这些用户都是自己人,先进行验证线上新功能;
  2. 后台将灰度比例从0调整为1,此后 user_id 最后两位为 00 的用户可以使用新功能;
  3. 观察无问题,后台将灰度比例从1调整为2,此后 user_id 最后两位为 00、01 的用户可以使用新功能;
  4. 依次类推,直至灰度比例变成100。

注意,实际场景中,也会有千分比灰度、万分比灰度。 千分比,看user_id 最后3位;万分比灰度,看 user_id 最后4位。

注意:千分之十、百分之一灰度是不一样的

从数值上来看,10/1000等于1/100。

但是两者灰度命中的用户不是完全相同的。比如对于 user id 100009,这是在 10/1000 灰度内的,但不在 1/100 灰度中。


( 本文完 )

文章目录