上云以后，常见的情况有两种。一种是服务器配置开得很高，账单每个月都很扎眼，可业务量其实只用了一小部分。另一种是为了省钱把配置压得很低，结果大促那天页面打不开，用户走了，损失比省下的钱大得多。两种问题的根子都是没有先弄清楚自己到底需要多少资源，单价反倒在其次。选阿里云配置的办法很朴素。先看真实负载，再定规格，别凭感觉拍板。
适量到底是什么意思
适量不等于越便宜越好。前提是性能和稳定性够用，同时不为闲置的资源付钱。可以从三个角度看：平时够不够用，高峰扛不扛得住，低谷有没有明显浪费。很多团队只盯着峰值去配，结果机器长期只跑到两成左右，这是最常见的浪费，也是最容易被忽略的。
先看懂这三项指标
选型前，先到云监控（CloudMonitor）里看下面三类数据。
- CPU利用率：同时看日均值和高峰值。如果长期低于30%，规格多半偏大；经常超过80%，就该考虑升配或者加机器。
- 内存使用率：内存一紧，系统就会频繁走交换分区，页面会明显变慢。内存的余量要比CPU留得宽一些，这一项最容易被低估。
- 带宽与磁盘IO：不少网站慢，卡住的往往是带宽或读写，而不是计算。如果CPU很闲，页面却很慢，先查这两项，别急着加核数。
看数据的时间窗口也要够长。两到四周比较稳妥，最好能覆盖工作日、周末和一次活动期。只看某一天，很容易得出片面的结论，比如周一上午的低谷，可能正好掩盖了周五晚上的高峰。
一个生鲜电商的调整过程
下面是一个虚构的例子，用来说明思路。某本地生鲜电商最早用的是8核16G的云服务器，带宽10Mbps，规划时按大促峰值来配。运行一段时间后，团队看监控发现，日常CPU平均只有15%左右，内存峰值大约六成，带宽峰值也只在6Mbps上下。机器大部分时间其实都在空转。
团队随后做了三处改动。基础规格降到4核8G，足够应付日常流量；接入弹性伸缩（Auto Scaling），CPU超过60%时自动加实例，最多扩到4台，流量回落后自动释放；带宽改为按流量计费，并设置上限，防止突发流量带来不可控的账单。
后来做大促，晚上八点左右系统自动加了两台实例，活动结束后又自动缩回去。月度云资源的账单降了三成左右，页面响应时间基本没受影响。这个例子说明的是，资源要跟着业务的节奏走，单纯降配只是其中一步。
包年包月和按量付费怎么搭配
计费方式也会影响选型。业务稳定、长期在线的服务，包年包月通常更省；流量起伏大、测试环境或者短期活动多的，按量付费更灵活。实际操作中，常见做法是基础负载用包年包月或预留资源兜底，波动的部分交给按量付费和弹性伸缩处理。两边各自承担合适的那部分，成本和弹性一般都能照顾到。
每月复盘一次
适量不是配完就结束的事。业务增长、功能迭代、用户习惯变化，都会改变资源需求。建议每个月固定花半小时复盘，重点看这几项。
- 过去一个月的利用率趋势有没有明显变化，比如峰值是否在慢慢抬高。
- 有没有长期闲置的实例、磁盘快照或公网IP，这些往往在无人察觉时持续计费。
- 大促或活动前有没有做压测，压测得出的峰值和线上实际峰值对得上吗，对不上就要回头查原因。
- 告警阈值设得是否合理。阈值太低会天天收到无效提醒，太高又可能在问题出现时没有反应。
余量留多少合适
不少工程师配置时喜欢留出很大一块余量，理由是”万一出事”。这种担心可以理解，但余量最好有依据。一般来说，峰值利用率控制在70%左右比较健康，既能接住突发流量，也不至于浪费太多。更稳的兜底方式通常是弹性伸缩、多可用区部署和完善的监控告警。把预算全压在单台机器的规格上，效果往往有限。
几个容易踩的坑
- 只看单台机器：分布式系统要看整体。单台利用率低未必有问题，更应该关注集群内的负载是否均衡。
- 忽略数据库和缓存：应用服务器配得再合理，数据库规格偏低，照样会成为整条链路的瓶颈。
- 配完就不动：业务变了，原来的配置很快就不再合适，最好把复盘当成日常动作。
- 套用固定的内存与CPU比例：网上流传的比例大多只适合特定场景，套到自己的业务上未必对，还是要以实际负载为准。
小结
阿里云适量的做法并不复杂，就是先看数据，再做判断，之后持续调整。先用监控摸清真实负载，结合计费方式和弹性能力选配置，定期复盘。这样既不会为闲置资源多花钱，也不会在大促的时候掉链子。如果团队还没有这个习惯，可以从下周开始，把过去一个月的CPU和内存曲线导出来看一眼，多数时候答案比预想的更清楚。
