云联信息：弹性伸缩策略，怎么配才不会反复扩缩

2026-11-05 1次浏览

弹性伸缩听起来很美：忙时自动加机器，闲时自动减。实际配置不好，会出现刚扩完就缩、缩完又扩的循环，费用没省下来，服务还跟着抖。

先看业务曲线

有明显峰谷的业务适合弹性伸缩，比如白天忙晚上闲、工作日忙周末闲。全天平稳的业务，固定规格反而更省心。

扩容阈值可以敏感一些，缩容要保守。扩慢了用户等，缩快了刚扩容又不够，两个方向的策略不对称才对。

扩容后给新机器几分钟预热，这段时间不再触发新的扩容。没有冷却时间，一条曲线上升会连续扩出十台机器。

只看 CPU 容易被单核跑满误导，结合连接数、队列长度、响应时间一起判断，扩容决策更准。

缩容阈值设得比扩容阈值低一截，形成回差。两个阈值贴太近，就会在边界上反复横跳。

镜像里预装好依赖，启动脚本尽量短。新机器启动要五分钟，扩容的意义就少了一半，预热时间也要算进容量规划。

新机器自动注册到负载均衡，摘除时先停止接收新请求再关机。顺序错了，缩容期间会有请求打到正在关闭的机器上。

最少两台保证高可用，最多十台防止异常流量把费用打爆。上限不是限制业务，是保护预算。

大促、月初结算这类可预知的峰值，用定时策略提前扩容，比等监控触发更稳。动态策略兜底不可预知的部分。

扩缩次数多说明阈值不合理，一次没扩说明策略没生效。记录是最好的调参依据，比凭感觉改参数靠谱。

一次扩十台，新机器同时启动，镜像拉取、依赖下载会把网络打满，反而拖慢启动。分批扩容，每批两三台，间隔一两分钟，整体反而更快完成，也更平稳。

直接把机器关掉，正在处理的请求会失败。正确的顺序是从负载均衡摘除、等待连接排空、再关机。这个细节决定缩容期间用户有没有感知。

弹性伸缩触发时正好在做发布，新扩容的机器可能拉到旧版本镜像。发布期间暂停伸缩策略，发布完成再恢复，避免版本混乱。

弹性伸缩的价值在于匹配业务节奏，而不是追求全自动。云联信息【资深云服务专家微信：cloud7591】建议先从定时策略起步，跑稳之后再加动态策略，扩容快、缩容慢、留回差，这三点抓住就不容易抖。