nginx

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > nginx > Nginx灰度发布

Nginx实现灰度发布的多种策略分享

作者：眷蓝天

灰度发布是一种重要的策略,它允许我们在不影响所有用户的情况下逐步推出新功能或更新,本文介绍了Nginx实现灰度发布的多种策略,有需要的小伙伴可以了解下

基于权重的灰度发布（适合逐步验证新版本）

灰度发布：又名金丝雀发布；逐步地用新版本替代老版本

蓝绿发布：直接用新版本替代老版本

原理：通过upstream模块的weight参数分配流量比例，逐步将新版本服务器权重调高。

配置示例：

 upstream backend {
     server 192.168.1.100 weight=90;  # 旧版本
     server 192.168.1.101 weight=10;  # 新版本
 }
 server {
     listen 80;
     location / {
         proxy_pass http://backend;
     }
 }

操作步骤：

适用场景：简单验证新版本稳定性，无需区分用户群体。

基于客户端请求的灰度发布（精准控制用户群体）

Cookie或Header标识

原理：根据请求中的Cookie或Header值（如version=V2）转发到特定服务器。

配置示例：

 upstream stable { server 192.168.1.100; }
 upstream canary { server 192.168.1.101; }
 ​
 map $http_cookie $group {
     ~* version=V2 canary;
     default stable;
 }
 ​
 server {
     listen 80;
     location / {
         proxy_pass http://$group;
     }
 }

适用场景：A/B测试或定向邀请用户试用新功能。

IP地址过滤

原理：将特定IP的请求转发到新版本服务。

配置示例：

server {
    listen 80;
    set $backend "stable";
    if ($remote_addr = "10.0.0.1") {  # 允许特定IP访问新版本
        set $backend "canary";
    }
    location / {
        proxy_pass http://$backend;
    }
}

适用场景：内部测试或定向开放给特定区域用户。

组合策略（灵活控制流量）

原理：结合权重和请求标识，优先匹配特定用户，剩余流量按比例分配。

配置示例：

map $http_cookie $group {
     ~*version=V2 canary;
     default $default_group;
 }
 ​
 upstream backend {
     server 192.168.1.100 weight=90;
     server 192.168.1.101 weight=10;
 }
 ​
 server {
     listen 80;
     set $default_group backend;
     location / {
         proxy_pass http://$group;
     }
 }

适用场景：既有定向用户测试，又有逐步放量的需求。

操作注意事项

配置生效：修改Nginx配置后需执行nginx -s reload重新加载。

优先级：基于Cookie/Header的规则通常优先于权重分配。

监控与回滚：通过日志监控新版本服务状态，若异常需快速回滚配置。

方法补充

灰度发布（金丝雀发布）是指让部分用户（如内部测试用户、特定区域用户）先使用新版本，验证无误后再逐步扩大范围，最终全量切换。Nginx作为反向代理，可以在流量入口层实现灵活的灰度策略。

以下是几种主流实现方式，按复杂度从低到高排列。

基于客户端 IP 的灰度

最简单的方式，通过 geo 模块或 if 语句判断源 IP，将指定 IP 段的请求转发到新版本后端。

upstream backend_stable {
    server 10.0.1.1:8080;
}
upstream backend_canary {
    server 10.0.1.2:8080;
}
server {
    listen 80;
    server_name example.com;
    # 定义灰度 IP 列表（可用 geo 模块维护）
    geo $canary_ip {
        default 0;
        192.168.1.100 1;   # 单个 IP
        10.0.0.0/24   1;   # IP 段
    }
    location / {
        if ($canary_ip) {
            proxy_pass http://backend_canary;
            break;
        }
        proxy_pass http://backend_stable;
    }
}

缺点：IP 列表不易维护，且对于 NAT 后的用户无法精确控制。

基于 Cookie 的灰度（最常用、最精准）

在用户首次访问时，服务端或 Nginx 设置一个 canary 的 Cookie，标记该用户是否进入灰度组。后续所有请求根据 Cookie 值分流，保证同一用户的体验一致。

upstream backend_stable { ... }
upstream backend_canary { ... }
server {
    listen 80;
    # 根据 Cookie 判断
    set $group "stable";
    if ($cookie_canary = "true") {
        set $group "canary";
    }
    location / {
        proxy_pass http://backend_$group;
    }
}

如何设置 Cookie？ 通常需要配合后端程序（如 Java、Python）在响应头中写入 Cookie。也可以在 Nginx 中通过 add_header 和内部重定向实现（较复杂）。

基于请求头（Header）的灰度

适用于移动端 App、API 调用等场景，客户端在请求中携带特定 Header（如 X-Canary: true），Nginx 根据 Header 分流。

upstream backend_stable { ... }
upstream backend_canary { ... }

server {
    listen 80;

    set $group "stable";
    if ($http_x_canary = "true") {
        set $group "canary";
    }

    location / {
        proxy_pass http://backend_$group;
    }
}

基于权重（随机百分比）的灰度

利用 Nginx 的 split_clients 模块，根据某个标识（如用户的 IP 或 User-Agent）计算一个 0-99 的哈希值，然后按百分比分流。这种方式不依赖 Cookie，同一用户多次访问会被分流到同一版本（确定性）。

upstream backend_stable { ... }
upstream backend_canary { ... }

split_clients "${remote_addr}${http_user_agent}" $variant {
    5%      "canary";   # 5% 的用户进入灰度组
    *       "stable";
}

server {
    listen 80;

    location / {
        proxy_pass http://backend_$variant;
    }
}

注意：split_clients 使用 MurmurHash2 算法，分布均匀，且对相同输入输出一致，适合 A/B 测试。

基于 URL 参数（如 ?version=v2）

适用于手动指定版本号进行调试的场景，例如内部测试人员在 URL 后加 ?gray=1。

server {
    listen 80;

    set $group "stable";
    if ($arg_gray = "1") {
        set $group "canary";
    }

    location / {
        proxy_pass http://backend_$group;
    }
}

动态分流（结合 Lua + Redis）

对于更复杂的策略（如按用户 ID 哈希、按地域、按设备类型），可以借助 OpenResty 或 Nginx 的 Lua 模块（lua-nginx-module），从 Redis 或数据库中读取用户灰度配置。

示例（需要安装 lua-resty-redis）：

location / {
    access_by_lua_block {
        local redis = require "resty.redis"
        local red = redis:new()
        red:connect("127.0.0.1", 6379)
        local user_id = ngx.var.cookie_userid or "0"
        local is_canary = red:get("canary:" .. user_id)
        if is_canary == "1" then
            ngx.var.backend = "canary"
        else
            ngx.var.backend = "stable"
        end
    }
    proxy_pass http://backend_$backend;
}

结合 Kubernetes Ingress 的灰度

在 K8s 环境中，可以使用 Nginx Ingress Controller 的 canary 特性，通过注解实现权重、Header 或 Cookie 的灰度。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"   # 10% 流量到灰度服务
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp-stable
          servicePort: 80
---
# 另一个 Ingress 代表灰度版本
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  ...
  backend:
    serviceName: myapp-canary
    servicePort: 80

策略对比与选择建议

策略精确度复杂度适用场景
IP 段低低内部测试、特定办公室
Cookie高中用户粒度灰度，保证体验一致
Header高低API 网关、移动端
权重（split_clients）高中A/B 测试，按比例切流
URL 参数高低手动调试、压测
Lua + Redis极高高复杂业务规则，实时生效
K8s Ingress高中云原生环境

通用注意事项

总结

通过以上方法，可有效平衡系统稳定性和新功能验证需求。具体实现时需根据业务场景选择最合适的策略。

到此这篇关于Nginx实现灰度发布的多种策略分享的文章就介绍到这了,更多相关Nginx灰度发布内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文