预算吃紧时，怎么用“性能换成本”省钱：自动伸缩、冷热分层与按 SLO 配资源很多人一提优化，第一反应是“更快”。可在真

很多人一提优化，第一反应是“更快”。可在真实业务里，老板常先问的不是“还能快 20% 吗”，而是“这月云账单怎么又涨了”。这时候，优化目标就变了：不是把系统一直维持在满血状态，而是让它在“够用”的前提下少花钱。

这篇里说的“性能换成本”，先用人话解释，就是：不再为了少数高峰时刻，全天候买最贵、最多、最快的资源；而是让资源跟着流量和业务重要性走。 这样通常能省钱，但代价也很直白：有些时段会慢一点，性能波动会更明显，容量规划也会更费脑子。

如果你是初学者，读完这篇你应该能回答三件事：这套思路到底在换什么、四种常见手段该怎么选、以及为什么省钱后反而更容易遇到抖动和规划难题。

为什么明明在讲性能，最后却在讲省钱？

先讲人话。想象你开了一家奶茶店，晚饭后排队爆满，但上午基本没什么人。如果你为了晚上那一小时高峰，全天都配满店员和设备，服务当然稳，可成本也会很肉疼。技术系统也一样。很多业务高峰很短，低谷却很长，全天按峰值备资源，往往就是浪费的开始。

再讲术语。所谓“性能换成本”，本质是把原本固定、充裕、昂贵的资源配置，改成更弹性、更分层、更贴近业务目标的配置。你不是不要性能，而是把性能从“全时满配”改成“按需要提供”。

小案例也很好理解。一个在线教育平台，晚上 7 点到 10 点上课的人最多，白天访问量只有晚高峰的三分之一。如果它 24 小时都按晚高峰配机器，白天就像开着空调给空教室降温，心里很凉快，账单更凉。


flowchart TD

A[先问自己：现在最痛的是成本吗] --> B{核心链路必须全天低延迟吗}

B -- 是 --> C[核心链路别激进省钱，先保性能]

B -- 否 --> D{流量有明显波峰波谷吗}

D -- 是 --> E[优先考虑自动伸缩或分时扩缩容]

D -- 否 --> F{数据有明显冷热之分吗}

F -- 是 --> G[优先考虑冷热分层]

F -- 否 --> H{能说清服务承诺吗}

H -- 是 --> I[按 SLO 定资源]

H -- 否 --> J[先补监控和基线，再谈降本]

E --> K[小流量验证后上线]

G --> K

I --> K

这张图的意思是：先判断“能不能接受某些地方慢一点”，再选手段；你现在最该做的动作，是先把核心链路和非核心链路分开。

最常用的 4 种手段，到底各自省在哪

1. 自动伸缩：忙的时候加人，闲的时候减人

先讲人话。自动伸缩就是系统自己看流量和资源使用情况，忙了就扩，闲了就缩。它像商场临时加收银台，客人多了多开几个窗口，客人少了就收回来，免得一直养着一排空柜台。

再讲术语。自动伸缩通常会根据 CPU、内存、请求数、队列长度、延迟等指标，自动增加或减少实例数。它最适合流量起伏明显，但不一定完全按固定时间表走的业务。

小案例：一个电商活动页，平时 8 台应用实例够用，活动开始后流量突然涨到平时 3 倍。自动伸缩可以把实例从 8 台拉到 20 台，活动结束后再慢慢降回来。省钱的关键不在扩容，而在低谷时真的缩回去。

它的代价也别忽视。新实例启动、预热、建连接都要时间，所以流量刚冲上来那几分钟，延迟可能先抖一下。说白了，它不是瞬移，是一边跑一边穿鞋。

2. 分时扩缩容：既然高峰有规律，那就提前排班

先讲人话。分时扩缩容，就是你已经知道业务每天什么时候忙、什么时候闲，于是直接按时间表调资源。它像早餐店提前在 7 点前把蒸笼和人手准备好，而不是等排队排到门外才开始揉面。

再讲术语。分时扩缩容是 schedule-based scaling，也就是基于时间规则的扩缩容。它特别适合高峰有规律、负载曲线比较稳定的系统。

小案例：一个知识付费平台，工作日晚上 8 点直播课最热。团队可以在 19:30 先把应用最小实例数从 6 提到 14，23:00 再降回去。相比完全依赖自动伸缩，它少了一段“等告警触发再拉机器”的反应时间。

但它也有脾气。要是遇到临时热点、节假日活动、明星老师突然开播，原本的时间表就可能不准。它最怕一句话：平时很规律，偏偏今天不按剧本演。

3. 冷热分层：把贵资源留给最常用的东西

先讲人话。冷热分层就是把“经常访问、必须快”的数据放在快但贵的层里，把“很少访问、慢一点也能接受”的数据放在慢但便宜的层里。像你家衣柜，常穿的衣服放手边，过季羽绒服放顶柜，不会把所有东西都塞进最顺手的位置。

再讲术语。这里的“热”通常指高频访问、低延迟敏感的数据；“冷”指访问少、可接受更长读取时间的数据。常见做法是：热数据放内存、缓存、SSD、高性能库；冷数据放对象存储、低频盘、归档库、离线仓。

小案例：一个内容平台会把近 30 天文章和评论放在高性能存储里，因为读得多；一年以前的文章附件转到更便宜的存储里，第一次打开可能慢一点，但大多数用户根本不会频繁读它们。这样做的省钱点很直接：别让冷数据长期住在豪宅里。

代价也很真实。一旦用户访问冷数据，可能要回源、解压、重新加载索引，体验会慢一截。如果迁移策略做得糙，还可能出现“刚转冷就被打回热点”的反复横跳。

4. 按 SLO 定资源：别为了模糊目标，长期过度买单

先讲人话。SLO 可以先理解成“你对业务承诺的服务目标”。比如，大多数请求要在 300 毫秒内完成，可用性要达到某个水平。按 SLO 定资源，不是问“机器越多越好吗”，而是问“为了达到这个承诺，到底需要买多少资源才刚好合适”。

生活类比一下。你开一家同城跑腿店，承诺 30 分钟送达，就没必要按“5 分钟必须到”的标准长期备 10 倍骑手。承诺和资源要对得上，不然就是自己把自己卷麻了。

小案例：内部 BI 报表系统，业务能接受 5 秒内出结果，那就没必要为了追求 500 毫秒，把计算集群常年堆到很高。相反，支付下单接口如果承诺 300 毫秒内完成、错误率极低，那它就不该跟 BI 报表用同一套省钱策略。

按 SLO 定资源的难点在于：SLO 定低了，资源会不够；SLO 定高了，省钱空间又没了。 它不像买衣服大一号小一号都能穿，差一点就可能直接引发抱怨。

|---|---|---|---|---|

这张表的意思是：四种手段省钱的位置不一样；你现在最该做的动作，是先找出自己到底在“为哪种浪费买单”。

什么时候值得这样做，什么时候别硬上

如果你的目标是“先降本，再在可接受范围内守住体验”，那这套思路就很有价值。下面这几种场景尤其合适：

流量有明显波峰波谷，比如电商、教育、内容社区、活动页。
非核心请求可以慢一点，比如历史记录、后台报表、冷门详情页。
数据冷热差异明显，新数据很热，老数据很冷。
团队已经有基础监控，至少知道峰值、低谷、延迟和错误率。
业务能讲清楚什么叫“够用”，也就是能说出一个大致的 SLO。

反过来，有些场景就别把这招当银弹：

支付、清结算、交易撮合、库存扣减这类核心链路。
用户对抖动极其敏感的实时交互，比如超低延迟音视频控制链路。
完全没有监控和回滚能力的团队。
流量极度不可预测，且扩容准备时间又长的系统。
法规、合同、强 SLA 要求很严的场景。

|---|---|---|---|---|

| 每天高峰很规律 | 适合 | 非常适合 | 一般 | 适合 |

| 老数据远多于新数据 | 一般 | 一般 | 非常适合 | 适合 |

| 用户能接受部分请求慢一点 | 适合 | 适合 | 非常适合 | 适合 |

这张矩阵的意思是：先选最匹配自己业务形状的第一招；你现在最该做的动作，是只挑一到两种手段做第一轮试点，不要四招一起上。

为什么省了钱，性能波动反而更大

很多初学者会问：我不是做优化吗，为什么优化完反而更容易抖？答案很简单，因为你把原本一直存在的“富余资源”拿掉了。

第一，缓冲变少了。以前你 24 小时都按峰值配机器，高峰来了当然稳，因为你一直在烧备用金。现在低谷会缩容、冷数据会下沉、报表会按较宽松目标配置，系统自然更贴边运行。一旦业务波动超出预期，就更容易出现延迟抬头。

第二，扩容本身需要时间。监控发现压力、触发规则、拉新实例、加载配置、连接数据库、预热缓存，这一串动作都不是零成本。用户请求可不会站在门口等你换鞋。

第三，冷数据本来就故意更慢。如果你把一年前的图片、日志、订单明细移到了更便宜的层，第一次访问慢一点，本来就是设计的一部分。它不是事故，而是你用体验换账单的明牌交易。

第四，按 SLO 配资源，意味着你主动放弃了过度冗余。只要系统达到既定目标，你就不会为了追求漂亮数字继续堆机器。所以你看到的 P95、P99 可能比过去更接近阈值，这很正常。


sequenceDiagram

participant U as 用户流量

participant A as 应用集群

participant X as 扩缩容系统

U->>A: 12:00 请求突然上涨

A-->>U: 部分请求开始变慢

A->>X: CPU、队列、延迟达到阈值

X->>A: 拉起新实例

Note over A: 启动、拉配置、建连接、预热缓存

A-->>U: 2 到 5 分钟后延迟逐步回落

这段时序图的意思是：波动往往出现在“高峰刚到、资源还没补上”的空档；你现在最该做的动作，是关注扩容耗时和预热时间，而不只盯着最终实例数。

为什么容量规划会更难

固定配额时代，容量规划虽然粗糙，但脑子比较省事：按峰值买一圈，再加点保险，就差不多了。性能换成本之后，问题一下子变多了，不过别慌，复杂是正常的。

你不再只算“峰值要多少台”，还得算这些问题：

最小实例数设多少，才不会一缩就抖。
最大实例数设多少，才不会高峰顶不住。
触发阈值和冷却时间怎么配，才不会一会儿扩一会儿缩，像电梯里有人狂按关门键。
哪些数据可以转冷，转冷后第一次读取能慢到什么程度。
哪些接口必须保留额外冗余，哪些接口可以按 SLO 卡得更紧。

再来一个小案例。一个直播课堂平台，把晚高峰应用实例从固定 24 台改成基线 8 台、最高 28 台，看起来很合理。结果第一次开学季活动时，扩容速度跟不上，登录接口在 10 分钟内明显变慢。后来他们不是把省钱策略整个推翻，而是补了两件事：活动期间提高最小实例数，扩容阈值提前触发。 这就是容量规划变难的本质：你要开始为“变化”本身做规划。

说得再直白一点，固定配额像买一辆大七座，平时一个人开也无所谓；弹性降本像改成按出行场景拼车，省钱是真省钱，但你得更懂路线、时间和上下车点。

给初学者一个能直接照着走的落地示例

假设你维护的是一个知识社区，现状是这样的：

首页、搜索、发布接口共用 20 台应用实例，全天不变。
最近内容和三年前的老内容都放在同一类高性能存储里。
后台报表和前台请求混用同一套计算资源。
平均 CPU 只有 15% 左右，但每月账单让人看了想扶墙。

这时候，不要一上来就全栈大改。更稳的做法是下面这 5 步。

第一步：先把请求分成“必须稳”和“可以慢一点”

先用人话分。发布、登录、支付、首页这些，用户一慢就骂；历史搜索、冷门详情、后台报表这些，慢一点通常还能接受。

对应成术语，就是做业务分层和性能分级。你要明确哪些请求是核心链路，哪些是非核心链路。别把所有请求都当国宾级接待，那样钱一定花得很平均，也很冤。

第二步：先定一个能落地的 SLO，不要靠感觉买机器

这里先把 P95 讲成人话：100 次请求里，大约有 95 次要在你承诺的时间内完成。它不是平均值，而是更接近用户体感的那条线。

例如你可以先约一个简单版本：

首页接口：P95 延迟不高于 300 毫秒
发布接口：错误率不高于 0.1%
历史搜索：3 秒内返回可以接受
后台报表：10 秒内完成可以接受

这里最关键的不是数字多漂亮，而是数字要能指导配置。如果后台报表 10 秒能接受，你就不该按 500 毫秒的成本去养它。

第三步：只组合最需要的 4 招

这个场景里，比较自然的组合是：

应用层做自动伸缩，实例范围从 8 到 24。
晚高峰 19:00 到 23:00 设置分时扩容，把最小实例数提前抬到 16。
90 天外的老附件和老日志下沉到冷存储，近 90 天数据保留在热层。
后台报表单独拆资源池，按较宽松 SLO 配资源，不跟前台抢饭吃。

注意，这里没有说数据库、缓存、搜索、对象存储都同时大动干戈。初学者第一轮最怕改太多，最后不知道是哪一项让系统抖了。

第四步：上线时别只看账单，要同时看 4 个指标

至少盯住这几项：

月度资源成本有没有下降
核心接口的 P95 和错误率有没有越线
自动伸缩从触发到生效花了多久
冷数据访问命中率和回源延迟有没有失控

如果你只看“省了多少钱”，那就像减肥只看体重不看体脂，数字变好看了，身体未必更健康。

第五步：一定要留兜底

兜底通常包括：

活动日手动提高最小实例数
如果核心接口连续几分钟超阈值，就暂停激进缩容
冷数据异常回源时，允许短期回切热点层
每周拿近似配置和真实业务结果做一次对账

这一步看着不炫，但它决定你做的是工程优化，还是把生产环境当盲盒。

| 项目 | 改造前 | 改造后 |

|---|---|---|

| 应用实例 | 全天固定 20 台 | 基线 8 台，晚高峰最低 16 台，最高 24 台 |

| 存储策略 | 全量高性能层 | 近 90 天热层，90 天外冷层 |

| 资源分配 | 前后台混用 | 核心接口和报表分池 |

| 性能目标 | 凭经验堆资源 | 按 SLO 给不同链路定档 |

| 体验特征 | 整体平稳但浪费明显 | 大多数时间够用，峰值更依赖监控和兜底 |

这张前后对比表的意思是：真正的降本不是一味删机器，而是把资源放到更值得花钱的地方；你现在最该做的动作，是先画出自己的改造前后对照表。

初学者最容易踩的 4 个坑

坑 1：一上来就把核心交易链路也一起省了

能省钱的地方很多，但不是每一处都该省。支付、库存、订单确认这类链路，通常应该最后动，甚至不动。先从无状态应用层、后台任务、冷数据、非核心查询下手，成功率高得多。

坑 2：只配自动伸缩，不配最小保底

如果最小实例数压得太低，系统就会在每次高峰到来时都先挨一拳，再开始补资源。自动伸缩不是“零库存管理”，它更像“有保底库存的弹性补货”。

坑 3：转了冷层，却没设计回热策略

有些数据平时冷，活动一来就突然热。如果只会“下沉”，不会“回热”，用户一访问就慢成拖拉机。冷热分层不是一次搬家，而是持续调仓。

坑 4：SLO 写在文档里，却没有进监控和告警

SLO 不是 PPT 里的漂亮句子，它必须和监控、告警、扩缩容规则、回滚策略连在一起。否则你写了“P95 300 毫秒”，系统根本没人盯，那它就只是墙上的标语。

最后，把这件事记成 5 句能落地的话

先区分链路：先检查哪些请求必须稳，哪些请求可以慢一点。
先识别浪费：先测量流量波峰波谷、数据冷热分布和资源利用率。
先挑一招试点：先选择最匹配业务形状的一到两种手段，不要一口吃四个降本方案。
先写清 SLO：先把核心接口的延迟、错误率、可用性目标说清，再决定配多少资源。
先验证再放大：先灰度测试扩容耗时、冷数据访问和回滚兜底，再扩大到全量业务。

如果你只想记住一句话，那就是：性能换成本，不是把系统故意做差，而是把“哪里必须快、哪里可以省”说清楚，然后让资源跟着这个答案走。 省钱能成，靠的从来不是胆子大，而是分层清、目标明、监控稳。