去年双十一，某电商平台在流量峰值期部署新版本，结果进程启动即崩溃，支付链路中断23分钟，直接损失3400万订单。这不是技术事故，是部署策略的锅。
生产环境每次上线都是一场赌博。赌代码没bug，赌配置正确，赌用户无感知。零宕机部署（Zero-Downtime Deployment）不是消除风险，而是把"全押"改成"分批验证"——新版本和旧版本并行跑，流量逐步切，出问题秒级回滚。
Node.js生态里，真正能落地的就三种方案：蓝绿部署、滚动部署、金丝雀部署。本文按实现复杂度排序，告诉你什么场景该用哪个，以及一个血泪教训：没有健康检查，这三种全是摆设。
蓝绿部署：最粗暴的"双轨制"
原理像高铁换轨。绿色环境跑当前版本，蓝色环境部署新版本，测试通过后负载均衡器一键切流量，旧环境保留作为回滚备份。
实现上需要双倍资源。以Kubernetes为例，两套Deployment同时存在，Service通过selector切换标签。Node.js应用的关键是启动速度——从容器启动到能接流量，必须在健康检查超时内完成。
代码层面要处理SIGTERM信号。进程收到终止信号时，先关闭HTTP server的keep-alive连接，等活跃请求处理完再退出。漏掉这步，切流量瞬间会有请求被强制中断。
蓝绿的优势是回滚极快，切回selector就行。劣势也明显：资源成本高，不适合有状态服务（比如WebSocket长连接会被强制断开）。适合金融支付、核心交易链路这类"错一次就完蛋"的场景。
滚动部署：穷人的渐进式
资源不够两套全量？用滚动部署。逐个替换实例：起一个新Pod，健康检查通过，下线一个旧Pod，循环直到全量更新。
Node.js这里有个坑：默认的滚动策略是maxUnavailable=25%，意味着更新期间总容量只有75%。如果新版本有内存泄漏，25%的实例要扛100%的流量，雪崩风险极高。
建议配置改成maxSurge=1, maxUnavailable=0。先扩容再缩容，保证容量不降。配合readinessProbe（就绪探针）和livenessProbe（存活探针）双重校验，防止"假健康"实例混入。
滚动部署的问题是回滚慢。如果第5个实例发现问题，前4个已经更新，得逐个回滚。适合内部工具、非核心服务，或者资源确实紧张的小团队。
金丝雀部署：用真实流量做AB测试
最精细的方案，也最复杂。先切1%流量到新版本，监控错误率、延迟、业务指标，全部正常再逐步扩大比例。像煤矿里的金丝雀，先放一只进去探毒气。
实现需要流量控制能力。Nginx用split_clients模块，Istio用VirtualService权重，AWS用CodeDeploy的线性部署。Node.js应用本身要支持多版本共存——数据库schema必须向前兼容，否则1%的流量写新字段，99%读旧字段会炸。
关键指标不是"服务是否活着"，而是"业务是否正常"。健康检查返回200，但支付成功率掉了0.5%，金丝雀应该自动回滚。这需要接入Prometheus + Alertmanager，或者云厂商的Synthetics Canary。
金丝雀的隐藏成本是观测体系。没有完善的日志、指标、链路追踪，你根本不知道该扩还是该回。很多团队金丝雀变"金丝鸟"——放了就忘，出问题靠用户投诉发现。
前置条件：没这三样，上面全是空谈
第一，真实的健康检查。不要只检查进程是否存在，要验证数据库连接、缓存连通、关键依赖响应。内存阈值建议设400MB预警，Node.js的V8堆内存默认1.4GB，留足buffer。
第二，优雅的进程退出。收到SIGTERM后，server.close()停止接收新连接，设置30秒超时强制退出，防止僵尸进程。PM2的cluster模式要注意，默认会fork新进程替代退出的worker，部署期间可能引发混乱。
第三，可观测性。部署事件必须关联到指标看板，能一眼看出"14:23的发布"和"错误率飙升"的因果关系。Grafana的annotations功能，或者Datadog的deployment markers，都是标配。
原文作者最后提了一个细节：某团队的金丝雀部署监控了47个指标，但漏了"订单创建延迟的P99"。新版本数据库查询加了未命中索引的字段，平均延迟只涨5ms，P99涨了800ms，大促期间超时熔断，金丝雀没触发回滚，因为阈值设的是平均延迟。
你的健康检查，真的检查了该检查的东西吗？
热门跟贴