3. 蓝绿发布原理：流量切换机制与滚动发布对比

蓝绿部署（Blue-Green Deployment）的核心思想是维护两套完全独立的生产环境——蓝环境（当前运行版本）与绿环境（新版本），通过一次性或渐进式的流量切换完成发布。这种机制从根本上解决了传统滚动发布中“新旧共存”带来的兼容性风险。

3.1 蓝绿部署的流量切换机制

流量切换是蓝绿部署的执行关键，分为前置条件、切换动作和回滚保障三个阶段。

3.1.1 流量切换的三种模式

3.1.2 流量切换的底层实现

在 Kubernetes 生态中，蓝绿切换通常通过 Service 的 selector 切换或 Istio VirtualService 权重路由实现。以下为两种典型实现方式：

# 方式一：Kubernetes Service selector 切换（全量切换）
# 假设蓝环境标签：version: blue，绿环境标签：version: green
# 切换前 Service 指向 blue
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
    version: blue   # 切换时改为 green
  ports:
  - port: 80
    targetPort: 8080

# 切换命令（更新 Service selector）
kubectl patch service myapp-svc -p '{"spec":{"selector":{"version":"green"}}}'

# 方式二：Istio VirtualService 权重路由（渐进切换）
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1   # 蓝环境
      weight: 90
    - destination:
        host: myapp
        subset: v2   # 绿环境
      weight: 10     # 逐步调至 100

3.2 蓝绿部署 vs 滚动发布：核心差异

滚动发布（Rolling Update）是 Kubernetes 默认的更新策略，逐个替换 Pod 实例；蓝绿部署则保持两套完整环境。两者在以下维度存在本质区别：

3.3 蓝绿部署的流量切换流程（SVG 架构图）

下图展示了从“蓝环境运行”到“绿环境就绪”，再到“流量切换”和“蓝环境待命”的完整流程：

3.4 蓝绿部署在服务目录中的关键属性

平台工程团队应在服务目录中为每个服务记录以下蓝绿部署相关属性，作为门禁系统的输入参数：

• 切换模式：全量 / 渐进 / 灰度，决定门禁通过后的流量切换策略
• 观察周期：蓝环境保留时间（默认 15 分钟，核心服务建议 30 分钟）
• 自动回滚阈值：错误率超过 X% 或延迟超过 Y ms 时自动切回蓝环境
• 预热时间：绿环境启动后到接受流量的等待时间（用于缓存预热、连接池初始化）
• 资源配额：蓝绿两套环境各自的 CPU/内存/存储需求，用于成本核算
• 兼容性检查：DB Schema 是否向前兼容、API 是否支持双版本

3.5 蓝绿部署 vs 滚动发布：决策矩阵

以下决策矩阵帮助平台工程团队在服务目录中为每个服务选择合适的发布策略：