为什么你要关心“只让1%的用户先用”

先问一个问题：你上次上线新功能的时候，是不是直接把所有用户都切过去了？然后心里七上八下，生怕出点啥问题？ 传统的“全量发布”就像把一锅热汤直接端到满座的餐厅里——万一洒了，全场遭殃。而灰度发布（也叫金丝雀发布）的做法是：先让一小部分用户（比如1%）用上新版本，观察没问题了，再逐步扩大到5%、20%、50%，最后才全量。 这样做的好处非常直白：

• 万一新功能有bug，影响的只是1%的用户，不是绝大多数
• 发现问题可以秒级回滚，只影响这1%的人
• 用真实用户的流量验证，比测试环境靠谱一百倍 那问题来了：怎么精准地控制只让这1%的用户看到新功能？

方法一：按用户ID取模——最简单粗暴的方式

这是最常用的方法，核心思路是把用户ID当成一个数字，做除法取余数。 具体来说：

1. 每个用户都有一个唯一的ID（比如uid=123456）
2. 把这个ID除以100，看余数是多少
3. 余数为0的那1%用户（比如uid尾号是00的），访问新版本
4. 余数为1-99的用户，继续访问旧版本

举个例子：用户A的uid=123400，123400÷100=1234余0——他进入新版本。用户B的uid=123401，余1——他留在旧版本。 这个方法的好处是简单、稳定、不需要额外存任何状态。同一个用户每次访问都会被分到同一个版本，不会今天看到新功能明天又没了。 代码层面大概长这样：

// 判断用户是否在灰度组
boolean isInGrayGroup = (userId % 100 == 0);
if (isInGrayGroup) {
    // 走新版本
} else {
    // 走旧版本
}

方法二：Nginx权重分流——不改代码也能搞定

如果你不想动业务代码，在网关层用Nginx就能控制流量比例。 Nginx通过weight参数控制不同版本的流量权重：

upstream backend {
    server app-v1:8080 weight=99;  # 99%流量去旧版本
    server app-v2:8080 weight=1;   # 1%流量去新版本
}

这样配置完，100个请求里只有1个会落到新版本。想从1%扩到5%？把weight改成95和5就行。 但这种方式有个小问题：同一个用户每次请求可能会落到不同版本。如果你希望同一个用户始终看到同一个版本，需要结合Cookie或Header来做：

# 根据用户cookie中的user_id做hash，保证同一用户始终路由到同一版本
upstream backend {
    hash $cookie_user_id consistent;
    server app-v1:8080 weight=99;
    server app-v2:8080 weight=1;
}

方法三：功能开关（Feature Flag）——最灵活的方式

如果说前两种方法是“流量切分”，那功能开关就是“功能开关”——新功能代码已经部署上去了，但默认是关着的，只对特定用户打开。 市面上有成熟的工具可以用（比如LaunchDarkly、或者各云厂商的功能开关服务），操作逻辑是：

1. 把新功能代码合并到主干，但用开关包裹起来
2. 在控制台上配置：只对1%的用户开启这个开关
3. 这1%的用户看到新功能，其他人看不到
4. 没问题就逐步调高百分比，直到绝大多数 这种方式最大的好处是不需要重新部署——调个百分比，点一下保存，实时生效。发现有问题，一键关停，影响范围极小。

方法四：服务网格（Istio）——微服务架构的进阶玩法

如果你的系统是微服务架构，用Istio这类服务网格工具可以做到全链路灰度。 简单说就是：给请求打上“灰度”标签，这个标签会沿着整个调用链传递下去，保证灰度的请求从头到尾走的都是新版本服务。 配置示例（Istio的VirtualService）：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - match:
    - headers:
        gray-tag:
          exact: "true"
    route:
    - destination:
        host: my-service
        subset: v2
  - route:
    - destination:
        host: my-service
        subset: v1

然后在网关层，只对1%的用户注入gray-tag: true这个Header。 这种方式适合调用链复杂、服务之间依赖多的系统，能保证灰度流量在整个链路中不被“污染”。

实操建议：从1%开始，逐步放量

不管用哪种方法，标准的放量节奏是这样的：

• 错误率有没有上升
• 响应时间有没有变慢
• 用户反馈有没有异常

最容易踩的3个坑

坑一：1%的用户选得太随机 如果这1%的用户恰好都是某个特殊群体（比如全是iOS用户、全是某个地区的用户），测试结果可能有偏差。建议按用户ID分层抽样，保证样本有代表性。 坑二：只测功能不测数据 如果新功能改了数据库表结构，灰度期间新旧版本共用一套数据库，很容易出问题。要么做好数据兼容，要么把灰度用户的数据隔离到单独的表里。 坑三：没有自动回滚机制 发现问题后手动回滚太慢。建议设置自动回滚阈值——比如错误率超过5%就自动切回旧版本。

总结

控制1%的用户体验新功能，本质就是一句话：把流量切一刀，让一小部分人走新路，大部分人走老路。

• 最简单：用户ID取模，一行代码搞定
• 不改代码：Nginx配权重，运维就能操作
• 最灵活：功能开关，随时调比例随时生效
• 最全面：服务网格，全链路灰度无死角 从1%开始，稳扎稳打逐步放量——这才是现代软件发布该有的样子。

Q1：1%的用户太少，测不出问题怎么办？ A：如果你的日活很大（比如百万级以上），1%就是一万个真实用户，样本量足够了。如果日活很小（比如几千），可以把初始比例调到5%甚至10%，保证有足够的测试样本。 Q2：同一个用户今天进了灰度组，明天会不会被分到旧版本？ A：会的——如果你用的是纯随机比例分配。所以建议用用户ID取模或Cookie Hash的方式，保证同一用户始终落在同一个版本。 Q3：这些方法需要额外花钱吗？ A：用户ID取模和Nginx权重配置都是免费的，不需要买任何额外工具。功能开关和服务网格在云上可能有少量费用，但都有免费额度可以用。