慢启动避免新实例被压垮
慢启动让新加入或刚恢复的后端从较小权重逐步爬到目标权重。刚启动的服务往往缓存是空的、连接池未预热、JIT 未优化，此时如果直接接满权重，容易出现超时与错误。慢启动把流量爬坡交给负载均衡，产品不支持时可以用分批调整权重手动实现同样效果。
基本信息
| 作用 | 新成员接入后权重按时间渐进爬升到目标值 |
|---|---|
| 适用场景 | 缓存冷启动、连接池预热、启动耗时较长的应用 |
| 配合流程 | 先摘除流量、再发布、带慢启动加回 |
| 替代方案 | 产品不支持时按批次手动调高权重 |
| 注意 | 慢启动只解决流量爬坡，不替代发布流程 |
典型使用场景
- 批量扩容后新实例直接接入，需要避免冷缓存打满连接池
- 滚动发布期间新旧版本并存，用慢启动控制新实例的初始压力
- 数据库连接池预热要求较高的应用，接入前端服务时渐变放量
- 实例重启恢复后被自动加回后端列表，避免瞬间满权重
- 压测前的准备：确认被测服务已预热到稳定状态
分批调权重的手动节奏
分批调权重的手动节奏
T+0 权重 5 观察错误率与 P99 延迟
T+10 权重 20 错误率无上升再继续
T+20 权重 50 同时核对后端连接数与排队情况
T+30 权重 100 纳入常规监控
# 任何一档出现错误率上升，立即回退到上一档并排查接入方式对照
| 方式 | 适用条件 | 风险 |
|---|---|---|
| 开启慢启动 | 产品支持该能力 | 低，自动化程度高 |
| 手动分批加权重 | 产品不支持 | 依赖人工节奏，容易忘 |
| 先摘除再发布 | 所有滚动发布场景 | 无，属于标准流程 |
| 直接全权重接入 | 对启动速度有信心时 | 冷启动超时集中爆发 |
慢启动解决的是流量爬坡问题，发布流程仍应先摘除流量再操作实例；顺序颠倒时新旧实例会同时承受流量。
把慢启动当成发布流程的替代品是常见误用：它不会帮你更新代码，也不会处理未就绪依赖。