博客站

在 Nginx 中实现灰度发布（渐进式发布）可以通过多种方式灵活控制流量分配到新旧版本。以下是 6 种主流方法 的详细配置和适用场景，涵盖从简单到复杂的实现方案：

1. 基于 Cookie 的灰度发布

原理：通过 Cookie 标记用户身份，将特定用户路由到新版本。
配置示例：

map $cookie_gray $backend {
    default      backend_old;  # 默认旧版本
    "true"       backend_new;  # 带灰度Cookie的用户访问新版本
}

upstream backend_old { server 10.0.0.1:8080; }
upstream backend_new { server 10.0.0.2:8080; }

server {
    location / {
        proxy_pass http://$backend;
        
        # 首次访问无Cookie时，默认进入旧版（可通过登录态等逻辑动态设置Cookie）
        add_header Set-Cookie "gray=false; Path=/";  # 默认不灰度
    }
}

适用场景：

• 需要精准控制特定用户（如内部员工、测试用户）访问新版本。
• 结合登录系统动态设置Cookie（如 add_header Set-Cookie "gray=true"）。

2. 基于 IP 的灰度发布

原理：按 IP 地址段分流，适合固定IP的用户群体。
配置示例：

geo $gray_ip {
    default         0;
    192.168.1.0/24 1;  # 内网IP访问新版本
    10.0.0.1       1;  # 特定IP访问新版本
}

upstream backend {
    server 10.0.0.1:8080;  # 旧版
    server 10.0.0.2:8080 weight=1;  # 新版（权重控制）
}

server {
    location / {
        if ($gray_ip) {
            proxy_pass http://backend_new;
        }
        proxy_pass http://backend_old;
    }
}

适用场景：

• 内部测试或地域性灰度（如仅开放某办公室IP）。

3. 按比例分流（Nginx Plus 或开源模块）

原理：使用 split_clients 模块随机分配流量。
配置示例：

http {
    # 基于客户端IP的20%流量到新版本
    split_clients "${remote_addr}${date_gmt}" $backend {
        20%     backend_new;
        *       backend_old;
    }

    upstream backend_old { server 10.0.0.1:8080; }
    upstream backend_new { server 10.0.0.2:8080; }

    server {
        location / {
            proxy_pass http://$backend;
        }
    }
}

开源替代方案：
使用 Lua 脚本实现随机分流：

location / {
    access_by_lua_block {
        if math.random(100) <= 20 then  -- 20%流量
            ngx.var.backend = "backend_new"
        end
    }
    proxy_pass http://$backend;
}

4. 基于请求头的灰度发布

原理：通过 HTTP 头（如 User-Agent、自定义头）区分版本。
配置示例：

map $http_user_agent $backend {
    ~*TestClient  backend_new;  # 特定UA访问新版
    default       backend_old;
}

server {
    location / {
        proxy_pass http://$backend;
        proxy_set_header X-Gray "true";  # 告知后端当前流量类型
    }
}

适用场景：

• 移动端特定版本APP灰度。
• 通过前端代码添加自定义头（如 X-Gray: true）。

5. 动态灰度（结合外部服务）

原理：调用外部API决定流量路由，实现动态规则。
配置示例（使用 OpenResty + Redis）：

location / {
    access_by_lua_block {
        local redis = require "resty.redis"
        local red = redis:new()
        red:connect("127.0.0.1", 6379)
        
        -- 根据用户ID查询灰度状态
        local user_id = ngx.var.cookie_userid or ""
        local is_gray = red:get("gray:" .. user_id)
        
        if is_gray == "1" then
            ngx.var.backend = "backend_new"
        end
    }
    proxy_pass http://$backend;
}

优势：

• 实时调整灰度规则无需重启Nginx。
• 支持复杂逻辑（如用户分群、AB测试）。

6. 金丝雀发布（Canary Release）

原理：逐步增加新版本流量比例，同时监控错误率。
配置示例：

upstream backend {
    server 10.0.0.1:8080 weight=95;  # 旧版95%流量
    server 10.0.0.2:8080 weight=5;   # 新版5%流量
}

server {
    location / {
        proxy_pass http://backend;
        
        # 监控新版错误率（Nginx Plus功能）
        health_check uri=/status interval=5s fails=1 passes=1;
    }
}

操作流程：

1. 初始设置5%流量到新版本。
2. 监控错误率和性能（如Prometheus）。
3. 逐步调整权重至100%。

完整配置示例（Cookie + 比例分流）

http {
    # 定义后端
    upstream backend_old { server 10.0.0.1:8080; }
    upstream backend_new { server 10.0.0.2:8080; }

    # 按Cookie和IP综合判断
    map $cookie_gray $gray_by_cookie {
        default 0;
        "true"  1;
    }

    geo $gray_by_ip {
        default 0;
        192.168.1.0/24 1;
    }

    # 最终灰度决策：Cookie优先，其次IP
    map $gray_by_cookie$gray_by_ip $backend {
        ~*1      backend_new;
        default  backend_old;
    }

    server {
        location / {
            proxy_pass http://$backend;
            
            # 灰度用户设置Cookie（实际由业务逻辑设置）
            if ($arg_gray = "true") {
                add_header Set-Cookie "gray=true; Path=/; Max-Age=86400";
            }
        }
    }
}

验证与监控

1. 手动测试：

   # 强制进入灰度
   curl -H "Cookie: gray=true" http://example.com
   

2. 日志分析：

   log_format graylog '$remote_addr - $upstream_addr - $http_user_agent';
   access_log /var/log/nginx/gray.log graylog;
   

3. 监控指标：
   • 各版本请求量对比。
   • 新版错误率（5xx状态码）。
   • 平均响应时间差异。

灰度发布最佳实践

1. 渐进式放量：
   从1%流量开始，逐步增加至100%。
2. 快速回滚机制：
   保留旧版本容器/代码，出现问题时秒级切换。
3. 关键指标监控：
   • 错误率、延迟、CPU/Memory使用率。
4. 用户无感知：
   同一用户始终访问同一版本（通过Cookie保持）。

通过以上方法，可以实现从简单到复杂的灰度发布策略，平衡新功能验证和系统稳定性。