3. 部署基础概念

说实话，我第一次接触「部署」这两个字时，以为就是拿个脚本往服务器上一跑完事。结果线上出了个大事故，用户数据丢了半小时。从那天起我才明白——部署不是复制粘贴，而是一套严谨的流程，甚至是一门手艺。

这节课我们就聊聊什么是部署，以及几种主流的部署策略。我保证不堆概念，直接上实战经验。

什么算部署？

说白了，部署就是把新版本的代码、配置、依赖，整体或分步地替换到生产环境，让用户能用到你的最新功能。但这里有个关键点：部署不等于发布。你可以把代码部署到线上，但通过开关、流量控制等手段，并不一定马上让所有用户看到。很多人搞混这个，结果一上线就崩。

我早期带团队时，部署就是「全军出击」——所有人都盯着一个集群，跑完脚本就开香槟。后来频繁出问题，才意识到我们需要更精细的策略。

部署的常见风险点

你想想看，一次部署可能涉及十几台机器、几十个微服务、数据库迁移、消息队列重建……任何一个环节出问题，后果都可能被放大。为什么会这样？因为生产环境不是测试环境，流量、并发、边界条件完全不一样。我见过最惨的一次，只是改了个日志级别，结果触发死循环把CPU打满了。

主流的部署策略

现在业界常用的部署模式有四种：蓝绿部署、金丝雀部署、滚动部署、A/B测试部署。它们各有场景，也各有坑。我一个个说。

蓝绿部署

准备两套完全一样的环境：蓝环境（当前线上版本）和绿环境（新版本）。把流量从蓝环境全部切到绿环境，切换完成后蓝环境变成备用。这个方案我最喜欢，因为回滚极其简单——切回来就行。

优点： 零停机、秒级回滚、环境隔离。
缺点： 资源翻倍（你得有两套机器），数据库兼容性是个大头。

金丝雀部署

先拿一小部分用户（比如1%）体验新版本，监控没问题后逐步扩大比例，直到100%。名字来源于「矿井金丝雀」——先让一只金丝雀试毒。

优点： 风险可控，发现问题影响面小。
缺点： 流量调度复杂，需要精确的路由规则；监控报警必须实时；如果数据库向后不兼容，金丝雀和旧版本共存时会出问题。

滚动部署

一个接一个地替换实例，比如你有10台机器，先停掉1台，部署新版本，再恢复，然后处理下一台。这种方案不需要额外资源，但耗时较长，且新旧版本共存期间要保证兼容。

优点： 零额外资源，逐步交付。
缺点： 回滚慢（得逐台回滚），容易出现「旧版本还没处理完，新版本已经出问题」的僵局。

A/B测试部署

严格来说它不算部署策略，更像一种实验。你同时运行两个版本，通过路由规则让不同用户看到不同功能，用数据对比哪个版本更好。A/B测试通常不涉及全量切换，只是验证假设。

我一般把A/B测试作为金丝雀的补充——先金丝雀放量，没问题再开A/B测试看业务指标，最后全量。

四种策略对比一览

策略	资源开销	回滚速度	风险等级	适用场景
蓝绿部署	高（双倍环境）	极快（秒级切换）	低	关键服务、无状态应用
金丝雀部署	中（额外少量资源）	中（取决于放量比例）	低至中	新功能验证、大版本更新
滚动部署	低（无需额外）	慢（逐台操作）	中	无状态服务、实例数多
A/B测试	中（双版本共存）	不涉及回滚	低（仅小范围）	产品功能实验、UI调优

怎么选？一张图帮你理清思路

我画了个决策流程图，看完你就知道面对不同场景该选哪种策略了。

实际部署时要注意的细节

光知道策略还不够，每个策略都有「坑」。我挑几个常见的啰嗦两句。

• 数据库变更兼容：蓝绿或金丝雀部署时，新旧代码同时运行，数据库 schema 必须向前兼容。我建议把所有数据库变更拆成多个小版本，先加字段、后删除，避免不兼容。
• 监控颗粒度：金丝雀部署需要按流量比例设置告警阈值。别等到错误率飙升才收到报警，我习惯设置「相对于基线版本错误率增长超过 20% 就自动回滚」。
• 健康检查接口：无论是蓝绿还是滚动，负载均衡依赖的健康检查必须覆盖核心依赖（比如数据库连接、缓存状态）。我曾经只检查了 HTTP 200，忽略了 Redis 连接池耗尽，结果流量打上来瞬间雪崩。

结语

部署策略没有银弹。你得根据团队的运维能力、服务重要程度、资源预算来平衡。我个人的推荐是：核心服务用蓝绿，普通服务用滚动，高风险变更用金丝雀，有业务疑问时加A/B测试。多演练几次，慢慢形成自己的部署 SOP。