3. 计算资源优化：CPU与内存的合理配比、弹性伸缩策略、预留实例与竞价实例的选择

说到计算资源优化，我见过太多团队一上来就盯着实例规格选型，结果钱没省下来，线上还频频告警。说白了，计算成本控制不是单纯的「买便宜货」，而是要让每一分钱都花在刀刃上。今天咱们就聊聊三个核心维度：配比、伸缩、购买策略。

3.1 CPU与内存的合理配比：别让资源「偏科」

先问个问题：你选实例规格时，是按什么标准来的？

我见过不少团队直接套用默认配置，比如一律选 4C8G。结果呢？有的服务 CPU 跑满了，内存还剩一大半；有的内存快爆了，CPU 却闲得很。这就是典型的「资源偏科」——你为闲置资源付了钱。

3.1.1 如何找到你的「黄金配比」

我个人习惯先做一轮压测，采集真实负载数据。重点关注两个指标：

• CPU 使用率：看峰值和均值
• 内存使用率：同样看峰值和均值

然后算一个比值：CPU 使用率 / 内存使用率。举个例子：

3.1.2 配比调整的避坑指南

另外，别只看平均值。有些服务平时负载低，但高峰期 CPU 会瞬间飙高。这时候要考虑的是「峰值容忍度」——是扛一下还是直接扩容？这就要说到弹性伸缩了。

3.2 弹性伸缩策略：动态匹配，按需付费

弹性伸缩的核心逻辑很简单：负载高了就加机器，负载低了就减机器。但实际落地时，很多团队要么缩得太慢导致服务降级，要么扩得太猛造成浪费。

3.2.1 伸缩策略的三种模式

• 基于指标：CPU、内存、QPS 等指标触发。适合负载波动规律明显的场景。
• 基于时间：比如每天 10 点准时扩容，22 点缩容。适合有固定峰谷的业务。
• 混合模式：时间策略兜底，指标策略微调。我个人最推荐这种方式。

举个例子，我曾经负责过一个电商平台的后端架构。大促期间流量是平时的 10 倍，但流量曲线很规律——早上 10 点开始涨，晚上 10 点回落。我们用了混合模式：

# 伪代码示例：混合伸缩策略
if 当前时间 in [10:00, 22:00]:
    基础实例数 = 20
    如果 CPU > 70% 则额外扩容 50%
    如果 CPU < 30% 则缩容 20%
else:
    基础实例数 = 5
    如果 CPU > 80% 则扩容 30%
    如果 CPU < 20% 则缩容 10%

3.2.2 伸缩的「成本陷阱」

弹性伸缩虽然能省钱，但用不好反而更贵。比如：

• 频繁启停：每次创建实例都有启动成本，如果实例存活时间太短，这部分成本会吃掉节省的费用。
• 预留资源过多：有些人为了「保险」，把最小实例数设得过高。说白了，就是花钱买安心。
• 忽略预热：新启动的实例需要时间加载缓存、建立连接池。如果流量已经来了才扩容，那扩容期间的服务质量会下降。

3.3 预留实例与竞价实例的选择：长期 vs 短期

这部分是成本优化的重头戏。云厂商的定价模型其实就三种：按需、预留、竞价。咱们一个个说。

3.3.1 三种购买模式的对比

你想想看，如果你的服务 7x24 小时都在跑，用按需实例就是白白浪费钱。我见过一个团队，核心数据库跑了三年按需实例，多花了将近 40% 的费用。

3.3.2 预留实例的「正确姿势」

预留实例虽然便宜，但有个硬伤：你得承诺用满 1 年或 3 年。万一业务调整，预留的实例用不上了，那损失更大。

我个人习惯的做法是：

1. 先跑一个月按需，采集真实负载数据。
2. 找出「稳定基线」：比如每天最低负载是 10 台实例，那就把这 10 台转成预留。
3. 超出部分用按需或竞价：弹性伸缩扩出来的实例，用按需或竞价来覆盖。

3.3.3 竞价实例的「玩法」

竞价实例说白了就是云厂商的「尾货」——他们有多余的计算资源，低价甩卖。但有个风险：当资源紧张时，你的实例可能被随时回收。

所以竞价实例只适合：

• 无状态服务：比如 Web 前端、API 网关
• 容错任务：比如视频转码、数据清洗
• 批处理作业：比如离线报表、日志分析

3.4 本章知识体系总览

下面这张图把本章的核心逻辑串起来了，你可以对照着回顾一下：