当业务流量在数分钟内翻倍，而你的云服务器却仍在用固定规格硬扛时，响应延迟上升、请求排队、甚至服务不可用，这往往是弹性伸缩策略缺失或配置不当的典型症状。云服务器弹性伸缩的核心，是根据预设的监控指标（如CPU使用率、内存占用）自动增加或减少实例数量，从而在负载高峰时保障性能，在低谷时降低成本。本文将以CPU与内存指标为例，分析自动扩容的触发条件、配置步骤与常见误区。
为什么CPU和内存是核心指标？
CPU和内存直接反映计算资源的使用情况。CPU使用率过高通常意味着计算密集或并发请求过多；内存占用过高则可能引发OOM（内存溢出）甚至进程被内核杀死。根据Linux内核文档，内核负责进程调度和内存管理，当内存压力过大时，内核会启动OOM Killer选择进程终止，这会导致服务中断。因此，基于CPU和内存的自动扩容，能提前规避因资源耗尽引发的故障。
自动扩容的触发条件与阈值设定
合理的阈值设定是弹性伸缩策略的关键。阈值过低会导致频繁扩容，成本上升；阈值过高则可能来不及扩容，业务受损。一般建议：
- CPU使用率：平均使用率超过70%持续5分钟触发扩容，低于30%持续15分钟触发缩容。
- 内存使用率：可用内存低于20%持续5分钟触发扩容，高于60%持续15分钟触发缩容。
但具体数值需根据业务类型调整。例如，视频转码等CPU密集型任务可适当提高CPU阈值；内存数据库则更关注内存指标。同时，应设置冷却时间（如300秒），避免频繁伸缩。
配置步骤：从监控到自动化
以常见的云平台为例，配置自动扩容通常包含以下步骤：
- 创建监控指标：在云监控中定义CPU和内存使用率的采集规则，确保数据准确。
- 定义伸缩组：设置最小实例数（如2）、最大实例数（如10），以及默认实例规格。
- 配置伸缩策略：选择“基于指标”的伸缩，添加触发条件（如CPU>70%），并设置扩容数量（如增加2台）和冷却时间。
- 设置通知：在伸缩动作发生时，通过邮件或短信通知运维人员。
- 测试与调优：模拟负载，观察伸缩行为，调整阈值。
注意，内存指标的采集需依赖操作系统层面的工具（如free命令），云平台通常通过安装代理获取。根据Ubuntu Server文档，Ubuntu Server支持通过cloud-init等工具进行初始化配置，可在实例启动时自动安装监控代理。
常见误区与失败条件
- 只关注CPU而忽略内存：许多应用是内存密集型，内存耗尽可能导致OOM，而CPU可能尚未达到阈值。
- 阈值设置过高或过低：过高则扩容滞后，过低则频繁伸缩，增加成本。
- 忽视冷启动时间：新实例启动需要时间（如加载镜像、初始化应用），若扩容信号触发到实例就绪耗时过长，可能无法及时承接流量。解决方案是提前预置部分实例，或使用更快的镜像。
- 伸缩组配置不当：最小实例数设为0可能导致所有实例被回收，服务中断；最大实例数过小则无法应对突发流量。
- 依赖单一指标：某些场景下，CPU和内存均正常，但网络或磁盘I/O成为瓶颈，此时应考虑其他指标。
策略取舍与调优建议
弹性伸缩并非万能，它更适合无状态应用（如Web前端、API服务）。对于有状态应用（如数据库），直接伸缩可能导致数据不一致，需借助分布式缓存或读写分离架构。此外，缩容策略应保守，避免频繁缩容导致资源浪费或性能抖动。
在调优过程中，建议利用云平台提供的伸缩历史记录，分析每次伸缩的原因和效果，逐步优化阈值。同时，结合定期压测，验证伸缩策略的有效性。
参考资料
延伸阅读