3. 灰度基础设施搭建：网关层灰度路由配置、服务网格灰度支持、配置中心动态开关

灰度切换不是靠写死代码就能搞定的。你得在基础设施层面，把「流量分发」和「配置控制」这两件事彻底解耦出来。说白了，灰度基础设施就是三个核心组件：网关、服务网格、配置中心。它们各自负责什么？怎么搭？坑在哪？这一章我跟你掰扯清楚。

3.1 网关层灰度路由配置

网关是流量的第一道关卡。所有外部请求都从它过，所以在这里做灰度路由，成本最低、效果最直接。我个人习惯把网关灰度路由分为两层：全局路由和细粒度路由。

3.1.1 全局路由：基于 Header/Cookie 的简单分流

最常见的做法，就是让网关根据请求头里的某个标识（比如 X-Canary、X-Version）或者 Cookie 值，把流量打到不同的后端集群。我在项目中遇到过，有些团队直接用 Nginx 的 map 指令配合 proxy_pass 来做，简单粗暴，但维护起来有点头疼。

这里给一个基于 OpenResty 的示例配置：

-- 灰度路由规则
local canary_header = ngx.var.http_x_canary
local target_upstream = "default_upstream"

if canary_header == "v2" then
    target_upstream = "canary_upstream"
elseif canary_header == "v3" then
    target_upstream = "canary_v3_upstream"
end

ngx.var.target = target_upstream

嗯，这里要注意：全局路由只适合做粗粒度的分流。比如新版本上线，先切 5% 的流量过去看看。如果你需要根据用户 ID、地域、设备类型来做更精细的控制，那就要用到细粒度路由了。

3.1.2 细粒度路由：基于 Lua 脚本或插件

细粒度路由的核心，是在网关层维护一份「灰度规则表」。这张表可以存在 Redis 里，也可以从配置中心拉下来。网关每次收到请求，都去查一下这个用户该走哪个版本。

我曾经踩过一个坑：把灰度规则直接写在 Nginx 配置文件里，每次改规则都要 reload 网关。结果有一次 reload 导致连接中断，线上出了几分钟的 502。从那以后，我再也不敢把规则写死在配置文件里了。

正确的做法是：规则动态化。比如用 Redis 的 Hash 结构存储用户灰度映射：

-- 从 Redis 获取用户灰度版本
local redis = require("resty.redis")
local red = redis:new()
red:set_timeout(1000)
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
    ngx.log(ngx.ERR, "failed to connect redis: ", err)
    return
end

local user_id = ngx.var.cookie_user_id
local version = red:hget("gray:user:version", user_id)
if version then
    ngx.var.target = version .. "_upstream"
end

3.2 服务网格灰度支持

网关层搞定了入口流量，但服务之间的调用怎么办？比如订单服务调用了库存服务，我想让订单的灰度版本只调用库存的灰度版本。这时候，服务网格就派上用场了。

服务网格（Service Mesh）的核心是 Sidecar 代理。它接管了服务间的所有通信，你可以在 Sidecar 上配置流量路由规则，实现「灰度流量闭环」。说白了，就是让灰度请求在整个调用链上都走灰度版本，不会串到稳定版本里去。

3.2.1 Istio 的 VirtualService 和 DestinationRule

以 Istio 为例，灰度路由主要通过两个 CRD 实现：VirtualService 和 DestinationRule。前者定义路由规则，后者定义子集（subset）。

下面是一个典型的灰度配置：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
  - order-service
  http:
  - match:
    - headers:
        x-canary:
          exact: "v2"
    route:
    - destination:
        host: order-service
        subset: v2
  - route:
    - destination:
        host: order-service
        subset: stable
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  subsets:
  - name: stable
    labels:
      version: stable
  - name: v2
    labels:
      version: v2

这个配置的意思是：如果请求头里有 x-canary: v2，就把请求路由到打了 version: v2 标签的 Pod 上；否则走稳定版本。

3.2.2 灰度流量闭环：从网关到网格

你想想看，如果网关和服务网格各自为政，灰度规则就割裂了。我建议的做法是：网关负责识别灰度用户，并在请求头里注入灰度标识；服务网格负责根据这个标识做内部路由。这样，灰度标识就能在整个调用链上传递下去。

具体流程是这样的：

1. 用户请求到达网关，网关根据规则判断该用户走灰度版本。
2. 网关在请求头里添加 x-canary: v2，然后转发给后端服务。
3. 后端服务（比如订单服务）收到请求，Sidecar 根据 x-canary: v2 将请求路由到订单的 v2 版本。
4. 订单 v2 版本调用库存服务，Sidecar 再次根据 x-canary: v2 将请求路由到库存的 v2 版本。

这样一来，灰度流量就形成了一个闭环，不会污染稳定版本。

3.3 配置中心动态开关

灰度基础设施的第三个支柱，是配置中心。它负责管理灰度规则的动态变更。你想想看，如果每次改灰度比例都要重启服务，那还叫什么灰度？

配置中心的核心能力就两个：配置下发和配置监听。服务启动时从配置中心拉取灰度规则，运行时监听配置变化，实时更新。

3.3.1 灰度开关设计

我个人习惯把灰度开关设计成三层结构：

全局开关用来一键关闭灰度，防止出问题时灰度流量扩散。服务级开关控制每个服务的灰度比例。用户级开关则用于白名单测试。

3.3.2 基于 Nacos 的动态配置示例

以 Nacos 为例，灰度配置可以这样设计：

// 配置数据结构
{
  "gray": {
    "enabled": true,
    "services": {
      "order-service": {
        "ratio": 10,
        "version": "v2"
      },
      "inventory-service": {
        "ratio": 5,
        "version": "v2"
      }
    },
    "whitelist": ["user_1001", "user_1002"]
  }
}

服务端代码监听配置变化：

@NacosConfigListener(dataId = "gray-config", group = "DEFAULT_GROUP")
public void onGrayConfigChange(String config) {
    GrayConfig grayConfig = JSON.parseObject(config, GrayConfig.class);
    // 更新本地灰度规则缓存
    this.grayRuleCache = grayConfig;
    log.info("灰度配置已更新: {}", grayConfig);
}

3.4 灰度基础设施架构总览

最后，我用一张图把这三部分串起来。你一看就明白它们是怎么协同工作的。

这张图里，用户请求先到网关，网关根据配置中心的规则判断灰度身份，然后注入灰度标识。请求进入服务网格后，Sidecar 根据标识逐跳路由，确保灰度流量在整个调用链上保持一致。配置中心则负责动态调整所有规则，不需要重启任何服务。

嗯，这套基础设施搭好了，灰度切换就成功了一半。剩下的就是业务代码层面的配合了，那是后面章节要聊的内容。