3、资源规格选型：告别“大炮打蚊子”——CPU/内存配比优化实战
说实话，我见过太多团队在资源规格上栽跟头。
一上来就开 8C16G、16C32G 的实例，结果 CPU 利用率不到 10%，内存倒是占得满满当当。说白了，这就是典型的“大炮打蚊子”——钱花了，效果没出来。
我个人习惯，做资源选型前先问三个问题：
- 这个应用是 CPU 密集还是内存密集？
- 它的峰值流量在什么时段？
- 它能不能扛得住突发抖动？
嗯，这三个问题搞清楚了，选型就成功了一半。
3.1 别被“默认配置”坑了
很多 PaaS 平台默认给你推荐 2C4G 或 4C8G。为什么？因为这是最通用的配置，兼容性最好。但通用 ≠ 最优。
我在项目中遇到过这样一个案例：一个 Java 微服务，业务逻辑很简单，就是做数据清洗。默认给了 4C8G，结果 CPU 长期在 5% 以下，内存倒是用了 6G。你想想看，这 4 个核基本在“摸鱼”，但钱是按核数收的。
后来我把它改成 2C8G，性能完全没变，成本直接砍半。
3.2 配比公式：从“拍脑袋”到“算清楚”
我一般用这个公式来估算初始配比：
CPU 核数 = 预估 QPS / 单核处理能力
内存大小 = 堆内存 + 非堆内存 + 系统预留 + 缓冲举个例子：一个 Node.js 应用，预估 QPS 是 2000，单核能处理 500 QPS。那 CPU 至少需要 4 核。内存方面，应用本身需要 512MB，加上 Node 的 GC 开销和系统缓存，我建议给 2G 起步。
所以初始选型是 4C2G。但注意，这只是起点。
3.3 实战案例：一个 Java 应用的“瘦身”过程
我记得有一次帮一个电商团队优化订单服务。他们用的是 8C16G 的实例，跑着 Spring Boot + MySQL。我一看监控，CPU 平均 12%，内存用了 10G。
我当时的分析过程是这样的：
- 先看 JVM 堆内存：-Xms8G -Xmx8G，堆用了 6G 左右。
- 再看非堆：Metaspace 用了 500MB，线程栈、Direct Buffer 等加起来不到 1G。
- 系统预留：操作系统本身 + 缓存，大概 1G。
算下来，实际需要的内存是 6G + 0.5G + 1G = 7.5G。但 16G 里有一半是浪费的。
我建议他们改成 4C8G，堆内存降到 4G。改完后，CPU 利用率升到了 30%，内存利用率 70%。成本直接降了 50%。
3.4 常见配比模型与适用场景
我整理了一个表格，方便你快速对照：
| 配比类型 | CPU:内存 | 典型场景 | 我的建议 |
|---|---|---|---|
| 计算密集型 | 1:1 ~ 1:2 | 数据处理、视频转码、科学计算 | 优先保证 CPU，内存够用就行 |
| 通用型 | 1:2 ~ 1:4 | Web 服务、API 网关、微服务 | 最常用，适合大多数场景 |
| 内存密集型 | 1:4 ~ 1:8 | 缓存（Redis）、搜索引擎、实时分析 | 内存是核心，CPU 可以少给 |
| 高并发 IO 型 | 1:2 ~ 1:3 | 消息队列、Nginx、负载均衡 | CPU 和内存都要适中，重点看网络 |
3.5 避坑指南：我曾经踩过的三个坑
坑一：只看规格不看限制。
我曾经选了一个 2C4G 的实例，以为够用了。结果发现这个规格的 CPU 有“突发性能限制”——平时只能跑 20%，只有突发时才能跑满。高峰期直接被打回原形。后来我换成了“无突发限制”的 2C4G 实例，问题才解决。
坑二：忽略内存的“隐性消耗”。
Java 应用除了堆内存，还有线程栈、Metaspace、JIT 编译缓存等。我见过有人给 2C2G 的实例跑 Spring Boot，结果 GC 频繁，系统直接 OOM。我的经验是：Java 应用至少给 4G 内存，堆内存占 60%-70%。
坑三：不做压测就上线。
有一次我自信满满地改了一个服务的配比，从 4C8G 降到 2C4G。结果上线后，流量一上来，CPU 直接 100%，服务雪崩。后来我学乖了：任何配比调整，必须先压测，至少跑 30 分钟峰值流量。
3.6 实操建议：三步搞定选型
- 第一步：摸底。 用监控工具（如 Prometheus + Grafana）跑一周，看 CPU、内存、网络、磁盘的峰值和均值。
- 第二步：试配。 按“CPU 密集给高核低内存，内存密集给低核高内存”的原则，选一个初始规格。
- 第三步：压测。 用 JMeter 或 Locust 模拟峰值流量，观察资源利用率。如果 CPU 超过 80% 或内存超过 90%，就升配；如果都低于 30%，就降配。
嗯，这套流程我用了好几年，基本没出过大问题。