灰度发布网络配置？

本文目录导读：

1. 网关/负载均衡层配置（最常用）
2. 服务网格层配置（Kubernetes + Istio/Linkerd）
3. DNS 层配置（粗粒度/大版本升级）
4. 客户端/SDK 层配置（移动端应用）
5. 灰度发布网络配置的核心注意事项
6. 总结：选择哪种网络配置？

灰度发布（灰度发布，又称金丝雀发布）的网络配置，核心目标是将一小部分流量（或特定用户）引导至新版本的服务实例，而大部分用户仍使用旧版本。

实现这一目标,通常涉及DNS（域名系统）、负载均衡器、网关、服务网格等网络层面的配置，以下是几种主流方案及其配置要点：

网关/负载均衡层配置（最常用）

在 Nginx、HAProxy、Kong、Spring Cloud Gateway 或云厂商的 SLB（服务器负载均衡器）/ALB（应用负载均衡器） 上，通过权重或条件路由实现。

方案 A：基于权重的灰度（无差异化）

• 原理：后端挂载两个服务组（旧版本组、新版本组），配置流量比例为 9：1（90% 去旧版，10% 去新版）。
• Nginx 配置示例：

  upstream old_version {
      server 10.0.1.1:8080 weight=9;  # 旧版 90%
  }
  upstream new_version {
      server 10.0.2.1:8080 weight=1;  # 新版 10%
  }
  server {
      listen 80;
      location / {
          # 使用 split_clients 模块按比例分配（更精确）
          split_clients "${remote_addr}${http_user_agent}" $version {
              90%     old;
              *       new;
          }
          proxy_pass http://$version;
      }
  }

方案 B：基于请求头的灰度（精准控制）

• 原理：根据 HTTP Header（如 X-Canary: true）、Cookie、UA（用户代理）或 IP 进行路由，测试人员带上特定 Header 即可访问新版。
• Nginx 配置示例：

  upstream old_version {
      server 10.0.1.1:8080;
  }
  upstream new_version {
      server 10.0.2.1:8080;
  }
  server {
      listen 80;
      location / {
          if ($http_x_canary ~* "true") {  # Header 中包含 X-Canary: true
              proxy_pass http://new_version;
              break;
          }
          proxy_pass http://old_version;
      }
  }

• 云厂商 ALB/API Gateway：可以在控制台配置“基于 Header 或 Query String 的转发规则（转发到不同的目标组 Target Group）”。

服务网格层配置（Kubernetes + Istio/Linkerd）

这是目前云原生最推荐的灰度方式，无需修改代码，通过 Sidecar 代理劫持流量。

Istio 配置示例（按权重灰度）：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
  - my-service
  http:
  - match:  # 可选：基于 Header 的灰度（精准控制）
    - headers:
        canary:
          exact: true
    route:
    - destination:
        host: my-service
        subset: v2 # 新版
      weight: 100 # 匹配到的 Header 全走新版
  - route:  # 默认流量，按权重分配
    - destination:
        host: my-service
        subset: v1 # 旧版
      weight: 90
    - destination:
        host: my-service
        subset: v2 # 新版
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

关键配置点：

1. DestinationRule：定义两个子集（Subset），通过 Pod 标签 version: v1 和 version: v2 区分。
2. VirtualService：定义流量的路由规则（按 Header 或按权重）。

DNS 层配置（粗粒度/大版本升级）

• 原理：通过 DNS 轮询或加权解析。
• 场景：常用于多机房、多集群的大版本升级或容灾切换，流量从 old.example.com 逐渐切换到 new.example.com，或在同一个域名下配置不同 IP 的权重。
• 缺点：生效慢（DNS 缓存）、无法精确到请求 Header。
• 配置示例（假设使用 AWS Route53 或 阿里云 DNS）：
  • 将 api.example.com 解析到 IP1 (旧版), 设置权重 90。
  • 将 api.example.com 解析到 IP2 (新版), 设置权重 10。

客户端/SDK 层配置（移动端应用）

对于手机 App（Android/iOS）等强客户端，网络配置在服务端下发。

• 配置中心：使用 Apollo / Nacos 存储灰度参数。
• 下发规则：服务端下发接口返回 {"new_api_url": "https://new.api.com/v2"}。
• 客户端逻辑：根据设备 ID 或账号 ID 哈希，决定是否使用新的 new_api_url 进行请求。

灰度发布网络配置的核心注意事项

1. 会话保持（Sticky Session）：
   • 如果用户首次请求走了新版节点,下一次请求（如登录后的操作）绝不能落到旧版（否则 Session 会丢失）。必须确保基于 Cookie 或 IP 的一致性哈希（ip_hash 在 Nginx 中，或 Istio 的 consistentHash）。
2. 数据库兼容性：

   新代码可能产生新的数据格式,旧版代码必须能正确读取或忽略新数据，网络层面无法解决，需要代码层做向前兼容（如数据库字段加新列、加默认值）。

3. 监控与回滚：
   • 配置灰度后,必须实时观察新版本的流量、错误率（Error Rate）、延迟（Latency）。
   • 网络配置中预留快速回滚机制：如 Nginx 配置准备好 upstream fallback，或在 Istio 中将权重一键改为 0。
4. 灰度隔离：
   • 如果是基于 Header 的灰度，必须确保灰度环境（新版本）能正确调用生产环境的共享服务（如 Redis、MQ），或者灰度流量只访问灰度专用的共享资源（如 canary_redis_db）。

选择哪种网络配置？

建议：如果是刚接触灰度发布，可以先从网关层（Nginx/Kong）配置基于 Header 或权重的灰度开始，这样不需要改动服务代码，纯粹是网络配置操作，风险最小。

标签： 网络配置