第4章:部署(Deployment)
一、导读
1.1 本章学习目标
第4章讲解生产级软件的部署策略。从蓝绿部署到金丝雀发布,不同的策略有不同的适用场景。
1.2 为什么第四章如此重要
部署是软件交付的最后一环。错误的部署策略会导致服务中断、数据丢失。正确的部署策略可以实现零停机发布。
1.3 核心问题引导
蓝绿部署如何工作?
金丝雀发布的优势是什么?
如何实现零停机部署?
回滚策略如何设计?
二、核心概念详解
4.1 蓝绿部署
两个完全相同的环境:蓝环境和绿环境
部署流程:
1. 当前流量 → 蓝环境(运行旧版本)
2. 部署新版本 → 绿环境
3. 测试绿环境
4. 切换流量 → 绿环境
5. 蓝环境保留作为回滚
优点:零停机、快速回滚
缺点:需要双倍资源4.2 金丝雀发布
逐步将流量从旧版本切换到新版本
部署流程:
1. 部署新版本(少量实例)
2. 将 5% 流量切换到新版本
3. 监控指标,确认正常
4. 逐步增加流量:10% → 25% → 50% → 100%
5. 如有问题,立即回滚
优点:风险可控
缺点:需要负载均衡支持4.3 滚动更新
逐个替换旧版本的实例
部署流程:
1. 启动新版本实例
2. 等待健康检查通过
3. 将流量从旧实例切换到新实例
4. 关闭旧实例
5. 重复直到所有实例更新
优点:资源利用率高
缺点:回滚较慢4.4 回滚策略
回滚决策:
- 错误率超过阈值
- 响应时间超过阈值
- 关键指标异常
回滚方式:
- 蓝绿部署:切换回旧环境
- 金丝雀发布:将流量切回旧版本
- 滚动更新:部署旧版本三、实战案例
4.1 Kubernetes 部署
yaml
# 金丝雀发布
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 1 # 少量实例
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
---
# 渐进式流量切换(使用 Istio)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
http:
- route:
- destination:
host: app-v1
weight: 95
- destination:
host: app-v2
weight: 5四、本章小结
部署策略决定了发布的安全性和效率。蓝绿部署适合关键系统,金丝雀发布适合渐进式验证,滚动更新适合资源敏感的场景。
五、思考与练习
蓝绿部署和金丝雀发布如何选择?
如何实现数据库的零停机迁移?
回滚策略如何设计?
如何处理有状态服务的部署?
如何自动化部署流程?