在运维和 DevOps 领域，蓝绿部署（Blue-Green Deployment） 和 金丝雀发布（Canary Release） 是两种常见的无缝升级策略，主要用于减少系统升级过程中的风险，提高系统可用性。
1. 蓝绿部署（Blue-Green Deployment）
概念
蓝绿部署是一种零停机部署策略，核心思想是维护两个环境：
- 蓝色（Blue） ：当前运行的旧版本环境。
- 绿色（Green） ：新版本环境。
在 发布新版本 时：
- 先在 绿色环境 部署新版本，并进行完整的测试。
- 测试通过后，切换流量到 绿色环境（通过 负载均衡 或 DNS 切换）。
- 旧的 蓝色环境 仍然保留，以便在新版本出现问题时快速回滚。
优点
✅ 零停机：切换过程对用户透明，不会影响可用性。
✅ 快速回滚：如果新版本有问题，可以迅速切回蓝色环境。
✅ A/B 测试支持：可以部分流量先切换到新版本进行灰度测试。
缺点
❌ 资源成本高：需要维持两个完整的环境，占用更多计算资源。
❌ 数据一致性问题：数据库需要兼容新旧版本，否则可能导致数据格式不匹配。
适用场景
🔹 适用于 低流量业务 或 有强回滚需求的核心系统（如银行、金融系统）。
2. 金丝雀发布（Canary Release）
概念
金丝雀发布是一种渐进式发布策略，类似于 “灰度发布”。其名称来源于过去矿工带着金丝雀下矿井，当空气有毒时，金丝雀会先死掉，从而预警。
在 发布新版本 时：
- 仅让一小部分用户（如 1%）访问新版本，监测系统稳定性。
- 观察一段时间后（如 无异常），逐步增加新版本流量占比（如 10% → 30% → 50% → 100%）。
- 若发现问题，立即停止金丝雀流量，回退到旧版本。
优点
✅ 降低风险：如果新版本有问题，影响范围仅限于小部分用户。
✅ 渐进式部署：可逐步验证新版本在实际流量下的表现。
✅ 流量控制灵活：可以按用户类型、地域、设备 进行精细化发布。
缺点
❌ 需要流量控制：通常依赖 NGINX、Kubernetes Ingress、Service Mesh（如 Istio） 进行流量拆分。
❌ 监控要求高：需要配合 APM（如 Prometheus、Grafana） 来监控新版本性能、错误率、用户反馈。
适用场景
🔹 适用于 高流量系统（如互联网应用、SaaS 平台），能平滑升级，避免一次性发布带来的风险。
对比总结
| 方案 | 蓝绿部署 | 金丝雀发布 |
|---|---|---|
| 特点 | 一次性切换流量 | 逐步增加流量 |
| 回滚方式 | 直接切回旧环境 | 停止金丝雀流量 |
| 风险控制 | 一旦出错影响全体用户 | 仅影响一部分用户 |
| 资源成本 | 高，需要两套环境 | 低，不需要额外环境 |
| 适用场景 | 低流量、企业级核心系统 | 高流量、互联网应用 |
在 Kubernetes 中如何实现
蓝绿部署
在 Kubernetes 中，可以使用 两个 Deployment（blue/green） ，然后通过 Service 切换 selector：
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app-green # 只需切换这里的 selector
ports:
- port: 80
targetPort: 8080
金丝雀发布
在 Kubernetes Ingress + Istio 中，可以用 VirtualService 进行流量控制：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- my-app.example.com
http:
- route:
- destination:
host: my-app
subset: v1
weight: 90
- destination:
host: my-app
subset: v2
weight: 10
这里 v1 版本接收 90% 流量，v2 接收 10% 流量，随着监控数据稳定，可以逐步调整权重。
总结
- 蓝绿部署 → 一次性切换，适合核心业务，但资源占用较大。
- 金丝雀发布 → 逐步增加流量，适合高流量互联网应用，但需要精细化监控和流量控制。
