4Release It!(第2版)

部署

部署策略

蓝绿部署金丝雀发布滚动更新回滚策略

🎯 AI 时代的学习建议:不要只读理论。理解这一章的设计动机(为什么需要这个概念?)和边界条件(什么情况下会失效?)。当 AI 生成的代码涉及这些概念时,你能判断它是否用对了场景。AI 能帮你总结内容,但无法替代你亲手阅读、思考、建立直觉的过程。

第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

四、本章小结

部署策略决定了发布的安全性和效率。蓝绿部署适合关键系统,金丝雀发布适合渐进式验证,滚动更新适合资源敏感的场景。


五、思考与练习

蓝绿部署和金丝雀发布如何选择?

如何实现数据库的零停机迁移?

回滚策略如何设计?

如何处理有状态服务的部署?

如何自动化部署流程?


4/7部署
0%