81 lines
2.7 KiB
Markdown
81 lines
2.7 KiB
Markdown
---
|
||
title: "Zero-Downtime Deployment"
|
||
type: concept
|
||
tags: [DevOps, Deployment, Reliability]
|
||
sources: [engineering-devops-automator]
|
||
last_updated: 2026-05-01
|
||
---
|
||
|
||
# Zero-Downtime Deployment
|
||
|
||
## 定义
|
||
零停机部署是一组软件部署策略，旨在更新应用程序时保持服务持续可用，避免部署过程中用户请求失败或服务中断。
|
||
|
||
## 主要策略
|
||
|
||
### 蓝绿部署（Blue-Green Deployment）
|
||
- **原理**：维护两套完全相同的环境（蓝和绿），新旧版本各占一套
|
||
- **切换**：通过负载均衡器将流量一次性从旧环境切换到新环境
|
||
- **回滚**：切换回旧环境即可实现秒级回滚
|
||
- **优点**：简单、切换快速、回滚容易
|
||
- **缺点**：资源成本翻倍
|
||
|
||
### 金丝雀发布（Canary Deployment）
|
||
- **原理**：先将新版本部署到小部分服务器/用户，逐步扩大范围
|
||
- **切换**：基于流量比例（如 5% → 20% → 100%）
|
||
- **监控**：每个阶段监控指标，异常则暂停/回滚
|
||
- **优点**：风险可控、可进行 A/B 测试
|
||
- **缺点**：实现复杂度较高
|
||
|
||
### 滚动更新（Rolling Update）
|
||
- **原理**：逐步替换实例，每次替换一个或一组
|
||
- **配置**：Kubernetes Deployment 默认策略
|
||
- **优点**：资源利用率高，无需额外环境
|
||
- **缺点**：新旧版本共存时间长，回滚相对慢
|
||
|
||
### 特性开关（Feature Flag）
|
||
- **原理**：通过配置开关控制功能启用/禁用
|
||
- **部署**：代码部署与功能启用分离
|
||
- **优点**：秒级回滚、无需重新部署
|
||
- **缺点**：代码复杂度增加
|
||
|
||
## 在 DevOps Automator 中的应用
|
||
DevOps Automator 的标准部署流程：
|
||
1. 部署到 green 环境
|
||
2. 健康检查
|
||
3. 切换流量
|
||
4. 监控关键指标
|
||
5. 异常自动回滚
|
||
|
||
```yaml
|
||
kubectl set image deployment/app app=registry/app:${{ github.sha }}
|
||
kubectl rollout status deployment/app
|
||
kubectl patch svc app -p '{"spec":{"selector":{"version":"green"}}}'
|
||
```
|
||
|
||
## 相关概念
|
||
- [[CI/CD Pipeline]]：零停机部署是 CI/CD 流水线的最终目标
|
||
- [[Kubernetes]]：K8s 原生支持 Rolling Update 和 Canary Deployment
|
||
- [[Blue-Green Deployment]]：最常用的零停机部署策略
|
||
|
||
## 关键考虑因素
|
||
- **健康检查**：必须配置主动和被动健康检查
|
||
- **数据库迁移**：需要向后兼容的 Schema 变更
|
||
- **会话管理**：确保用户会话在版本间保持有效
|
||
- **缓存策略**：避免旧缓存导致行为不一致
|
||
|
||
## 成功指标
|
||
- 部署期间请求失败率：0%
|
||
- 部署期间延迟增长：< 5%
|
||
- 回滚时间：< 1 分钟
|
||
|
||
## Aliases
|
||
- Zero Downtime Deployment
|
||
- 无停机部署
|
||
- 滚动更新
|
||
- Rolling Deployment
|
||
- 金丝雀发布
|
||
- Canary Release
|
||
- 蓝绿部署
|
||
- Blue-Green Deployment
|