备案站点的实例启动预热与慢启动治理

健康检查通过了，但这个实例还没真正"热"起来

发布或扩容时经常遇到这样的现象：新实例启动完成、就绪探针顺利通过、负载均衡立刻把它加入后端列表开始分流，但这个实例在最初的几十秒里，请求延迟明显高于其他实例，甚至出现成片的超时。等过了一两分钟，它的表现就和其他老实例完全一致了。

这不是实例有问题，而是**"进程能响应请求"和"进程能以正常性能承载满额流量"之间存在一个真实存在的差距**——冷实例需要一段时间把各层缓存填满、让运行时完成优化，这段时间里它的实际承载能力远低于稳态水平。健康检查只验证了前者，却被当作后者来使用。

关键要点

• 冷实例慢在多个层次：连接池未建立、本地缓存为空、运行时尚未完成热点代码优化，这些都需要实际流量跑一段时间才能改善。
• 就绪探针通过只意味着"能处理请求"，不代表"能承载和老实例同等的流量份额"，两者必须区别对待。
• 慢启动（渐进提升新实例的流量权重）是成本最低、收益最直接的缓解手段。
• 弹性扩容场景下预热不足最危险：扩容本身就发生在系统已经承压时，新实例如果立刻承担满额流量却处理不过来，会让情况进一步恶化。

冷实例到底慢在哪几层

层次	冷启动时的状态	需要什么才能改善
连接池	到数据库、缓存、下游服务的连接尚未建立	首批请求触发建连，建连本身有耗时，见 数据库连接池与连接数治理
本地缓存	进程内缓存为空，每个请求都要回源	实际请求逐步填充缓存
运行时优化	解释执行或未优化状态，热点代码尚未被优化编译	代码被反复执行一定次数后才会触发优化
类加载 / 模块初始化	部分代码路径在首次访问时才被加载初始化	首次访问该路径时才完成，表现为个别请求特别慢
下游缓存关联	共享缓存里可能也没有这个实例需要的数据	依赖整体的缓存预热情况，见 缓存与 Redis 运维

这几层叠加起来的效果，可能让冷实例最初的响应延迟是稳态的数倍。更麻烦的是它们的恢复速度不一致：连接池可能几秒就建好了，但运行时的热点代码优化需要足够多的实际执行次数才会触发，这就是为什么有些实例"看起来已经正常了"但延迟仍然偏高一段时间。

就绪探针通过 ≠ 能承载满额流量

就绪探针的设计目的是回答"这个实例现在能不能处理请求"，它通常检查进程是否启动完成、关键依赖是否可连通，见 优雅停机与健康检查 中关于探针职责划分的讨论。但它不检查、也无法检查"这个实例能以什么性能水平处理多少请求"。

一个常见的误区是试图通过"把就绪探针做得更严格"来解决这个问题——比如在探针里加上一些预热逻辑，等预热完成才返回就绪。这个思路有部分道理，但有两个局限：探针通过与否是个二元判断，无法表达"能力正在逐步提升"这个渐进过程；而且探针迟迟不通过会让编排系统误判实例启动失败并反复重启它，反而更糟。

更合理的分工是：探针负责判断"能不能用"，流量权重负责表达"能承载多少"，两者配合而不是让探针承担全部责任。

慢启动：按权重渐进放量

慢启动的思路很直接：新实例加入后端列表时，不立刻给它和老实例同等的流量权重，而是从一个较低的比例开始，在一段时间内逐步提升到正常水平。这样新实例在能力较弱的阶段只承担少量请求，既不会被压垮，也能通过这些真实流量逐步完成各层预热。

落地要点：

• 渐进窗口要覆盖实际的预热耗时：窗口设得比实际预热时间短，流量提升完成时实例还没热透，问题依然存在；设得过长则会延缓扩容的实际效果，在应对突发流量时反应不够及时。
• 权重提升曲线不必是线性的：实践中常用前期提升慢、后期提升快的曲线，因为预热的收益通常在前期最明显。
• 慢启动需要负载均衡层支持：这是一项负载均衡或服务发现层的能力，应用层无法自行实现，相关配置见 Nginx 反向代理配置，实例列表管理见 服务发现与注册中心运维。

主动预热：该预热什么

除了靠真实流量被动预热，也可以在实例启动阶段主动执行一些操作来提前完成预热：

• 预建连接池的最小连接数：启动时就建立若干到数据库和关键下游的连接，而不是等第一个请求来触发建连。
• 预加载核心的本地缓存数据：把高频访问的配置、字典类数据在启动时就加载到进程内缓存。
• 主动触发关键代码路径：用构造的请求跑一遍核心业务逻辑，让运行时有机会提前完成热点代码优化和类加载。

主动预热要注意两点：预热动作本身不能对下游造成明显压力（大量实例同时启动预热时，这些预热请求的总量可能不小）；预热的内容要和真实流量的分布匹配，预热了一批实际上很少被访问的数据，对改善真实请求的延迟没有帮助。确认预热效果的方式是在影子环境或压测中实际对比预热前后的延迟曲线，见 全链路压测与影子环境。

弹性扩容场景：预热不足最危险的时刻

预热问题在日常发布时的影响通常可以接受——发布是计划内操作，可以选在低峰期，个别请求变慢的影响面有限。但弹性扩容的场景完全不同：扩容恰恰发生在系统已经承压的时候，此时如果新实例刚加入就被分配满额流量却处理不过来，会出现一个很糟糕的连锁反应：

新实例响应慢甚至超时 → 这部分请求失败或触发重试 → 重试流量进一步加重整体负担 → 看起来扩容没有缓解压力、反而更糟 → 可能触发进一步扩容，加入更多同样没热透的冷实例。

这类连锁放大的防护需要几方面配合：慢启动机制确保新实例不会一上来就被压垮；重试要有退避和上限避免失败请求放大流量，见 超时设置与重试策略；扩容策略的触发阈值和冷却时间要考虑预热耗时，避免在前一批实例还没热透时就触发下一轮扩容，容量策略的设计见 容量规划与弹性伸缩；必要时配合限流兜底，见 限流、熔断与服务降级。

常见坑

• 把就绪探针当成"能承载满额流量"的判断依据：探针通过就立刻灌入等量流量，冷实例被压垮。
• 在就绪探针里塞进完整的预热逻辑：探针长时间不通过，编排系统误判启动失败并反复重启实例。
• 慢启动窗口短于实际预热耗时：权重提升完成时实例还没热透，问题只是被推迟而非解决。
• 大量实例同时启动并主动预热：预热请求的总量对下游造成明显压力。
• 弹性扩容策略不考虑预热耗时：前一批实例还没热透就触发下一轮扩容，冷实例越来越多。

常见问题

怎么确定一个实例需要多长时间才能热透？

在压测或影子环境里观察单个新实例从加入流量到延迟曲线趋于稳定所需的时间，这个时长就是预热耗时的参考值。不同服务差异很大，依赖较多、本地缓存较重的服务预热时间明显更长，没有通用数值。

主动预热和慢启动，应该选哪个？

两者不冲突，通常配合使用。主动预热能缩短需要靠真实流量才能完成的预热部分，慢启动则保证即使预热不完全，新实例也不会在能力不足时被压垮。只做主动预热无法覆盖运行时优化这类必须靠实际执行才能完成的部分；只做慢启动则延长了实例达到满载能力的时间。

无状态服务是不是不存在预热问题？

无状态指的是不在实例本地保存业务状态，但它依然有连接池、本地缓存、运行时优化这些需要预热的部分。无状态简化的是扩缩容和故障转移的逻辑，并不意味着新实例一启动就具备和老实例同等的性能表现。

预热期间的慢请求，要不要计入服务的可用性指标？

应该计入，因为用户实际体验到了变慢。把预热期间的异常排除在指标之外会掩盖问题，导致预热配置长期不合理却没人发现。更合理的做法是如实统计，并把"预热期间的延迟抬升幅度"作为评估预热配置是否到位的依据，指标口径见 故障响应、复盘与 SLO 实践。

资料来源

主流负载均衡与服务网格关于慢启动机制的公开文档，以及运行时性能优化与实例预热的通用工程实践资料。本文为通用运维说明，仅供参考，具体方案请结合技术栈与实际预热耗时设计。