灰度策略设计
灰度策略，说白了就是让新功能「小范围试水」。我在好几个密码迁移项目里都被问过：「灰度到底怎么做才稳？」 其实核心就两点——规则定义 + 比例控制。规则决定谁能进，比例决定进多少人。
灰度规则实现
常见的灰度规则有三种：按用户、按IP、按版本。我习惯把它们看成三个不同维度的筛子，可以单独用，也可以组合用。
- 按用户灰度：基于用户ID或用户组。比如只让VIP用户先切新密码存储。我以前在金融项目里就踩过坑——只按用户ID取模，结果测试账号全是灰度组，根本没覆盖真实用户。
- 按IP灰度：基于请求来源IP。适合内部员工先测，或者特定区域先行。注意了，IP可能变化（比如NAT出口），我曾经遇到分公司所有员工IP被误判为同一个，导致灰度范围一下子炸开。
- 按版本灰度：基于客户端版本号或API版本。适合App升级场景，新版客户端才能走新流程。老版本走老路径，这样兼容性压力最小。
我的建议：不要只用一种规则。实际项目中我都是「用户ID + 版本号」双因子，再配合比例切量，出错概率低很多。
灰度比例控制
比例控制才是灰度的心脏。你划了规则，但人群多大、流量多少，都得靠比例来调。
实现方式很简单——Hash取模。把用户标识（比如UID）哈希到0~99，设定一个阈值，小于阈值就进灰度组。举个例子：
# 伪代码示例
def in_grayscale(user_id, threshold_percent=10):
# 一致性哈希，保证用户每次结果一致
slot = hash(str(user_id)) % 100
return slot < threshold_percent这么做的好处是：同一用户每次请求结果一致，不会出现「上午在灰度、下午不在」的混乱。比例可以动态调整，从1%逐步推到100%，观察指标没问题再放量。
注意：比例控制不是线性放量就完了。我见过团队直接从1%跳到20%，结果日志爆了。建议小步快跑：1% → 5% → 10% → 25% → 50% → 100%，每个阶段至少观察一个业务周期。
灰度策略设计流程
我一般按以下步骤设计灰度策略，你可以参考：
- 确定灰度目标：是想验证功能正确性，还是评估性能影响？目标不同，规则和比例也不同。
- 选择规则组合：按场景选一种或多种。我个人倾向「用户ID+版本号」，因为ID稳定，版本能兜底。
- 设定初始比例：通常从1%或5%开始，安全第一。
- 设计回滚机制：如果灰度出问题，能一键切回旧逻辑。我习惯把灰度开关做成配置中心的热配项。
- 监控与迭代：灰度期间重点看错误率、延迟、用户反馈。达标后再逐步提升比例。
下面这张图概括了整个灰度决策链路，你一看就明白：
三种规则的对比
实际选型时，可以根据下表快速决策：
| 规则类型 | 适用场景 | 稳定性 | 典型问题 |
|---|---|---|---|
| 按用户 | 账号级别权限、分批发布 | 高（ID不变） | 测试用户遗漏 |
| 按IP | 内部办公、区域试点 | 中（IP可能变） | NAT导致范围失控 |
| 按版本 | App端升级、接口版本迁移 | 高（版本号稳定） | 版本覆盖率不足 |
我踩过的一个坑： 曾经仅按版本号灰度，结果老版本用户一直不走新流程，但新版本用户也只有一小部分——因为版本号是写死的，没有配合用户维度。最终灰度推进极慢。后来改成「版本号 + 用户ID取模」，才把流量铺开。
嗯，灰度规则就是这样。关键是规则要稳、比例要小、监控要全。你下次设计灰度时，可以先从最简单的单规则开始，跑通了再加组合。比例嘛，从1%起步，别贪快。