本文目录
自动扩容是容量控制回路，必须能在业务失效之前生效
增加应用实例只有在应用是主要瓶颈且共享依赖有余量时，才可能增加有效处理量。容量水位应根据业务延迟拐点、峰值增长速度、实例就绪时间和故障余量确定，不能统一照搬 CPU 百分比。自动扩容还依赖指标、配额、调度和预热，缩容需保护在途任务与稳定性。成本应包含应用、数据库、缓存、网络、日志与峰值预留，验收同时检查有效业务容量、故障承受能力和费用变化。
扩容前的四个决策条件
| 判断项 | 需要的实测证据 | 盲目扩容风险 |
|---|---|---|
| 瓶颈位置 | 增加实例后有效完成量上升，延迟改善，共享依赖未饱和 | 数据库或外部限额不变，多实例只增加竞争 |
| 触发水位 | 指标在业务超标之前变化，且覆盖就绪等待 | 按平均 CPU 触发过晚，排队与尾延迟已失控 |
| 可用容量 | 实例能够调度、拉起、预热并通过业务就绪检查 | 副本期望数增加，但没有实际可接流量的实例 |
| 成本上限 | 扩容最大副本、依赖费用与资源配额有记录 | 吞吐收益有限，连接、网络与采集费用快速增长 |
适用边界：横向扩容不等于所有组件自动扩容
这份指南适用于可多实例运行的业务应用，Kubernetes HPA 用作资源与扩容行为的参考。虚拟机、容器平台或托管服务的实际指标和启动方式不同，应按部署环境实现；数据库与外部服务需单独评估。
先确认应用无必须绑定单机的状态，或有明确会话、文件与任务协调方案。多实例后重复定时任务、并发缓存重建和本地计数可能改变业务行为。故障余量还要考虑实例所在节点或区域的关联性，不能把同一故障域内很多副本当成相同数量的独立保障。
会话共享和任务协调方案本身也可能引入缓存或数据库压力，所以扩容前要跟踪这些新增工作。若业务使用长连接，连接分布可能不能随新副本立即均衡；应确认新容量是否接到实际流量，以及退出实例时连接怎样重新建立，避免只看到实例数量增长。
- 列出可以扩的组件和不能随应用增长的共享依赖。
- 检查会话、文件、定时任务和全局配额在多实例下的行为。
先证明增加实例能够改善有效容量
固定负载结构与数据，比较不同副本数下的有效业务完成量、延迟和共享依赖压力。若数据库锁、热点写入或第三方限额已经成为瓶颈，扩应用可能没有收益，反而使连接和重试放大。
把应用处理、连接等待、存储与外部等待分开看。单位新增实例带来的收益不必线性，但应能够解释；负载不均时还要检查路由、长连接或热点租户。优化代码、查询与请求成本有时比扩容更划算，不过判断应来自相同条件下的实验，而不是预设架构偏好。
- 保存各副本组合的容量曲线与依赖资源变化。
- 为无法横向扩的热点列出拆分、限流或业务调整方案。
水位取决于业务拐点与扩容生效时间
扩容触发需在排队和延迟失控前留出反应时间。CPU 不是所有业务的可靠信号，I/O 等待或依赖限额时 CPU 可能不高；队列年龄、在途请求、实际需求与拒绝量可作为补充条件。
Kubernetes 的 CPU 利用率口径与资源请求配置相关，缺少正确请求值会影响按利用率扩容判断。资源 requests 影响调度，limits 会形成运行约束，两者不能混为“机器总资源”。设置水位前先测启动、镜像拉取、连接建立、缓存预热与负载均衡接流的整段时间。
- 记录正常水位、业务延迟拐点、峰值增长速度与就绪耗时。
- 检查指标缺失、延迟和限流压低信号时的处理规则。
把峰值预留、故障余量与费用放到同一容量表
最小副本、最大副本和提前预热分别承担日常、峰值与响应时间要求。只按最低费用运行，活动突增可能发生在新实例就绪之前；一直保持极高余量又可能让预算失控，需要按业务峰谷验证。
成本表除实例费外，还包含数据库规格、缓存、网络出口、负载均衡和日志采集；具体单价应以合同与当期账单为准。按有效业务完成量比较资源方案，并计算故障时剩余容量。新增实例带来的连接总数和预热回源也要计入共享资源预算，不能只计算应用本身。
- 为日常、活动和故障场景分别列出配置、能力与费用。
- 设置最大副本、预算、配额与触顶后的入口保护动作。
实施步骤：扩容、就绪、缩容形成完整回路
先建立容量与成本基线，再配置可靠指标和资源请求，设置最小与最大副本，验证就绪与预热，然后测试扩大负载时扩容生效，最后验证缩容稳定窗口、连接排空与在途任务交接。
缩容过快可能造成反复伸缩，也可能在任务未完成时移除实例；终止流程应停止接新流量，再按业务边界处理在途工作。批量任务与长连接需要单独确认交接方式。自动扩容权限、指标服务、资源配额和调度容量都是前置依赖，故障时应有人工扩容或限流的可执行入口。
- 在可控环境测完整控制回路，不能只看副本数量变化。
- 为指标不可用、配额耗尽和实例无法就绪写明处置动作。
验收：容量增长、失败模式与账单都要核对
验收包含缓慢增长、瞬时突增、实例退出、指标异常、扩容触顶和高峰后缩容。实际就绪容量要在体验超标前提供有效处理量，扩容后共享依赖仍受控，缩容不丢业务状态。
对比同一负载下优化前后的费用与容量，说明是减少单位请求成本还是采购了更多资源。检查重试与限流不会掩盖扩容需求，预热不会产生回源洪峰。报告保留无法调度或不就绪的失败阶段，以及触顶时业务如何降级，才能证明容量方案在现实约束下可用。
费用评估应采用实际资源使用与账单类别，并注明观察周期、峰谷比例和价格口径。不同活动长度或数据规模不能直接用单日费用比较；对于按量服务，记录请求放大和重试成本，解释高峰过后费用是否回落，才能判断自动扩容是否达到了预期经济性。
- 核对期望副本、实际就绪副本、有效完成量与成本。
- 确认缩容后任务、连接与会话仍符合约定状态。
需求讨论中的问题
自动扩容统一按 CPU 多少触发？
没有适合所有业务的百分比。应看 CPU 或其他指标何时预示业务延迟超标，并留出新实例就绪时间；还要核对利用率口径、资源请求与共享依赖。
增加一倍应用实例能增加一倍容量吗？
取决于瓶颈和依赖余量。数据库、热点写入、外部限额或负载不均会限制收益，应在固定负载与数据下比较有效完成量，而不是按副本数推算。
自动扩容已经配置，活动前还需要预热吗？
如果流量增长快于调度、启动和预热总时间，就需要提前准备容量或入口保护。应测整段就绪时间与活动增长曲线，不能只验证扩容规则能改副本数。
扩容与成本方案验收清单
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- Kubernetes：Horizontal Pod Autoscaling
核验 HPA 控制回路、利用率指标与资源请求关系，以及扩大和缩小副本的行为配置。
- Kubernetes：Resource Management for Pods and Containers
核验 requests 对调度及 limits 对 CPU、内存的约束；本文不使用通用资源百分比作保证。
需要评估现有系统的性能瓶颈？
提供关键业务路径、真实峰值、服务器与数据库配置，以及现有压测或故障记录，月弦科技可据此梳理优化顺序、实施范围和可验证的验收条件。