弹性伸缩实战指南：让云服务器按需呼吸，省下过半成本

我做了多年线上业务运维，有个很深的体会：多数团队的钱不是被大流量烧掉的，而是被“买多了的服务器”一天一天耗掉的。打开云控制台看一眼实例列表，如果所有机器的CPU平均使用率长期趴在5%-15%，那基本可以断定预算有一大半在空转。后来我花了很大力气把业务改造成可以弹性伸缩的架构，让服务器能像人一样“吸气扩容、呼气缩容”，账单肉眼可见地降了下来。这套东西放在云上叫弹性伸缩（Auto Scaling），很多教程把它讲得很玄，实际上核心逻辑就一句话：让计算资源的数量跟着真实负载走，而不是按最坏情况提前买断一整年。这篇就用大白话把配置思路、实操步骤和踩坑经验讲透。适合手里有云服务器、想控制成本，又不敢随便动现网架构的运维和后台开发。

1. 钱都浪费在“不喘气”的机器上了

1.1 为什么按峰值买机器是最大的浪费

先看一个很常见的业务场景：一个面向企业内部的Web系统，白天上班时间访问量高，午休和夜间基本没人用。如果采购服务器时按峰值估算，比如高峰期需要8台8核16G的实例，那绝大多数团队的选择就是买8台包年包月，放在那里常年运行。

问题是，真实流量不是一条水平的直线，它更像心电图，有高峰有低谷。每天真正需要8台实例的时间可能只有两三个小时，剩下的21个小时里，用2到3台实例就能完全扛住。这就好比公司为了应付每天下午三点的集中取餐，直接雇了8个全职厨师从早上站到晚上，其余时间大部分人在刷手机。钱花得很冤枉。

“按峰值买”这件事还有一个隐藏成本：峰值本身是动态的。业务促销、外部爬虫、突发热点都可能让流量短时间冲到平时十倍。如果按预估峰值买，怕预估不准；如果按保险起见再高一点买，浪费更多。预留容量永远在“不够用”和“用不完”之间反复摇摆，而弹性伸缩解决的就是这个剪刀差。

1.2 弹性伸缩的本质：把“买机器”变成“调度机器”

弹性伸缩听起来像个高级技术，本质却是非常朴素的管理思想。包年包月的固定实例相当于全职员工，不管有没有活干都要发工资；弹性伸缩里临时创建的按量实例则像临时工，忙的时候按小时叫人过来，忙完立刻结账走人。按量实例的单价通常比包年包月的等效单价贵一些，但因为使用时间短，总开销反而低得多。

我再把逻辑说得直白一点。假设业务高峰期需要8台实例，低谷期只需要2台。传统做法是直接买8台包月，一个月30天每天都为8台机器的钱买单。弹性伸缩的做法是让2台包年包月的“底座”保底运行，高峰期再自动拉起6台按量实例，等高峰期一过就释放掉。按量实例可能只跑2到6个小时，按小时计费，虽然单价高，但总费用比起全天24小时开着的包月机器少很多。

关键是要理解“用多少、开多少、关多少”这句话。很多运维一听到弹性伸缩就觉得是稳定性方案，只想到“流量大了自动加机器”，却把“流量低了自动减机器”这半边忽略了。省钱恰恰靠的是后面这半个动作，而且是整套配置里最容易出错的部分。

1.3 先泼盆冷水：不是所有服务都适合“会喘气”

我在推动弹性伸缩落地时，第一个要确认的不是云平台参数，而是业务能不能“放得开”。如果应用把用户会话存在本机内存里、把临时文件写在本机磁盘上、把状态留在进程里，那扩容出来的新机器不熟悉用户，缩容又会把正在使用的用户会话直接杀掉。这种有状态服务直接做弹性伸缩，不是省钱，是给自己埋雷。

适合弹性伸缩的服务有几个共同特征：无状态、支持水平扩展、启动时间可以控制在几分钟内、被负载均衡接管后能通过健康检查。Web前端、API服务、消息消费者、离线任务执行节点这类角色通常天然适合。而数据库、缓存、需要本地持久化的中间件，尽量不要让它们跟着流量随意伸缩。数据节点一旦缩容，丢的可能是真金白银。

所以要“会喘气”，先想清楚哪些节点能喘、哪些必须稳稳站住。这是配置前最需要花时间的判断，比任何参数都重要。

2. 扩缩容不是魔法：启动模板、伸缩组、伸缩策略到底管什么

2.1 启动模板：新机器的“出厂说明书”

弹性伸缩不会凭空捏出一台服务器，新实例总得有个“出厂说明”，这就是启动模板或启动配置。它规定了一台新机器创建时用哪个镜像、多大规格、多少磁盘、挂在哪个安全组、用什么密钥登录、要不要执行一段初始化脚本。

很多新手图省事，随便选一个公共镜像当启动模板。结果业务高峰期扩容出来的机器里没有JDK、没有PHP扩展、没有应用代码，等CLB把流量转发过去，请求一片5xx。启动模板不是只选个镜像就完事，它至少要把三件事定清楚：基础环境（系统版本、运行时）、应用部署方式（包在哪、配置从哪拉）、开机后的自启动动作。

实际项目中我习惯把“应用版本”和“启动模板”解耦。启动模板里只放操作系统和基础运行环境，应用版本通过初始化脚本从对象存储或软件仓库拉最新包，配置统一从配置中心读取。这样每次发版不用重新做镜像，扩容出来的永远是最新版本。

2.2 伸缩组：管“一群人”的管理单元

有了启动模板，还需要一个容器把这一批机器装起来管，这个容器就是伸缩组。伸缩组定义了这台机器的“人口边界”：最小实例数是多少、最大实例数是多少、期望实例数是多少、分布在哪些可用区、要不要自动挂到负载均衡后面。

你可以把伸缩组理解成一个负责排班的调度室。它时刻查看当前有多少台实例在岗，少于最小值就自动补人，多于最大值就拒绝再加人，收到策略指令就调整人数。只要实例挂了或者健康检查不通过，它还会自动创建新实例替换。

有一个常见误解是把伸缩组当成普通的实例列表管理工具，直接在界面里手动创建实例再加进组。这通常会让伸缩组困惑，它有自己的期望容量，外来实例会被判定为多余，过一会儿就被回收掉。正确做法是调整伸缩组的期望实例数，让系统来决策增删，而不是自己动手“加塞”。

2.3 伸缩策略：吸多大口气、呼多大口气，都得有依据

伸缩策略是整套配置的大脑，回答三个问题：什么时候扩、一次扩多少、什么时候缩、一次缩多少。云平台一般提供几种方式，我分别说下白话解释。

手动伸缩，是在大促或演练前手动把期望实例数从3改成10，系统按差值补齐机器。它适合“你知道接下来要发生什么”的场景。

定时伸缩，适合流量规律明确的业务。比如每天早上8点自动扩容，晚上11点自动缩容；或者已知周五晚上有活动，提前半小时扩容。定时伸缩的缺点是扛不住突发，只按日历走，不按真实流量走。

动态伸缩，通过监控指标触发。比如CPU平均使用率连续5分钟超过70%，就增加一台机器；超过85%，一次加两台。它适合流量不可预测的场景，但也有滞后性，指标飙高到追加机器需要几分钟，期间可能已经有部分请求超时。

目标追踪伸缩，更省心一些。你直接告诉系统“我希望能让CPU稳定在60%左右”，云平台会自动帮你组合多条告警规则，自己判断什么时候扩、什么时候缩。这套机制适合已经从“手动配阈值”进化到“只关心业务水位”的团队。还有预测式伸缩，靠历史数据预测未来的流量趋势，提前扩容，需要一定数据积累，刚上手的项目不建议一上来就用。

2.4 一次完整的“呼吸”是怎么发生的

把整个流程串起来看，弹性伸缩的运转很像一次深呼吸。当伸缩策略判定需要扩容，伸缩组会启动一个伸缩活动：先从启动模板创建实例，等实例开机并跑完初始化脚本，然后挂到负载均衡后端，负载均衡健康检查通过后开始接收流量。整个过程通常需要两三分钟到十几分钟，取决于应用启动速度。

缩容正好反过来。策略判定需要减机器后，伸缩组先选择一台符合移出条件的实例，把它从负载均衡的接收流量列表里摘掉，等存量连接处理完或者超过一个等待时间，才真正释放这台机器。这样做是为了让正在处理请求的用户不被打断。

明白这个完整链路后，再配置策略就会清楚很多。扩容要关注“多久能顶上”，缩容要关注“流量摘得够不够干净”，任何一环出问题，呼吸节奏都会乱。

3. 白话配置流程：一步步跑通一套弹性伸缩组

3.1 前置条件：先做无状态改造

前面说了，有状态服务不适合直接伸缩。真到了配置环节，第一步就是检查业务是否满足无状态要求。

我用一个简单的清单自查：

• 用户Session是不是存在Redis或独立会话服务里？
• 上传的临时文件是不是放到了对象存储？
• 本机磁盘有没有需要保留的数据？
• 应用启动后有没有定时任务会在多个实例上重复执行？
• 服务间调用能不能通过负载均衡或注册中心自动发现新节点？
• 关闭应用时能不能主动通知负载均衡“我正在下线”？

如果哪个问题的答案是“不行”，那就先别急着配伸缩。就算配好了，一到缩容就出事故，最后还得灰溜溜关掉。无状态化改造不复杂，但需要业务方配合，这笔技术债早晚要还。

3.2 做镜像和启动模板：把环境固化成文件

条件具备后，先准备启动模板。我推荐的做法是找一台临时实例，手动把基础环境装好：操作系统补丁、JDK/Python/Node运行时、日志采集Agent、监控Agent、基础工具链。确认没有垃圾文件后，把这台机器制造成自定义镜像。

然后在控制台创建启动模板，关键项这样填：

• 镜像：使用刚创建的自定义镜像，而不是每次都用公共镜像重新装环境。公共镜像意味着环境“裸奔”，初始化脚本要干太多活。
• 实例规格：根据业务选CPU内存比。如果是计算密集就选CPU占比高的规格，内存型业务选大内存规格。
• 磁盘：系统盘建议40G以上，数据盘按需挂载。弹性实例尽量不要依赖数据盘里的内容。
• 安全组：至少放通负载均衡健康检查端口和应用服务端口。
• 登录凭证：选密钥对。密码方式在批量创建场景下容易泄露，不方便管理。
• 实例名称和标签：加上前缀和标签，比如 env=prod，app=order-api，方便后面按标签查账单。

还有一个非常重要的输入框：初始化脚本，也就是UserData。它会在实例第一次启动时执行。我在里面通常会写这些动作：从配置中心拉配置、从软件仓库拉最新应用包、启动应用进程、把实例注册到服务发现组件。这样镜像只需要“最小可用”，版本迭代不依赖重新打镜像。

3.3 创建伸缩组：定好边界和挂载关系

启动模板准备好后，创建伸缩组。名字用业务含义，比如 order-api-asg，别用随意的字符串。区域和专有网络选择要和负载均衡在同一地域和VPC下，否则挂不上。

最小实例数我建议生产环境至少设2，不要设1，更不要设0。设1意味着有一台机器宕机后，伸缩组还能再补一台，但补的间隙里已经没了容量，对高可用是很大的风险。最大实例数根据成本上限和下游容量来设，不能无限大。期望实例数如果不填，默认和最小值一样。

然后要选择多个可用区。比如华东地域有可用区A和B，把伸缩组覆盖到两个可用区，弹性扩容时才不会把新机器全塞进同一个故障域。单可用区扩容，一旦可用区整体出问题，再加多少台都是白搭。

创建伸缩组时可以关联负载均衡。关联后，伸缩组会自动把新创建的实例加到负载均衡后端，缩容时也会先从负载均衡摘除。记得选对后端服务器组，并配置健康检查路径，健康检查返回2xx或3xx才算实例可用。如果你的服务健康检查路径是 /healthz，别在负载均衡里默认配成根路径 /，很多事故就是这么来的。

3.4 配动态策略：先定“吸气”的节奏

动态策略配置最核心的是阈值、持续周期、冷却时间和单次伸缩数量。我给你一套很多项目可以直接套用的保守配置：

几个数字背后的逻辑要讲一下。CPU阈值70%是扩容阈值，不是85%。因为从触发到新实例真正开始接流量至少需要几分钟，如果等到85%再扩，扩容完成时业务可能已经超时了。持续周期设5分钟，是为了避免瞬时尖峰触发无意义的扩容。缩容阈值30%放到很低，持续周期拉长到15分钟，就是防止“刚缩一台流量就上来”的尴尬。缩容动作本身数据上报和实例释放也需要几分钟，冷却600秒比扩容冷却更长，是刻意让系统“多想一会儿再决定”。

冷却时间的作用更大。一次伸缩活动结束后，在冷却时间内即使告警再次触发，伸缩组也不会立即执行新的伸缩活动。如果冷却时间太短，比如60秒，高峰期会出现连续扩容，一下从3台冲到最大实例数，账单瞬间起飞。

如果要配目标追踪策略，我建议目标值设在60%-70%之间。设太低，比如40%，系统会认为负载很高，频繁扩容；设太高，比如90%，系统反应太慢，扩容跟不上业务增长。

3.5 如果流量有规律，再加定时策略

动态策略处理的是突发，定时策略处理的是“可预期的规律”。

举个例子，一个面向学校的管理系统，每天早上8点到12点、下午2点到6点是使用高峰期。我可以在伸缩组里加两条定时规则：工作日07:40设置期望实例数为10台；工作日18:20设置期望实例数为3台。定时扩容要留出提前量，让实例在流量起来前就位。如果早上8点流量开始涨，7点40就要开始扩，给初始化预留15到20分钟。

定时策略和动态策略可以并存，方向要一致。如果定时策略把期望实例数设为10，而动态策略因为CPU低又慢慢缩到3，两边会打架。我的经验是：固定的“底座容量”交给定时或手动逻辑来设，动态策略只负责在底座之上做增量，最大实例数边框设好，避免策略叠加后数量失控。

4. 缩容省钱，但更考验功力：怎么做到“敢缩”而不翻车

4.1 不敢自动缩容的三种担忧

弹性伸缩落地最大的阻力通常在“缩容”环节。运维不敢开自动缩容，理由通常有三种。

第一种，怕缩完没多久流量又涨回来，再扩容一次既慢又贵。第二种，怕请求还没处理完实例就被释放，用户感觉到报错。第三种，怕某台实例上跑了定时任务或有临时数据，一缩就丢。

这三种担忧都很真实，但它们都应该通过配置和架构解决，而不是干脆不开缩容。因为不开缩容，就回到了固定机器按峰值买的老路，保费目的落空。下面几个机制就是用来化解这些担忧的。

4.2 冷却时间再长一点：给缩容“装个迟钝开关”

想解决“刚缩完又涨”的抖动问题，最有效的办法就是拉长缩容触发条件和冷却时间。我见过抖动最夸张的一个项目，伸缩组一天扩容缩容来回30多次，月底账单比不开伸缩还贵。

当时的根因是：业务流量在每分钟都有小波动，CPU一会儿70%一会儿40%，动态策略持续周期只有1分钟，冷却时间又设置成默认值，导致系统对短时噪音反应过度。调整方法是把扩容持续周期从1分钟提到3到5分钟，缩容持续周期提到10到15分钟，缩容冷却时间单独设到600秒以上。这就好比给系统装了一个迟钝开关，面对短时波动先缓一缓，不要一惊一乍。

针对业务高峰和低谷的切换，还可以给动态策略里配置时间范围限制。比如缩容策略只在晚上10点到早上8点之间允许执行，白天的高峰波动根本不会触发缩容，从规则层面锁死风险。

4.3 实例保护和优雅下线：让一台机器“体面地离开”

伸缩组在决定移除实例时，一般会按移出策略选最旧的一台，或最新的一台。但不管选哪台，如果这台机器正在处理关键请求，直接释放肯定出问题。这时需要两个保护机制配合。

实例保护，是给特定实例打上标记，伸缩组缩容时自动跳过它。比如某台机器上有临时的人工排查任务，或跑了不允许中断的近实时任务，就给这台实例设置“保护中”状态。要注意保护不是万能的，如果整体负载需要缩容到最小实例数以下，受保护实例可能会阻碍缩容，导致期望容量一直达不到。这种时候得人肉介入先解除保护。

优雅下线解决的是另一层问题。负载均衡在移除后端实例前，应该先停止向它转发新请求，再留一小段时间让存量请求处理完，之后才真正断开。很多负载均衡把这叫做“优雅下线”或“连接耗尽”。如果你用的是TCP四层监听，又没开优雅下线，那缩容时正在长连接里的用户就会突然掉线。建议在负载均衡侧把优雅下线时间设置为60到120秒，给进程足够时间把手头的活干完。

应用层面也可以做一件事：收到终止信号时主动通知负载均衡“我要下线”，并停止接收新任务。这块需要开发配合，但效果最稳。云厂商一般还会提供生命周期挂钩，可以在实例释放前暂停流程、执行一段脚本，比如备份日志、通知监控系统、确认任务排空后再继续释放。

4.4 从最小实例数为0开始：非生产环境的极端省钱法

对测试环境、预发环境、临时跑批任务这类场景，完全可以把伸缩组的最小实例数设为0。平时没有任何机器在跑，也就没有任何计算费用，只有镜像、快照这类少量存储费用。需要测试时触发一次伸缩规则拉到1到2台，用完再缩回0。

有的团队会把这种思路用到生产环境的非核心模块上，比如后台报表计算任务，白天不跑，每天凌晨2点定时扩到几台机器处理批量任务，处理完自动缩到0。一整个月的计算成本只有每天那半小时的按量费用，几乎可以忽略不计。这就是“会喘气”省钱的极限形态。

5. 弹性伸缩把我坑惨的几个瞬间及排查思路

5.1 扩容出来的新机器一直在负载均衡里“不健康”

先说一个最常见的事故。某次流量高峰触发扩容，伸缩组日志显示实例创建成功，但负载均衡后端面板上新增的三台机器一直处于“不健康”状态，流量全压在老机器上，老机器CPU已经飙到95%。

我的排查思路是分三步走。先别怀疑伸缩组，手动用同一个启动模板在控制台单独创建一台实例，看应用到底能不能正常启动。这一步能快速区分是模板问题还是伸缩组配置问题。然后登录实例查看初始化脚本日志和进程状态，我当时发现是应用版本拉取路径配置成了测试环境的地址，新机器全部从测试源拉包，版本不一致导致健康检查失败。最后再看健康检查本身，负载均衡的健康检查URL、端口、返回码是否和应用真实暴露的路径一致。

这个坑的教训是：启动模板改完后，一定要手动创建一台实例做冒烟验证，确认健康检查能通过后，才让伸缩组继续使用这个模板。别拿线上高峰期当试验场。

5.2 伸缩组疯狂“打摆子”：扩容缩容来回抖动

我见过最让人崩溃的情况是伸缩组像打摆子一样，CPU一上来就扩，扩完后新实例启动过程中CPU瞬间飙高又触发再扩，等新实例都起来了负载又降下去，触发了缩容；缩完一台，CPU又回到高位，再扩。整个活动日志刷屏，实例数量像炒股一样起伏。

一步步排查下来，问题出在三个叠加因素上。第一，持续周期设太短，1分钟内的CPU峰值就能触发动作；第二，冷却时间设成了0，伸缩活动结束后没有任何缓冲；第三，缩容阈值和扩容阈值相隔太近，扩容是CPU大于60%就加，缩容是小于50%就减，两条告警之间没有足够的安全间隔。

解决方式我前面也提过：扩容持续至少3到5分钟，缩容持续至少10到15分钟；冷却时间扩容300秒、缩容600秒上下；扩缩阈值之间留出足够“死区”，比如扩容70%、缩容30%，中间这段不属于任何动作区。这组配置改完后，抖动基本消失。

5.3 手动加的实例被伸缩组当成“多余人口”清理了

有一次线上做促销压测，运维为了方便，直接在负载均衡后端手动添加了一台高配实例。看起来流量分担了，但没过多久那台手动加的实例就被释放了。运维群里炸了锅，以为是平台出bug。

根因一点不复杂：伸缩组有期望实例数的概念。当时伸缩组期望实例数是3台，实际运行3台，手动加一台后，实际数量大于期望数量，伸缩组判定这台机器不在计划内，属于需要清理的“多余人口”，于是发起了缩容活动把它释放。

正确做法是：临时扩容时不要手动开机器再塞进负载均衡，而是去修改伸缩组的期望实例数，或者执行一条扩容伸缩规则。让伸缩组自己走到目标状态。这样新扩的机器才在“编制内”，不会被清理。

5.4 疯狂扩容应用，反而把数据库打挂了

有次活动流量上来，应用扩容策略正常触发，半小时内从4台扩到了12台。应用节点CPU稳定了，但数据库的连接数却突然暴涨，最终数据库触发连接数上限，整个系统拒绝服务。

原因并不难猜：每台应用启动时都会初始化一个数据库连接池，连接池默认最大连接数100。4台实例时最多400个连接，扩到12台后最多1200个连接，数据库的连接管理直接被冲垮。应用层的扩容解决的是计算瓶颈，但下游数据库、缓存的容量不一定跟上。连接池的上限要根据整个集群的最大实例数来算，不能只看单机。我的做法是：扩容策略里除了CPU指标，还要关注数据库连接数、缓存命中率这类下游指标，或者在下游设置更严格的连接上限和排队机制。

5.5 所有新实例都挤在同一个可用区

某次故障后重启整套环境，伸缩组自动扩容，结果发现新实例全部创建在可用区A，可用区B一台都没有。原因是创建伸缩组时没有手动指定多可用区交换机，系统默认只选了第一个可用区。看似每个实例都正常，实则所有鸡蛋都放在一个篮子里，可用区A一挂，整批实例全军覆没。

配置弹性伸缩时，一定要把多个可用区的交换机都选上。系统分配实例时会尽量分散，也能在某个可用区故障时把新实例调度到其他可用区。这个动作只是创建时多勾选几个交换机，但关键时刻能救命。

6. 配好之后算笔账：弹性伸缩到底能省多少钱

6.1 一个可以直接搬到报表里的成本算式

弹性伸缩到底省不省钱，不能靠感觉，建议算清楚。我给出一个通用的估算方法。

假设某业务高峰需要8台同规格实例，低谷只需要2台，按每天高峰4小时算。方案A是固定8台包年包月，全天24小时开机。方案B是固定2台包年包月保底，每天4小时高峰再拉6台按量实例。为了直观，假设一台包年包月折算成小时费用是1元，按量付费是2元（不同配置差异很大，这只是口径演示，实际以云厂商控制台为准）。

方案A一个月费用：8台乘24小时乘30天，乘以1元，结果是5760元。方案B一个月费用：固定2台全天开，2乘24乘30乘1元等于1440元；弹性6台每天开4小时，6乘4乘30乘2元等于1440元，合计2880元。方案B一个月能省接近一半。这还没算低谷期完全可以缩到1台，或者把固定机位再降一档。

实际账单里还有公网流量、云盘快照、负载均衡费用，弹性实例偶尔产生的高额流量费也会占一部分。建议做成本对比时不要把计算资源费用当成唯一指标，把每台实例的平均日运行时长、流量、快照纳入成本口径一起看。

6.2 要更极致省钱，可以把“临时工”换成“竞价实例”

按量付费单价还是偏高，如果业务无状态且能接受实例随时被回收，就可以让扩容部分使用各大云厂商提供的竞价实例或抢占式实例，价格通常只有按量付费的几折甚至更低。因为它们是云上闲置资源，随时可能被平台回收，不适合跑长时间任务和有状态应用，但非常适合无状态的Web前端、API服务、批量计算节点。

我在实践中的做法是把保底的固定实例用包年包月，弹性扩容的第一梯队用按量付费，第二梯队用竞价实例。配合负载均衡的健康检查，即使个别竞价实例被回收，伸缩组也会自动再创建一台，只要业务层面扛得住短暂抖动，整体成本能再降一个台阶。

6.3 动手之前应该先回答的几个问题

配置弹性伸缩最快的人，不是上手就点控制台的人，而是先画清楚业务模型的人。我每次帮团队做方案都会先问一轮问题。

• 业务的流量高峰是否有固定规律？如果有，定时策略的权重就高；如果没有，动态策略必须配好。
• 扩容一台实例到完全可用需要多久？如果超过10分钟，就要考虑把健康检查的预热时间放长，甚至提前扩容。
• 应用能不能在多个实例上同时跑而不互相干扰？本地Session和临时文件都是雷。
• 缩容造成的最坏影响是什么？如果会影响正在支付的用户，就要把优雅下线时间调高，以及配置实例保护。
• 你希望业务水位稳定在哪个指标？CPU不一定是最佳信号，QPS、并发连接数、队列深度可能更接近真实压力。

这些问题都有答案后再去配策略，基本能在五分钟内完成，而且不需要反复返工。

我个人实际落地的顺序，是先把应用改成无状态，再只开扩容策略观察一两周，确认扩容及时、业务稳定后，才把自动缩容打开。缩容从保守参数开始，持续观察一周再逐步调低阈值。千万不要第一天就扩容缩容全开，否则你会同时处理抖动、误伤和账单三个问题。等到整个节奏稳定，你再看月账单时，会真切体会到“会喘气”的服务器到底有多省钱。