4. 计算资源选型与性能基线
在 AWS 上做性能优化，第一步往往不是调参数，而是选对计算资源。EC2 实例类型由「实例族 + 规格大小 + 处理器架构 + 附加特性」共同决定，选错族或架构，后续再怎么优化都事倍功半。本节围绕实例族特性、处理器架构、网络与存储带宽、基准测试方法、性能基线建立与实例推荐这条主线展开，帮助你把「选型」从经验判断变成可复现的工程过程。
一、实例族特性：先看工作负载画像，再看字母
EC2 实例族用字母区分定位：通用型（M、T）计算/内存/网络均衡，适合 Web 服务、中小数据库、应用服务器；计算优化型（C）高主频、计算与内存比高，适合批处理、编码转码、游戏服务器、高性能 Web 前端；内存优化型（R、X、z）大内存，适合内存数据库、实时大数据、缓存；存储优化型（I、D、H）本地 NVMe/HDD 吞吐高，适合 NoSQL、数据仓库、日志处理；加速计算型（P、G、Inf、Trn）带 GPU 或推理芯片，适合训练、推理、图形渲染。T 族是突发型，靠 CPU 积分机制在低负载时积累、高负载时消耗，适合平均利用率低但偶发峰值的场景，一旦持续高负载积分耗尽就会降频，这是选型时最容易踩的坑。
同一族内还有代际与附加后缀：数字越大通常代际越新，单位算力性价比更高；后缀 a 表示 AMD、g 表示 Graviton（ARM）、i 表示 Intel、d 表示带本地 NVMe、n 表示网络增强、e 表示额外内存或存储。例如 m7g.2xlarge 就是第七代通用型、Graviton 处理器、2xlarge 规格。
二、处理器架构：x86 与 Graviton 的取舍
架构选择直接影响性价比与迁移成本。x86（Intel/AMD）生态成熟、二进制兼容性最好，几乎所有商业软件和自编译产物都能直接跑；Graviton 基于 ARM，同规格下通常有更好的每美元性能，但要求应用、依赖库、容器镜像都有 ARM 版本。判断能否迁移，关键看三点：语言运行时是否支持（Java、Go、Python、Node.js 主流版本均已支持）、是否有 x86 专用二进制或 JNI 本地库、容器基础镜像是否有 arm64 变体。迁移前建议先用同规格 Graviton 实例跑一遍基准测试，而不是直接全量切换。
三、网络与存储带宽：被忽视的性能上限
很多人只盯 vCPU 和内存，却忽略了带宽。EC2 的网络带宽和 EBS 带宽通常随规格增大而提升，且分为「基准带宽」和「突发带宽」。以 m 族为例，较小规格基准带宽低、可短时突发，较大规格则基准即高带宽。EBS 优化实例的 EBS 带宽同样随规格变化，例如 2xlarge 级别常见约 2.5 Gbps 上下，而更大规格可达 10 Gbps 以上（具体数值以官方文档为准）。如果应用是网络密集型（如 API 网关、代理、分布式缓存客户端）或磁盘密集型（如数据库、日志写入），带宽往往先于 CPU 成为瓶颈。选型时应把「峰值网络吞吐」「峰值 IOPS」「峰值吞吐量」三个指标与实例规格表对齐，而不是只看核数。
四、基准测试方法：让数字可比较
基准测试的核心是「控制变量」。同一份负载、同一套指标、同一段时长，只改变实例类型或架构，结果才有可比性。常用工具按维度划分：CPU 用 sysbench cpu 或 stress-ng；内存带宽用 sysbench memory 或 STREAM；磁盘用 fio 测随机读写 IOPS 与顺序吞吐；网络用 iperf3 测节点间带宽，用 wrk/hey 测 HTTP 服务端吞吐与延迟。测试时要注意：预热阶段不计入统计、至少跑三轮取中位数、关闭无关后台任务、固定可用区与子网以排除网络路径差异。
一个可复用的 fio 随机读测试示例（4K 随机读、队列深度 32、持续 60 秒）：
fio --name=randread --ioengine=libaio --direct=1 \
--rw=randread --bs=4k --iodepth=32 \
--size=2G --runtime=60 --time_based \
--group_reporting --output-format=json关注输出中的 iops、clat（完成延迟）和 bw。如果 IOPS 远低于实例规格表标称值，先确认 EBS 卷类型（gp3 的基准 IOPS 与吞吐可独立配置）和实例的 EBS 带宽上限，再判断是卷瓶颈还是实例瓶颈。
五、性能基线建立：把「正常」量化下来
性能基线是「在已知负载下，系统各项指标的稳定区间」。建立步骤：先确定业务关键指标（如 API P95 延迟、订单处理 TPS、数据库 QPS），再在目标实例上以典型负载运行，记录 CPU 利用率、内存使用率、网络吞吐、磁盘 IOPS、延迟分位数等，形成基线快照。基线不是一次性的，应随版本发布、实例变更、流量增长定期复测。判断是否偏离基线时，建议设定阈值，例如 P95 延迟超过基线 20%、CPU 持续高于 80%、IOPS 达到规格上限的 90%，就触发排查或换型评估。
六、实例类型推荐：从基线到决策
推荐流程可以归纳为：画像 → 候选 → 实测 → 成本折算 → 决策。举例来说，一个日均 200 万请求的 Java API 服务，峰值 CPU 利用率 65%、内存占用 6 GB、P95 延迟 120 ms。候选可以是 m7i.xlarge（4 vCPU/16 GB，x86）和 m7g.xlarge（4 vCPU/16 GB，Graviton）。在相同压测下，若 Graviton 版本 P95 延迟相当或更优、单位小时价格更低，且依赖库均有 arm64 版本，就优先推荐 Graviton；若存在 x86 专用本地库，则保留 x86 候选。最终推荐必须同时满足 SLO 和单位成本最低，而不是单纯追求跑分最高。