【系统架构设计】弹性伸缩：自动扩缩容的设计与实现
内容提要
自动扩缩容是带延迟的反馈控制系统，延迟会导致振荡和过冲。CPU、QPS、延迟等指标各有失效场景，需选对依据。HPA、VPA、Cluster Autoscaler独立运作，需协调。扩容受下游连接数、配额等约束，maxReplicas应由这些反推。冷启动和预热需配合就绪探针。扩缩容分钟级，需限流兜底，并主动注入故障验证配置。
延伸解读
扩缩容不是加机器，而是反馈控制
文章强调自动扩缩容本质是带延迟的反馈控制系统，延迟会导致振荡和过冲。CPU、QPS、延迟等指标各有失效场景，需选对依据。HPA、VPA、Cluster Autoscaler独立运作，需协调。扩容受下游连接数、配额等约束，maxReplicas应由这些反推。冷启动和预热需配合就绪探针。扩缩容分钟级，需限流兜底，并主动注入故障验证配置。
指标选择：CPU、QPS、延迟的失效模式
CPU利用率在I/O密集、锁竞争时失真；QPS假设请求同质，重请求场景失效；延迟是滞后指标且会自我强化。在途并发数结合Little定律更稳健。多指标取最大值是保守策略，避免单一维度掩盖过载。
HPA与VPA的协调与冲突
HPA和VPA不能在同一个资源指标上同时使用，否则会互相踩分母导致振荡。VPA调整资源请求，HPA调整副本数，两者独立运作。Cluster Autoscaler处理节点不足，三者互不知晓，需分别排查。
扩容的约束与兜底
扩容不解决下游容量问题，maxReplicas应由数据库连接数、配额等反推。冷启动和预热需配合就绪探针，否则新副本拖累系统。扩缩容分钟级，需限流兜底，并主动注入故障验证配置。
Q&A
自动扩缩容为什么会导致系统振荡？
自动扩缩容是一个带延迟的反馈控制系统，延迟来自指标采集、决策和Pod启动等环节。当负载变化周期与回路延迟相当时，控制器基于过时数据做出调整，可能方向错误，导致振荡。HPA通过稳定窗口和容忍度抑制振荡，但无法完全消除。
CPU利用率作为扩缩容指标有哪些失效场景？
CPU利用率在I/O密集型服务、锁竞争或队列积压、JVM GC暂停等场景下会失真。例如，线程等待数据库连接时不消耗CPU，导致CPU利用率下降，但系统实际过载。CPU指标仅适用于计算密集型、无外部依赖阻塞的工作负载。
HPA和VPA能否同时使用？
HPA和VPA不能在同一个资源指标（如CPU或内存）上同时使用，否则会互相干扰导致振荡。可以在不同指标上分别使用，或让HPA使用自定义指标。
KEDA与HPA是什么关系？
KEDA是HPA的增强，不是替代。它通过内置Scaler将事件源指标（如队列深度）暴露给HPA，并处理0到1和1到0的扩缩容，而1到N的扩缩容仍由HPA完成。
如何避免新扩容的Pod对数据库造成连接数冲击？
可以通过设置maxReplicas上限，确保副本数乘以每Pod连接池大小不超过数据库连接配额；或使用连接池代理（如PgBouncer）解耦应用副本数与数据库连接数。
扩缩容跟不上流量时，应该用什么机制兜底？
应该使用限流和过载保护，在扩容生效前保护系统。Google建议先扩容后限流，限流是扩缩容延迟的必然补充。
冷启动和预热如何影响扩缩容？
新Pod启动后需要预热连接池和缓存，否则无法承担流量。应使用就绪探针检查预热完成，并配合startupProbe提供充足时间。主动预热优于被动等待。
如何验证扩缩容配置是否有效？
通过主动注入故障，如模拟超过maxReplicas的流量脉冲，观察系统是否按预期触发限流；或制造数据库连接数逼近上限的场景，验证maxReplicas边界。
