3. 灰度发布架构设计：网关层灰度、服务网格灰度、应用层灰度、数据层灰度

灰度发布并非单一维度的流量切换，而是一个从入口到数据存储的分层治理过程。每一层承担不同的职责，也面临不同的风险。本章从架构视角拆解四个核心层次：网关层（流量入口）、服务网格层（通信基础设施）、应用层（业务逻辑）、数据层（持久化状态），并给出每一层的灰度设计模式。

3.1 四层灰度架构总览

下表对比了各层在灰度发布中的核心职责、典型技术选型与风险等级：

3.2 网关层灰度：流量入口的精准分流

网关层是灰度流量的第一道关卡。所有外部请求必须经过网关，因此在此层做灰度分流具有全局可控、零侵入的优点。常见的灰度策略包括：

• Header 路由：网关根据请求 Header（如 X-Canary: true）将流量转发到灰度集群。
• Cookie 路由：基于用户 Cookie 中的灰度标识（如 user_id 哈希）进行分流。
• 权重路由：按百分比（如 5% 流量到 v2 版本）随机分配。
• IP/地域路由：仅允许内测用户 IP 或特定地域访问灰度版本。

3.3 服务网格层灰度：Sidecar 代理的流量治理

服务网格层将灰度能力下沉到基础设施层面。每个服务实例旁挂一个 Sidecar 代理（如 Envoy），由控制平面（如 Istio）统一下发灰度路由规则。应用代码无需感知灰度逻辑，实现了业务与治理的完全解耦。

服务网格层支持的高级灰度模式：

• 权重路由：通过 VirtualService 配置 v1 和 v2 版本的流量权重。
• 流量镜像：将灰度流量复制一份发送到新版本，但不影响真实响应，用于无风险验证。
• Header 匹配路由：根据请求 Header 精确匹配到特定版本子集。
• 故障注入：在灰度版本上注入延迟或错误，测试服务容错能力。

# Istio VirtualService 灰度权重配置示例
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: user-service
        subset: v2
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90
    - destination:
        host: user-service
        subset: v2
      weight: 10

3.4 应用层灰度：特性开关与业务逻辑分支

应用层灰度是最灵活的灰度方式，适用于无法通过网关或网格层精确控制的业务逻辑。核心手段是特性开关（Feature Flag）和配置中心动态下发。

应用层灰度典型场景：

• 按用户灰度：仅对 VIP 用户或内测用户开放新功能。
• 按请求属性：根据请求参数（如 city=beijing）决定走新逻辑。
• 按时间窗口：在指定时间段内开启灰度，过期自动回退。
• 渐进式放量：从 1% 逐步增加到 100%，每个阶段自动评估错误率。

// 应用层特性开关示例（Java + Togglz）
import org.togglz.core.Feature;
import org.togglz.core.annotation.EnabledByDefault;
import org.togglz.core.annotation.Label;

public enum ApiFeatures implements Feature {
    @Label("新版订单结算流程")
    @EnabledByDefault
    NEW_CHECKOUT_FLOW,

    @Label("AI 推荐引擎 v2")
    AI_RECOMMEND_V2;
}

// 业务代码中使用
if (FeatureContext.getFeatureManager().isActive(ApiFeatures.NEW_CHECKOUT_FLOW)) {
    return newCheckoutService.process(order);
} else {
    return legacyCheckoutService.process(order);
}

3.5 数据层灰度：Schema 兼容与双写策略

数据层灰度是风险最高的层次。数据库 Schema 变更、缓存结构变化、消息队列格式升级，一旦出错可能导致数据丢失或全量回滚困难。数据层灰度必须遵循向前兼容和可回退原则。

数据层灰度核心策略：

3.6 四层灰度协同策略

在实际项目中，灰度发布往往是多层协同的结果。以下是一个典型的四层灰度协同流程：

1. 网关层根据用户 ID 哈希，将 5% 的流量标记为灰度流量，注入 X-Gray-Tag: canary-v2 Header。
2. 服务网格层根据该 Header，将灰度流量路由到 v2 版本的 Pod 实例。
3. 应用层读取 X-Gray-Tag Header，决定是否启用新业务逻辑（如新结算流程）。
4. 数据层在灰度应用写入时，触发双写策略，同时写入旧表和新表。