Linux 灰度发布过程中的风险控制

灰度发布失败的四大主因：iptables规则顺序错乱致流量不匹配；systemd重启引发服务注册中断；inotifywait因目录缺少x权限导致配置热加载失效；nginx未正确配置real_ip_module致X-Real-IP被覆盖。

灰度发布时流量切分不生效，iptables 规则顺序错乱

linux 灰度发布依赖精准的流量控制，iptables 是最常用手段之一，但规则顺序直接影响匹配结果。新规则默认追加到链尾，若已有 ACCEPT 或 DROP 规则在前，后续灰度规则根本不会触发。

• 插入规则必须用 -I input 1（或指定序号），而非 -A INPUT
• 检查当前链顺序：运行 iptables -L INPUT --line-numbers，确认灰度规则是否排在通用策略之前
• 避免混用 iptables 和 nftables：二者底层不兼容，共存时可能规则被静默忽略
• 生产环境务必先用 --dry-run（如支持）或在测试机验证规则效果，别直接 iptables-restore 上线

systemd 服务重启导致灰度实例被全量替换

用 systemctl restart 重启灰度服务时，旧进程被杀、新进程启动，中间存在不可控的空白期；若服务注册中心未做健康探针延迟或 deregister 保护，注册列表会短暂清空，流量瞬间打到其他节点——等于绕过灰度。

• 改用滚动更新：先 systemctl start myapp-gray@2 启新实例，等就绪再 systemctl stop myapp-gray@1
• 确保服务有 ExecStartPre 检查端口占用，避免新实例启动失败却已注销老实例
• 注册中心客户端需配置 health-check-interval ≥ 30s，且 deregister 延迟（如 eureka 的 eviction-interval-timer-in-ms）大于单次部署耗时

灰度配置热加载失败，inotifywait 监控路径权限不足

很多灰度方案靠监听配置文件变更实现动态切流，但 inotifywait 对监控路径有严格权限要求：不仅需要读取权，还要求对父目录有 execute 权限（即能 cd 进入），否则静默失败，无任何报错。

• 检查路径权限：运行 namei -l /etc/myapp/gray.conf，确认每一级目录都有 x 权限
• 不要监控软链接目标路径本身，应监控软链接所在目录——inotifywait 不跟随 symlink
• 避免监控整个 /etc：inotify 句柄数有限，且易被无关变更干扰；精确到具体配置文件或其所在子目录
• 脚本中加兜底逻辑：每 5 分钟轮询一次 md5sum，防止 inotify 失效后配置长期不更新

灰度日志无法区分真实来源，nginx 透传 X-Real-IP 被覆盖

常见架构是 nginx → 灰度网关 → 后端服务，但若 nginx 配置了 proxy_set_header X-Real-IP $remote_addr 却没处理多层代理，真实客户端 IP 就会被上一跳代理地址覆盖，导致灰度策略（如按 IP 段分流）完全失效。

• 必须启用 real_ip_module，并配 set_real_ip_from 指定可信代理段（如公司内网 CIDR）
• 用 $realip_remote_addr 替代 $remote_addr 传给下游，它才是经过信任链还原后的客户端 IP
• 验证是否生效：curl 请求后查看后端 access log 中记录的 X-Real-IP 值，对比原始请求源 IP
• 注意 Cloudflare 等 CDN 场景：需额外配置 real_ip_header CF-Connecting-IP

事情说清了就结束。灰度不是“加个开关”那么简单，真正难的是让每个环节都对“正在灰度”这件事有感知——从网络层规则顺序、进程生命周期管理、配置加载机制，到日志上下文完整性，漏掉任意一环，风险就藏在看似正常的日志和监控背后。