📚 课程目录第4章灰度发布模式

4. 灰度发布模式：蓝绿部署、金丝雀发布、A/B测试在Knative中的实现原理

灰度发布（Gray Release / Canary Release）是降低上线风险的核心手段。Knative Serving 基于 Revision（不可变快照）和 Traffic 路由（流量百分比分配）提供了三种主流灰度模式的原生支持。理解它们的实现原理，是设计回滚策略的前提。

4.1 三种灰度模式的核心差异

模式	目标	流量切分方式	用户感知	回滚速度	典型场景
蓝绿部署	环境级切换	100% 路由切换	无感知（瞬间切换）	极快（秒级）	重大版本升级、数据库迁移
金丝雀发布	渐进式验证	百分比流量（1%-99%）	部分用户感知	快（调整百分比）	功能验证、性能压测、逐步放量
A/B测试	业务效果对比	基于请求特征（Header/Cookie）	明确分组感知	中等（需修改路由规则）	UI实验、算法对比、转化率测试

  关键认知： 蓝绿和金丝雀关注的是 稳定性 与 风险控制；A/B测试关注的是 业务指标 与 假设验证。Knative 通过 traffic 块中的 tag 和 percent 字段统一了这三种模式的配置模型。

4.2 蓝绿部署：Revision 级别的环境切换

蓝绿部署在 Knative 中表现为两个独立的 Revision（蓝/绿）同时运行，但只有其中一个接收生产流量。切换时只需修改 traffic 配置，将 100% 流量从旧 Revision 指向新 Revision。

实现原理

部署蓝版本（当前生产）：revision-1 承载 100% 流量。
部署绿版本（新版本）：通过 @latest 创建 revision-2，初始流量为 0%。
验证绿版本：通过 tag: green 生成的独立 URL 进行内部测试。
切换流量：将 revision-2 的流量设为 100%，revision-1 设为 0%。
回滚：反向切换流量，将 100% 流量重新指向 revision-1。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    metadata:
      name: revision-2  # 绿版本
    spec:
      containers:
        - image: my-app:v2
  traffic:
    - revisionName: revision-1
      percent: 0        # 蓝版本流量归零
    - revisionName: revision-2
      percent: 100      # 绿版本承载全部流量
      tag: green        # 保留独立访问入口

最佳实践： 蓝绿部署切换后，旧 Revision 应保留至少 5-10 分钟（通过 minScale: 1 防止缩零），以便在发现问题时立即回滚，避免冷启动延迟。

4.3 金丝雀发布：渐进式流量迁移

金丝雀发布通过逐步增加新 Revision 的流量百分比来验证稳定性。Knative 的 traffic 配置支持任意比例的流量分配，且每个 Revision 可以独立设置 tag 用于直接访问。

典型流程

阶段 1（1%）：新 Revision 接收 1% 流量，监控错误率和延迟。
阶段 2（5%）：观察 5 分钟后，无异常则提升至 5%。
阶段 3（20%）：继续观察，逐步提升至 20%。
阶段 4（100%）：全量发布，旧 Revision 流量归零。
回滚：将新 Revision 的百分比直接降为 0%，旧 Revision 恢复为 100%。

# 金丝雀阶段：新版本 5%，旧版本 95%
traffic:
  - revisionName: revision-1
    percent: 95
  - revisionName: revision-2
    percent: 5
    tag: canary

避坑指南： 金丝雀发布期间，必须确保新旧 Revision 的 concurrency 和 timeout 配置一致，否则流量比例变化可能导致请求超时分布不均，引发误告警。

4.4 A/B测试：基于请求特征的路由

A/B测试不依赖百分比，而是根据请求的 Header、Cookie 或 Query Parameter 将流量路由到不同 Revision。Knative 通过 tag 配合外部网关（如 Istio VirtualService）或 Knative 内置的 header-based routing 实现。

Knative 原生实现方式

Knative Service 的 traffic 块支持 tag 定义命名路由，结合 Knative DomainMapping 或 Istio 实现基于 Header 的流量切分。

# 定义两个命名 Revision
traffic:
  - revisionName: revision-1
    percent: 0
    tag: v1
  - revisionName: revision-2
    percent: 0
    tag: v2
  - latestRevision: true
    percent: 100  # 默认路由

然后在 Istio VirtualService 中根据 User-Agent 或自定义 Header 将请求转发到对应的 tag URL：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service-ab
spec:
  hosts:
    - my-service.default.example.com
  http:
    - match:
        - headers:
            x-experiment:
              exact: "v2"
      route:
        - destination:
            host: my-service-v2.default.svc.cluster.local
    - route:
        - destination:
            host: my-service.default.svc.cluster.local

  实现要点： A/B测试的 回滚 不是调整百分比，而是修改路由匹配规则（删除或禁用实验 Header 匹配），使所有流量回归默认 Revision。由于涉及网关配置，回滚速度取决于配置下发延迟（通常 1-5 秒）。

4.5 三种模式的回滚策略对比

模式	回滚操作	回滚时间	数据一致性风险	推荐工具
蓝绿部署	切换 `traffic` 百分比	< 1s	低（全量切换）	Knative Service 原生
金丝雀发布	降低新版本百分比至 0%	< 1s	中（部分用户受影响）	Knative Service + 自动化脚本
A/B测试	删除/禁用 Header 匹配规则	1-5s	高（实验组数据需清理）	Knative + Istio / 网关

4.6 模式选择决策树

在实际项目中，应根据发布内容和风险等级选择灰度模式：

仅配置变更 / 非功能性升级 → 蓝绿部署（最快、最安全）。
新功能上线 / 性能优化 → 金丝雀发布（逐步验证，可随时中止）。
UI/UX 实验 / 算法对比 → A/B测试（需要业务指标反馈）。
紧急修复（Hotfix） → 蓝绿部署（直接切换，不经过渐进流程）。

课程关联： 本章介绍的三种灰度模式是后续第 5-7 章“回滚策略设计”的基础。蓝绿部署对应“全量回滚”，金丝雀发布对应“渐进回滚”，A/B测试对应“条件回滚”。理解实现原理后，才能针对不同模式设计差异化的故障恢复流程。