选云服务器时，规格页上的参数看多了反而容易犹豫。配高了预算白花，配低了高峰期一卡就出问题。阿里云 m3 是否合适，要看你的业务到底怎么用机器。下面按几种常见用量来说明。
选型前先看四个参数
规格页上的指标很多，真正影响体验和账单的主要是下面四项。
- vCPU 与内存比例，先看应用是吃 CPU 还是吃内存。跑接口和计算的服务通常 CPU 先紧张，缓存、连接数多的服务则更容易先撞上内存上限。
- 网络带宽与收发包能力，并发请求多、内网调用频繁的服务要留意这一项。带宽够不够，可以用历史流量峰值对照判断。
- 云盘 IOPS 与吞吐，数据库和日志写入密集的业务，磁盘往往比 CPU 更早成为瓶颈。页面一慢，先查磁盘等待，别急着加机器。
- 计费方式，按量、包年包月和抢占式实例的成本差距不小。长期跑着的服务和偶尔拉起来的任务，不应该用同一种计费。
具体型号的参数、可用地域和价格会随阿里云调整，本文不列精确数值。下单前请以阿里云官网 ECS 实例规格页面和控制台显示为准。
按用量判断：三种常见情况
下面三种情况是比较典型的用量模式，并非某个具体客户的真实记录，你可以对照自己的业务找到最接近的一种。
流量稳定、偶尔冲高的站点
设想一个本地生活类的电商站点，平时访问量比较平稳，活动期间流量会明显抬高。这类业务如果按活动最高峰配一组固定实例，平时大部分资源都在空转。
更合理的做法是把 Web 应用和缓存层拆开。Web 层用阿里云 m3 规格，配合伸缩组，平峰时保持较少实例，活动前通过定时策略提前扩容，活动结束后再缩回去。缓存层单独放在内存比例更高的规格上，不和 Web 进程抢资源。扩容时间要提前量好。等页面已经开始变慢再加机器，通常来不及。
白天忙、夜里跑批的内部系统
比如一套内部 ERP 或报表系统，用户以员工为主，访问集中在工作日上午和下午。系统对单次响应时间要求不算苛刻，但不能出故障，夜里又要跑大量批处理。
常见的坑是把批处理和在线服务放在同一台机器上。夜里任务把 CPU 占满，白天的查询就会莫名变慢，排查起来很费时间。更稳妥的办法是把批处理迁到独立实例，用任务调度控制并发数。计算密集的离线任务适合 阿里云 m3 这类均衡规格，在线服务保持常规配置即可。批处理实例按需启停，不跑的时候不产生费用。
只在特定时段使用的开发与测试环境
开发和测试环境最容易被忽略。很多团队图省事，直接按生产规格配置，然后长期开机，月底账单一出来才发现不对劲。
先统计每个环境的实际使用时间。测试环境多半只在工作日白天有人用，那就没必要全天候运行。可以把非生产环境降到够用的规格，配合定时开关机脚本，夜间和周末自动停机。需要压测时再临时提升规格，压测结束后恢复。压测环境的规格要单独锁定并记录，否则降配后测出来的数据不具备参考价值。
选型的四个步骤
- 采集真实负载。至少观察两周，记录 CPU、内存、磁盘 IO 和网络流量的峰值与均值。只看一天的数据，容易被偶发的活动干扰。
- 判断瓶颈类型。CPU 长期高位而内存充裕，说明计算是瓶颈，可以优先考虑计算比例更高的规格。内存使用率持续逼近上限，就该调整内存比例，单纯加 CPU 解决不了问题。
- 用候选规格做小规模压测。在测试环境用接近真实的流量跑一轮，记录响应时间和错误率。规格表上的数字不能代替这一步。
- 设定监控与伸缩规则。配置告警阈值和伸缩策略，把复查变成日常动作，别选完就放着不管。
省钱时容易踩的几个坑
- 别只盯单价。单台便宜，但要多开好几台才扛得住流量，总费用未必更低。算账时把台数和运维成本一起算上。
- 稳定业务和波动任务分开计费。长期在线的服务适合包年包月，偶尔跑的任务用按量付费更灵活。两者混在一起，账单很难看懂。
- 磁盘和网络别漏看。数据库或日志密集型应用，升级 CPU 之后性能提升不明显，常常是磁盘拖了后腿。
- 每个季度复查一次。业务增长后，当初选的规格可能已经不合适。看一下利用率，超过一半时间都很空闲，就可以考虑降配。
阿里云 m3 合不合适，取决于你的负载形态。先采集数据，再拆分负载，最后用小规模压测确认。省下的钱来自资源和实际需求对上，挑最便宜的规格未必省钱。
