---
tags: [microservice, canary-release, blue-green, traffic-routing, istio]
create time: 2026-05-05
---

# 流量治理

## 概述

灰度发布（也叫金丝雀发布）是降低变更风险的核心手段。它让你将新版本逐步推向一小部分用户，观察指标正常后再全量。

> [!question] 如何安全地上线？
> 你修复了一个紧急 Bug，但这次改动涉及核心支付链路。直接全量发布一旦出问题损失巨大。有没有办法先小范围验证，确认没问题再放量？

## 灰度策略全景

```mermaid
flowchart LR
    A["🟢 v1 (稳定版)<br/>95% 流量"] --> B["🔵 v2 (测试版)<br/>5% 流量"]
    B --> C{"监控指标?"}
    
    C -- "✅ 一切正常" --> D["逐步放量<br/>10% → 25% → 50%"]
    C -- "❌ 错误率飙升" --> E["自动回滚到 v1 🔄"]
    
    D --> F{"全部放量至 100%"}
    F --> G["🟢 v2 成为新稳定版"]
```

### 常见灰度策略对比

| 策略 | 描述 | 优点 | 缺点 | 适用场景 |
|------|------|------|------|---------|
| **按百分比** | 随机分配 N% 流量到新版本 | 简单粗暴，覆盖面广 | 可能只命中特定用户 | 通用场景 |
| **按用户 ID** | 指定用户/内部账号走新版 | 可精准控制测试范围 | 样本不够代表性 | 内部验收阶段 |
| **按 Header** | `x-canary: true` 路由到新版本 | 灵活性最高 | 需要客户端配合 | QA / AB 测试 |
| **按地域** | 某个城市/机房的新版本 | 地域性问题的理想试验场 | 地域偏差大 | 全球化部署 |
| **按设备类型** | iOS 新用户先用新版 | 覆盖目标人群 | 样本有限 | 移动端发版 |

## 蓝绿 vs 灰度

> [!summary] 两种发布策略对比
>
> | 维度 | 蓝绿部署 | 灰度发布 (金丝雀) |
> |------|---------|-----------------|
> | **切换方式** | 一次性全切 | 逐步放量 |
> | **资源消耗** | 双倍（新旧并行） | 初期少量副本 |
> | **回滚速度** | 秒级（切回 LB 即可） | 同样秒级 |
> | **风险等级** | 中高（全量暴露问题） | 低（渐进式） |
> | **适合场景** | 大型变更、重大版本 | 日常迭代、高风险链路 |

### 蓝绿部署流程

```mermaid
stateDiagram-v2
    [*] --> Blue: 初始状态
    Blue --> DeployGreen: 部署 v2 到 Green 环境
    DeployGreen --> TestGreen: 验证 Green
    TestGreen --> Switch: 切换入口流量
    Switch --> Green: 全部流量到 Green/v2
    Green --> CleanupBlue: 删除 Blue/v1
    CleanupBlue --> [*]
```

### 金丝雀发布流程

```mermaid
graph TB
    S1["v1 运行中<br/>100% 流量"]
    S2["部署 v2<br/>5% 流量"]
    S3["监控 15min"]
    S4{"P99 延迟 < SLA?"}
    
    S4 -- 否 --> Rollback["回滚 v2 🔄"]
    S4 -- 是 --> S5["放量 25%"]
    S5 --> S6["监控 30min"]
    S6 --> S7{"错误率 < 0.1%?"}
    S7 -- 否 --> Rollback
    S7 -- 是 --> S8["放量 50%"]
    S8 --> S9["监控 1h"]
    S9 --> S10{"全项达标?"}
    S10 -- 是 --> S11["100% 全量 ✅"]
    S10 -- 否 --> Rollback
    
    style Rollback fill:#ffebee
    style S11 fill:#e8f5e9
```

## 高级路由规则

### Istio VirtualService

```yaml
# 灰度规则：header 携带 canary=true 的用户走 v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-route
spec:
  hosts: ["order-service"]
  http:
    # 灰度规则
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: order-service
            subset: v2
          weight: 100
    # 默认：全部走 v1
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 100
```

### 权重路由示例

```yaml
# 按比例分流
http:
  - route:
      - destination:
          host: order-service
          subset: v1
        weight: 90
      - destination:
          host: order-service
          subset: v2
        weight: 10
```

## 流量治理的其他维度

除了发布策略，流量治理还包括：

| 能力 | 说明 |
|------|------|
| **熔断降级** | 下游不可用时自动降级，参见 [[02-服务治理/容错模式/README]] |
| **限流** | 保护上游不因过量请求被打垮，参见 [[02-服务治理/容错模式/README]] |
| **重试** | 对瞬态故障自动恢复，参见 [[02-服务治理/容错模式/README]] |
| **黑白名单** | IP 级别访问控制 |
| **A/B Testing** | 基于用户分组的长期实验 |

## 灰度发布的量化决策依据

> [!tip] 必须有可量化的观测指标作为决策依据
> 
> 不要凭感觉放量，让数据说话：
> 
> | 指标 | 阈值参考 | 告警级别 |
> |------|---------|---------|
> | **错误率** | < 0.1% (v1 baseline 对比) | > 1% 立即回滚 |
> | **P99 延迟** | ≤ v1 × 1.1 | > v1 × 1.3 暂停放量 |
> | **CPU/Memory** | 在 limits 的 70% 以内 | > 85% 扩容 |
> | **下游依赖成功率** | > 99.5% | < 95% 熔断 |

## 关联笔记

- [[02-服务治理/API网关/README]] — API Gateway 的路由和权重分发
- [[04-可观测性/Metrics监控/README]] — 灰度期间的监控面板设计
- [[05-部署运维/SRE实践/README]] — 基于 SLO 的发布决策