灰度发布操作步骤

一、前端灰度发布

创建不同版本的前端静态资源目录
- 每次前端打包后，生成不同版本的静态资源文件（带有版本号或哈希值）。例如：
  - /static/v1.0/
  - /static/v2.0/
Nginx 配置灰度流量分发
- 可以根据特定的规则（如 Cookie、用户 IP、请求头信息）来将部分用户导向新版前端，其他用户仍然使用旧版本。
- 配置示例：
```
# 通过 cookie 控制用户访问哪个版本的前端
map $cookie_version $frontend_version {
    default "v1.0";  # 默认访问 v1.0 版本
    "v2.0" "v2.0";  # 设置了 version=v2.0 的用户访问新版本
}

# 静态资源版本控制
location /static/ {
    alias /path/to/static/$frontend_version/;
    expires 1y;
    add_header Cache-Control "public";
}

# 为指定用户设置 v2.0 版本的 Cookie
location / {
    if ($request_uri ~* "^/beta") {
        add_header Set-Cookie "version=v2.0; Path=/";
    }
    try_files $uri $uri/ /index.html;
}
```
- 规则解释 ：
  - 通过 map 指令根据 version 的 Cookie 值决定用户访问的静态资源版本。
  - 默认情况下，用户访问 v1.0 版本的前端资源。如果某些用户访问指定的路径（如 /beta），Nginx 会为该用户设置 version=v2.0 的 Cookie，从而引导其访问新版前端。
  - 可以通过用户访问量逐步增加新版本的用户群，逐步完成灰度发布。
A/B 测试的用户分流
- 如果需要更精确的分流机制（如按用户比例进行灰度发布），可以使用 split_clients 指令来根据百分比进行用户分流。
- 示例：
  复制代码
```
split_clients "${remote_addr}" $version_bucket {
    80% "v1.0";  # 80% 的用户访问 v1.0 版本
    20% "v2.0";  # 20% 的用户访问 v2.0 版本
}

location /static/ {
    alias /path/to/static/$version_bucket/;
    expires 1y;
    add_header Cache-Control "public";
}
```
- 规则解释 ：
  - 按照用户 IP 地址的哈希值，80% 的用户将访问旧版前端 v1.0，20% 的用户会访问新版前端 v2.0。
  - 可以根据用户的反馈和监控数据逐步扩大新版本的覆盖比例，直到全量上线。

二、后端灰度发布

准备新版本后端服务
- 部署新版本的后端服务（lib、main.jar 和 config），新版本的服务实例可以独立于旧版本的实例运行，确保服务可用。
- 例如，新版后端实例可以运行在不同的端口或 IP 上：
  - 旧版本后端：http://backend_v1:8080
  - 新版本后端：http://backend_v2:8081
Nginx 负载均衡配置
- 在 Nginx 中设置负载均衡机制，将一部分用户流量引导到新版本的后端。
- 配置示例：
```
upstream backend {
    server backend_v1:8080 weight=8;  # 旧版本流量权重为8
    server backend_v2:8081 weight=2;  # 新版本流量权重为2
}

location /api/ {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
```
- 规则解释：
  - weight 参数控制流量的分配比例。此配置中，旧版本占 80% 流量，新版本占 20% 流量。
  - 可以根据新版本的稳定性逐步调整权重，比如先设置 weight=2，如果没有问题，再逐步增加到 weight=8 或完全切换到新版本。
灰度发布条件控制
- 如果需要更精细的流量控制，可以结合 Cookie 或请求头来指定哪些用户访问新版本的后端。例如，通过某个特定的 Cookie 值将用户引导到新版本的 API。
- 配置示例：
```
map $cookie_version $backend_version {
    default backend_v1;  # 默认访问旧版本
    "v2.0" backend_v2;   # 指定 version=v2.0 的用户访问新版本
}

location /api/ {
    proxy_pass http://$backend_version;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
```
- 规则解释：
  - 通过 map 指令根据 version 的 Cookie 值决定用户访问哪个版本的后端服务。默认用户访问旧版，特定用户访问新版。

灰度发布的监控和验证

灰度发布的关键在于监控系统的运行状态，及时发现和解决问题。以下是一些常见的监控和验证方法：

日志监控
- 在灰度发布过程中，实时监控 Nginx 和后端服务的日志。可以使用 ELK（Elasticsearch, Logstash, Kibana）等日志分析工具，观察用户行为和请求异常。
监控用户反馈
- 通过前端页面中的埋点或 A/B 测试工具（如 Google Optimize、Optimizely），收集用户在使用新旧版本时的行为数据、性能反馈以及问题报告。
自动化回滚
- 如果新版本在灰度发布中出现问题，可以快速将新版本流量回滚到旧版本。这个过程可以通过调整 Nginx 的负载均衡权重或切换版本的 Cookie 来完成。
- 例如，将 Nginx 配置中的 weight=0 设置给新版本后端，即可实现回滚：
  复制代码
```
upstream backend {
    server backend_v1:8080 weight=10;  # 100% 流量回到旧版本
    server backend_v2:8081 weight=0;   # 暂停新版本
}
```

健康检查

配置 Nginx 对后端服务进行健康检查，确保流量只会分配给健康的服务实例。如果发现服务不可用，Nginx 会自动将流量转移到其他正常的服务实例。

健康检查示例：

复制代码

upstream backend {
    server backend_v1:8080 max_fails=3 fail_timeout=30s;
    server backend_v2:8081 max_fails=3 fail_timeout=30s;
}

location /api/ {
    proxy_pass http://backend;
    proxy_next_upstream error timeout invalid_header http_500 http_502;
}

灰度发布总结

前端灰度发布：通过 Nginx 根据 Cookie、IP 或请求路径进行流量分配，逐步引导用户访问新版本的前端。
后端灰度发布：使用 Nginx 负载均衡，将部分流量引导至新版本后端，逐步增加比例，确保新版本稳定后再全量切换。
监控与验证：通过日志分析、用户反馈和健康检查监控灰度发布的效果，及时调整流量或回滚。

通过这些步骤和策略，你可以实现无感的灰度发布，让新版本平稳过渡到所有用户。