架构师必备，如何汇总设计灰度方案的策略？

大家好，我是Java烘焙师。本文结合笔者的经验和思考，对灰度方案做个总结，重点介绍AB实验。 灰度在开发流程中非常普遍。先做小流量验证，确认无误后再推全，灰度过程中一旦发现系统异常、或业务指标异常，应立刻回滚。 灰度场景 代码灰度：是最典型的灰度，灰度内做新逻辑，灰度外做旧逻辑 既可以提供v2版本新接口给调用方服务，由调用方来做灰度切换 也可以内部切灰度，做到调用方无感 发版灰度：上线过程中，新版本服务实例不断增加，需考虑兼容新旧协议 配置灰度：修改配置时，按服务实例灰度推送配置变更 灰度模式 数字id尾号灰度：取id最后2位（百分比）、最后3位（千分比）、最后4位（万分比）等 实现方式：id取模，例如 id % 100 < 灰度百分比，则命中灰度 特点：简单，适用于绝大部分技术优化场景 随机灰度：取一部分随机流量做灰度 实现方式：ThreadLocalRandom.current().nextInt(100) < 灰度百分比 之所以使用ThreadLocalRandom、而不是Random，是为了避免多线程竞争用于生成随机数的seed A/B实验 实现方式：分层实验、实验数据收集、离线统计 特点：适用于小流量验证新业务功能的效果，整体方案相对复杂，需要技术基建 id选取 业务id：如用户id、商品id等 设备id：未注册/未登录用户，此时没有用户id，只能取设备的唯一标识 下面重点介绍一下A/B实验。 A/B实验 目的 小流量验证新业务功能，正向显著则推至全量，否则继续迭代优化、或下线，避免功能过于臃肿 用数据作为依据，避免想当然、拍脑袋决策 分层实验 主要目的是为了同时做多个实验，而不是给每个实验均分一部分流量。因为当同时进行的实验变多时，组合数量成倍增加，每个实验分到的流量就很少了。 有这几层结构：实验层、实验、分组 实验层之间正交，可同时进行多个实验层的实验 同一实验层的实验之间互斥，比如命中了实验1-1，就不会命中实验1-2。实验持有0到多个分桶，根据业务id可计算出桶号，进而知道命中哪个实验 同一实验内有多个分组，包括1个对照组，和1到多个实验组，只会命中其中一个分组。分组持有0到多个分桶，根据业务id可计算出桶号，进而知道命中哪个分组 实验层、实验举例： 展示实验层：根据页面进行划分，如首页、搜索页、推荐页、详情页等。每个页面作为一个实验层，每个实验层里可同时做多个展示实验 算法实验层：根据场景进行划分，如相似推荐、搭配购推荐、个性化推荐、搜索排序、广告排序等。每个场景作为一个实验层，每个实验层里可同时做多个算法实验 哈希算法打散 要同时支持多个分层实验，核心在于通过哈希算法将每一层的流量打散，用于实现“均匀分流”和“层间正交”，使得流量在各个实验的效果正负抵消，才能得到真实的对比结果。