配置灰度发布和回滚怎么实现？
简化版
灰度发布把不可变配置版本先分配给稳定的小范围目标，确认版本收敛和业务指标后再逐级扩量。 回滚不是删除新版本，而是创建一个更高的发布版本，内容引用已验证的历史配置。 选择规则、目标集合、观察窗口、停止条件和回滚动作都要纳入审计。
详细版
发布模型包含内容版本、发布序列、作用域和灰度规则。 服务端计算每个客户端的当前期望版本，客户端拉取完整内容、校验后原子切换并上报实际版本。 灰度先选固定实例或稳定哈希桶，避免目标随每次请求漂移。
门禁同时检查客户端收敛、错误率、延迟、资源和业务指标。 失败时暂停扩量，按预案回滚或人工处置。 回滚也要经过通知、拉取和收敛过程，不能认为点击后瞬间全局恢复。
完整版教学
一、灰度解决爆炸半径
动态配置可在数秒内影响所有实例，错误扩散往往比代码部署更快。 灰度先暴露小范围真实行为，为发现问题和回滚争取时间。 它不能证明绝对正确，只能以受控风险换取生产证据。
灰度的核心不是“慢慢发”，而是每一步都有明确目标、观察和刹车。
二、版本与发布分离
内容版本描述配置字节，发布记录描述何时把哪个内容分配给什么目标。 同一内容可被多次发布，回滚也应形成新的发布序列。
release 501: content v20 -> canary
release 502: content v20 -> 25%
release 503: content v18 -> all (rollback)不可变历史保证审计和重放，禁止直接修改已发布版本。
三、稳定选择灰度目标
可按实例白名单、租户白名单或稳定哈希桶命中。 哈希输入要稳定，例如 tenantId；随机选择会让同一主体在新旧规则间跳变。
| 策略 | 适用场景 | 注意点 |
|---|---|---|
| 实例名单 | 基础设施参数 | 重启后身份变化 |
| 租户名单 | 业务规则 | 防止跨租户串用 |
| 哈希百分比 | 大规模扩量 | 固定盐和分桶数 |
目标集合快照进入发布记录，便于解释谁本应命中。
四、客户端如何应用
客户端获取本实例期望版本，下载完整配置并校验身份、摘要、schema 和业务约束。 构造不可变对象后原子替换，再上报 appliedVersion。 通知乱序时仍以服务端当前期望版本为准。 复杂资源如连接池先建立新资源，验证后切换并排空旧资源。
五、扩量门禁
例如按 5 个实例、5%、25%、100% 四阶段扩量。 每阶段至少观察 10 分钟，并覆盖必要业务周期。 门禁可要求该阶段目标集合中的健康可达实例收敛率 100%、错误率增量小于 0.2%、P99 增量小于 10%；失败、未知、离线和确认缩容实例要分别列出，不能通过缩小分母美化结果。 样本太小时业务指标不稳定，应延长观察或选择代表性租户。
六、回滚的正确语义
回滚创建新发布版本，内容从已验证历史版本复制或引用。 客户端看到新的发布序列后应用旧内容，审计保留谁因何回滚。 若新配置已产生不可逆数据，恢复旧值只能阻止后续影响，历史结果仍需补偿。 多个有关联的键应按配置集回滚，防止组合不合法。
七、故障与观测
同时监控期望版本、实际版本、各阶段目标数、加载失败、配置年龄和业务指标。 发布控制器重启后从持久化状态恢复，不能误把未完成阶段当成功。 通知失败由周期拉取补齐；离线实例重连后读取当前期望版本。 停止扩量与回滚应幂等，并处理并发发布冲突。
八、常见误区与追问
- 误区：随机挑请求就是配置灰度。 配置常在实例级加载，目标必须稳定。
- 误区：客户端都下载成功即可扩量。 还要观察真实业务指标。
- 误区：回滚就是删除最新版本。 应创建新发布序列并保留历史。
- 误区：回滚能撤销所有影响。 已产生的数据或外部调用可能需要补偿。
- 追问：灰度实例重启怎么办？ 按稳定身份或规则重新计算期望版本。
- 追问：两人同时发布怎么办？ 使用 baseVersion 和发布锁避免覆盖。
- 追问：通知丢失怎么办？ 周期拉取当前期望状态并最终追平。
九、加强记忆
- 内容不可变，发布记录单独版本化。
- 用稳定规则确定灰度目标。
- 客户端校验、原子应用并上报版本。
- 收敛与业务指标共同控制扩量。
- 回滚是新发布，不能抹除历史，也不能替代业务补偿。