零停机部署策略：蓝绿、金丝雀与滚动发布

零停机部署的核心目标，是在发布新版本的过程中不中断对用户的服务，并保留快速回滚能力。Martin Fowler 的零停机发布流程是这套思路的最小版本，本文展开讲讲三种主流策略。

一、蓝绿部署（Blue/Green）

蓝绿部署维护两套尽可能一致的生产环境：蓝色是当前线上，绿色用于部署新版本。新版本在绿色环境完成最终测试后，切换路由器/负载均衡把所有请求指向绿色；出问题再切回蓝色，实现秒级回滚。

用户 → 负载均衡 → [蓝色(当前) | 绿色(新版本)]
       切换流量 ⇄

优点：回滚极快、新旧隔离干净。缺点：需要双份资源。

落地时流量切换可以用 Nginx upstream 换组，或用云厂商的 Target Group 切换。配合Nginx 反向代理即可实现：

upstream app {
    server 127.0.0.1:8081;  # blue
    # server 127.0.0.1:8082; # green 发布时切换
}

二、金丝雀发布（Canary）

金丝雀发布让新版本先承接一小部分流量（如 5%~10%），观察错误率与延迟，确认稳定后逐步放量到 100%。它是"冒烟测试"在流量层面的延伸，适合对质量要求高、无法接受全量失败的场景。

发布前：100% → 旧版本
金丝雀：95% → 旧版本 + 5% → 新版本（观察）
放量：  逐步 50% → 100% → 新版本

实现方式包括 Nginx upstream 权重、Kubernetes 的多个 Deployment 分权重，或专门的金丝雀工具（如 Argo Rollouts）。

用 Nginx upstream 实现最直观：给旧版本权重 95、新版本权重 5，观察一段时间后逐步调整比值，直到全部切到新版本。

upstream app {
    server 127.0.0.1:8081 weight=95;  # 旧版本
    server 127.0.0.1:8082 weight=5;   # 新版本（金丝雀）
}

切换只是改权重后 nginx -s reload，整个过程用户无感知。关键是把“观察什么”提前定好：错误率、P95 延迟、业务指标（如转化率）各设一个阈值，一旦超限立刻把权重调回 100/0。

三、滚动发布（Rolling）

滚动发布把实例分批替换：先更新一部分（如 1/3），健康检查通过后再更新下一批，直到全部替换。它不需要双倍资源，是 Kubernetes Deployment 的默认策略。

kubectl rollout status deployment/app
kubectl rollout restart deployment/app

滚动发布期间新旧版本短暂共存，因此要求应用前后兼容（尤其是数据库 schema）。

四、健康检查：零停机的前提

任何策略都依赖可靠的健康检查来判断"新版本是否可用"。Docker 环境可用 healthcheck + depends_on，见Docker Compose 生产部署；Node 应用可配合 PM2 的 reload 做滚动重启，见PM2 部署指南。

健康检查建议包含：

就绪探针（readiness）：服务能接受流量
存活探针（liveness）：进程还活着
业务探针：关键接口能返回正常结果

五、数据库变更：最大的难点

Martin Fowler 特别强调：schema 变更要先于应用发布，且要前后兼容。流程是：先发布"兼容新旧两版"的数据库变更（加列、加索引、不加破坏性改动），确认稳定后再发布新应用版本；必要时保留旧版支持用于回滚。

-- 先加列（向后兼容），应用切到新版本后再考虑删旧逻辑
ALTER TABLE users ADD COLUMN api_key VARCHAR(64);

六、回滚机制

蓝绿：切回蓝色环境，最直接
金丝雀：流量调回 100% 旧版本
滚动：kubectl rollout undo 回滚到上一版本

回滚后要处理"新旧共存期间产生的数据"，所以数据库变更必须可逆或兼容。

七、与 CI/CD 衔接

零停机策略通常由CI/CD 自动部署流水线驱动：CI 构建产物，CD 执行切换/放量。生产监控（错误率、延迟）是判断放量是否继续的依据，可接入监控告警。Kubernetes 场景见K8s 入门指南。

一个选型场景：小型 SaaS 团队怎么选

假设一个 5 人 SaaS 团队维护一个 API + 前端的单体应用，日请求量约 50 万。发布节奏是每周一次，最怕发布后出现大面积故障影响线上。对这类团队，滚动发布 + 完善健康检查已经够用：Kubernetes Deployment 默认滚动，配合就绪探针，单次发布失败最多影响一小批实例；等团队规模变大、发版频率提高后，再引入金丝雀——先在 5% 流量上观察错误率，确认无误再放量。至于蓝绿，双倍资源的成本对多数中小团队偏高，更适合对可用性要求极高的核心服务。

选型的核心不是“哪个更先进”，而是“哪个符合当前的资源与风险承受能力”。

16IDC 观察

三种策略没有绝对优劣：蓝绿最稳但最贵，滚动最省资源但要求兼容性，金丝雀在"质量"与"资源"之间取得平衡。对中小项目，通常从滚动发布 + 可靠健康检查起步，成熟后再引入蓝绿或金丝雀。无论选哪种，"可验证的新版本 + 快速的回滚路径"才是零停机的本质。

参考：Kubernetes 滚动更新 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
原文来源：https://martinfowler.com/bliki/BlueGreenDeployment.html 、https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html

零停机部署策略：蓝绿、金丝雀与滚动发布