一、蓝绿发布（Blue-Green Deployment）

蓝绿发布是准备两套完全相同的生产环境：

• 蓝环境（Blue）：当前正在提供服务
• 绿环境（Green）：新版本环境

发布流程：

用户
  │
  ▼
负载均衡
  │
  ├── Blue（V1）← 当前运行
  └── Green（V2）← 提前部署

部署完成后：

用户
  │
  ▼
负载均衡
  │
  ├── Blue（V1）
  └── Green（V2）← 切换流量

特点

优点

• 发布速度快
• 回滚速度快
• 风险较低
• 不影响用户

缺点

• 资源消耗翻倍
• 需要两套完整环境
• 数据库升级需要额外处理

---

面试回答

蓝绿发布是同时维护两套生产环境，旧版本运行在蓝环境，新版本部署到绿环境。验证无误后通过负载均衡或Ingress切换流量到绿环境。如果发现问题可以快速切回蓝环境，实现秒级回滚。

---

二、灰度发布（Canary Deployment）

灰度发布是让部分用户先访问新版本。

例如：

90%流量 → V1
10%流量 → V2

验证稳定后：

70%流量 → V1
30%流量 → V2

继续扩大：

50%流量 → V1
50%流量 → V2

最终：

100%流量 → V2

---

特点

优点

• 风险最低
• 可以观察真实用户反馈
• 发现问题影响范围小

缺点

• 实现复杂
• 需要流量管理能力
• 监控要求高

---

面试回答

灰度发布是按照一定比例逐步引流到新版本，例如先放5%流量到V2，观察监控指标、错误率和用户反馈，没有问题再逐步扩大到20%、50%、100%。出现异常时只影响少量用户。

---

三、两者区别

对比项	蓝绿发布	灰度发布
运行版本	两套完整环境	两个版本同时运行
流量切换	一次性切换	按比例逐步切换
回滚速度	非常快	较快
风险	中等	最低
资源消耗	高	较低
实现复杂度	简单	较复杂
用户感知	全量用户同时升级	部分用户先升级

---

四、Kubernetes 中如何实现

蓝绿发布

创建两个 Deployment：

deployment-blue
deployment-green

Service 默认指向 Blue：

selector:
  app: blue

切换时修改：

selector:
  app: green

实现秒级切流。

---

灰度发布

最简单方式：

两个 Deployment

v1: 9 Pod
v2: 1 Pod

Service 同时选择：

selector:
  app: web

Kubernetes 自动实现：

90% -> V1
10% -> V2

但这种方式不够精准。

---

五、企业生产环境真实做法

你面试时最好这样回答：

在生产环境中，我们主要使用 Istio 实现灰度发布。通过 VirtualService 配置流量权重，例如先让5%的流量进入新版本，观察 Prometheus 和 Grafana 监控指标，包括响应时间、错误率、CPU和内存使用情况，确认稳定后逐步扩大到20%、50%、100%。如果出现异常，通过修改权重立即回退到旧版本。对于重大版本升级或架构迁移，我们会采用蓝绿发布，提前准备完整的新环境，验证通过后一次性切流，实现快速回滚。

Istio 灰度发布示例

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app
spec:
  hosts:
  - app
  http:
  - route:
    - destination:
        host: app
        subset: v1
      weight: 90
    - destination:
        host: app
        subset: v2
      weight: 10

面试官如果继续追问：

“你们生产环境是怎么做不停机发布的？”

可以回答：

我们采用 Kubernetes Deployment RollingUpdate 配合 Istio 灰度发布。普通版本升级使用滚动更新保证不停机；核心业务系统升级采用灰度发布逐步放量；涉及重大架构变更时采用蓝绿发布，确保能够快速回滚，从而保证业务连续性。这样既兼顾资源成本，又能降低发布风险。