全栈攻城狮

Appearance

蓝绿部署与灰度发布 ​

发布新版本是线上风险最高的操作之一。蓝绿部署与灰度发布把"一次性全量切换"变成"可控的、可观察的、可回退的"过程。本文拆解蓝绿、滚动、灰度三种发布方式的原理与落地，覆盖 K8s、Istio、Nginx 三种实现路径。

发布方式全景 ​

三种发布方式对比 ​

方式原理风险资源占用适用场景
滚动更新逐个替换旧版本低低常规发布
蓝绿部署新旧两套并行，整体切换中高（双倍资源）关键业务、数据库兼容要求高
灰度发布小流量先验证，逐步放大最低中大版本、高风险变更

一、蓝绿部署 ​

原理 ​

蓝绿部署模型：
  ├─ 蓝色环境（Blue）：当前线上版本
  ├─ 绿色环境（Green）：新版本（全新部署一套）
  └─ 验证 Green 通过后，把流量从 Blue 整体切到 Green

关键点：
  ├─ 两个环境并行运行，同一时刻只有一个接流量
  ├─ 切换是"瞬时"的（改路由/负载均衡指向）
  └─ 回滚：把流量切回 Blue（旧环境还在）
流量切换示意：
  用户 → 负载均衡 ──▶ Blue（v1，旧版）    ← 切换前
  用户 → 负载均衡 ──▶ Green（v2，新版）    ← 切换后（验证通过）
  出问题 → 切回 Blue

优点与缺点 ​

优点：
  ├─ 切换瞬间完成，几乎无感知
  ├─ 回滚极快（切回旧环境）
  ├─ 新旧环境完全隔离，便于验证
  └─ 无"新旧共存"的兼容问题

缺点：
  ├─ 需要双倍资源（两套环境都运行）
  ├─ 数据库兼容：新旧版本可能写同一库
  ├─ 长连接/会话：切换时在途请求要处理
  └─ 切换是"全量"，没有小流量验证

适用场景 ​

蓝绿适合：
  ├─ 数据库结构不变的小版本升级
  ├─ 有独立资源池、能承受双倍成本
  ├─ 需要快速回滚的场景
  └─ 不适合：数据库 schema 变更（新旧版本都连库）

二、Kubernetes 滚动更新 ​

原理 ​

K8s Deployment 滚动更新：
  ├─ 默认策略 RollingUpdate
  ├─ 逐步创建新版本 Pod，就绪后删除旧版本 Pod
  └─ 过程中新旧版本共存（短暂）

参数：
  ├─ maxSurge：最多超出的新 Pod 数
  ├─ maxUnavailable：允许同时不可用的旧 Pod 数
  └─ 例：replicas=5, maxSurge=1, maxUnavailable=0
      先起 1 个新 Pod → 就绪 → 停 1 个旧 Pod → 循环

滚动更新的问题 ​

滚动更新的风险：
  ├─ 新旧版本共存期 → 兼容问题
  │     ├─ 新版本连接的请求打到旧版本（反向同理）
  │     └─ 依赖新接口/新数据的请求会失败
  ├─ 无法控制"放多少流量"
  └─ 回滚靠 rollout undo（逐步回滚）

改进：
  ├─ 配合 readiness 探针：新 Pod 未就绪不接流量
  ├─ 分批发布：先更新 1 个副本观察，再全量（手动控制）
  └─ 复杂场景升级到灰度发布

分批发布示例 ​

bash
# 1. 更新到新版本，但只扩 1 个副本验证
kubectl set image deployment/order-service \
  order-service=registry/order-service:2.0.0

# 2. 观察新 Pod 健康与日志
kubectl get pods -l app=order-service
kubectl logs deployment/order-service -c order-service --tail=100

# 3. 验证通过 → 继续滚动到全量
#    验证失败 → 回滚
kubectl rollout undo deployment/order-service

三、灰度发布（Istio 权重路由） ​

原理 ​

灰度发布核心：按权重/条件分流
  ├─ 90% 流量 → v1（旧版）
  ├─ 10% 流量 → v2（新版）
  ├─ 观察新版指标（错误率、延迟、业务数据）
  └─ 逐步放大：10% → 30% → 50% → 100%

Istio 实现：VirtualService + DestinationRule ​

yaml
# DestinationRule：定义子集（版本）
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
yaml
# VirtualService：按权重路由
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 90          # 90% 流量到 v1
        - destination:
            host: order-service
            subset: v2
          weight: 10          # 10% 流量到 v2

灰度比例调整 ​

调整权重（灰度放大）：
  ├─ 10% → 30% → 50% → 100%
  ├─ 每次调整观察指标，验证通过再放大
  └─ 出问题：权重调回（100% 回到 v1）

Kiali 可视化：
  ├─ 流量拓扑：实时看到 v1/v2 流量比例
  ├─ 错误率、延迟对比
  └─ 辅助灰度决策

条件灰度（按请求特征） ​

yaml
# 按 Header 灰度：特定用户组走新版
http:
  - match:
      - headers:
          x-user-group:
            exact: internal   # 内部测试用户走 v2
    route:
      - destination:
          host: order-service
          subset: v2
  - route:
      - destination:
          host: order-service
          subset: v1
      weight: 100
条件灰度形式：
  ├─ 按 Header（用户组、设备、渠道）
  ├─ 按 Cookie / 用户 ID
  ├─ 按地区（区域灰度）
  └─ 按 IP（白名单灰度）

四、Nginx 网关灰度策略 ​

没有 Istio 时用 Nginx 灰度 ​

Nginx 灰度方案：
  ├─ 上游两组服务器（v1 组、v2 组）
  ├─ 按权重 / 条件分发
  └─ 适合：网关层灰度、无 Service Mesh 的架构

按权重灰度 ​

nginx
upstream order_backend {
    server order-v1.example.com:8080 weight=9;   # 90%
    server order-v2.example.com:8080 weight=1;   # 10%
}

server {
    listen 80;
    location /order/ {
        proxy_pass http://order_backend;
    }
}

按 Header 灰度 ​

nginx
# 按请求头分流：x-gray: v2 走新版
upstream order_v1 {
    server order-v1.example.com:8080;
}
upstream order_v2 {
    server order-v2.example.com:8080;
}

server {
    listen 80;
    location /order/ {
        if ($http_x_gray = "v2") {
            proxy_pass http://order_v2;
            break;
        }
        proxy_pass http://order_v1;
    }
}

网关灰度结合 Nacos ​

Spring Cloud 场景的灰度（无 Istio）：
  ├─ Nacos 实例带 version 元数据
  ├─ Gateway/LoadBalancer 按 version 路由
  ├─ 或 Nginx 按条件分流到不同网关
  └─ 适合轻量灰度，无需 Service Mesh

五、灰度发布完整流程 ​

发布步骤 ​

灰度发布标准流程：
  1. 部署 v2 到环境（不接流量）
  2. 健康检查通过
  3. 内部测试流量先行（条件灰度 1%）
  4. 观察指标：错误率、延迟、业务成功数
  5. 逐步放大：10% → 30% → 50%
  6. 全量切换：100% v2
  7. 观察稳定期（如 30 分钟）
  8. 清理 v1

灰度观察指标 ​

灰度验证指标：
  ├─ 技术指标：
  │     ├─ 请求错误率（对比 v1）
  │     ├─ P95/P99 延迟
  │     ├─ 服务可用性（SLA）
  │     └─ 资源使用（CPU/内存）
  ├─ 业务指标：
  │     ├─ 下单成功率
  │     ├─ 支付转化率
  │     └─ 核心业务完成量
  └─ 日志与告警：异常日志、告警量对比

灰度回滚 ​

灰度期回滚：
  ├─ 权重调回（100% v1）
  ├─ 秒级生效，v2 无流量
  └─ 保留 v2 排查问题

全量后回滚：
  ├─ 权重切回 v1（若 v1 环境仍在）
  ├─ 或 rollout undo
  └─ 数据库兼容问题需特殊处理

六、发布方式选型 ​

选型决策：
  ├─ 小改动、常规发布 → K8s 滚动更新
  ├─ 关键业务、要秒级回滚 → 蓝绿部署
  ├─ 大版本、高风险变更 → 灰度发布（Istio/网关）
  ├─ 数据库 schema 变更 → 蓝绿/灰度要配合兼容策略
  │     （新旧版本需共存读写）
  └─ 组合：滚动 + 灰度（K8s 分批 + 网关权重）

数据库兼容原则：
  ├─ 前向兼容：新版本能读旧数据
  ├─ 后向兼容：旧版本能读新数据（回滚安全）
  └─ 迁移分步：加列 → 双写 → 切换 → 清理

总结 ​

蓝绿、滚动、灰度是同一目标的不同实现：让发布可控、可观察、可回退。蓝绿用双环境换瞬时切换与秒级回滚，滚动用增量替换控制资源，灰度用权重/条件分流把风险摊薄到小流量上验证。K8s 提供滚动与分批能力，Istio 提供精细的权重与条件路由，Nginx 则适合轻量网关灰度。发布前想清楚兼容性与回滚路径，任何发布方式都能安全落地。