摘要：灰度发布通过逐步将新版本服务暴露给部分用户，实现风险可控的版本迭代。Nginx作为反向代理服务器，通过路由规则控制流量分发，支持权重分流、特征标识匹配、动态规则等策略，覆盖从简单到复杂的灰度场景。
灰度发布通过逐步将新版本服务暴露给部分用户，实现风险可控的版本迭代。Nginx作为反向代理服务器，通过路由规则控制流量分发，支持 权重分流、特征标识匹配、动态规则 等策略，覆盖从简单到复杂的灰度场景。
原理：通过调整不同服务实例的权重值，按比例分配流量。
适用场景：新版本初步验证、逐步扩大测试范围。
配置示例：
案例：
某电商平台升级支付系统时，先分配10%流量到新版本，通过监控观察错误率和响应时间。若稳定运行48小时，逐步将权重调整为50%→100%。
原理：根据Cookie中的特定标识（如version=V2）路由到新版本。
适用场景：定向用户测试（如内部员工、白名单用户）。
配置示例：
案例：
金融App在测试新投资功能时，仅允许Cookie包含version=V2的用户访问新版，其他用户仍使用旧版。
原理：通过自定义请求头（如X-Gray-User: 1）动态分流。
适用场景：A/B测试或按用户特征分组。
配置示例：
案例：
社交平台在灰度测试新UI时，通过客户端SDK向VIP用户请求头注入X-Gray-User: 1，引导至新版界面。
原理：根据客户端IP段（如内网IP或特定地区）分流。
适用场景：区域性测试或内部环境验证。
配置示例：
案例：
企业ERP系统升级时，仅允许办公网IP（192.168.1.0/24）访问新版本，避免影响外部分支机构。
原理：通过Lua脚本实时查询Redis中的灰度规则（如用户ID白名单）。
适用场景：需要实时调整规则的精细化控制。
配置示例：
案例：
在线教育平台通过Redis动态管理灰度用户，运营人员可在后台实时添加/移除测试用户，无需重启Nginx。
背景：某电商需升级购物车服务，要求平滑过渡且不影响用户体验。
实施步骤：
1. 权重分流阶段：初始分配10%流量到新版本，监控错误率与性能指标。
2. 定向测试阶段：通过Cookie标记核心用户（如高价值用户），确保关键路径稳定性。
3. 全量切换阶段：逐步调整权重至100%，并通过Nginx的-s reload平滑加载配置。
在K8S环境中，可通过Nginx Ingress的注解实现更灵活的灰度策略：
# 常规IngressapiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: main-ingressspec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: old-service port: 80# Canary Ingress（灰度规则）apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: canary-ingress annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "20" # 20%流量到新版本spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: new-service port: 80优势：支持动态调整权重、基于Header/Cookie分流，与K8S服务发现无缝集成。
通过以上方案，Nginx可实现从简单到企业级的灰度发布需求。建议优先选择 权重分流+动态规则 的组合策略，兼顾灵活性与稳定性。
来源：散文随风想
