容量规划怎么做才能既不浪费资源又不扛不住高峰
摘要：# 网站容量规划：钱花在刀刃上，流量来了不慌张 我前两天帮一个做电商的朋友看后台，真是哭笑不得。他花大价钱上了顶配的服务器集群，平时CPU利用率不到10%，跟养老似的。结果大促前夜，他问我：“哥，要不要再加两台机器？我怕扛不住。” 我一看监控数据，直接给…
网站容量规划：钱花在刀刃上，流量来了不慌张
我前两天帮一个做电商的朋友看后台，真是哭笑不得。他花大价钱上了顶配的服务器集群，平时CPU利用率不到10%，跟养老似的。结果大促前夜，他问我：“哥，要不要再加两台机器？我怕扛不住。” 我一看监控数据，直接给拦住了——再加？那纯粹是给机房送温暖。
这种场景你应该不陌生吧？容量规划这事儿，说白了，就是在“资源浪费”和“扛不住高峰”之间走钢丝。很多团队要么是“阔少”心态，盲目堆配置；要么是“赌徒”心理，指望每次都能侥幸过关。真等流量洪峰来了，网站一挂，就不是钱的问题了，用户信任和品牌口碑的损失，那才是真肉疼。
今天，咱就抛开那些云厂商华丽的PPT话术，聊点实在的。怎么才能像老中医一样，把把脉就知道自家业务该用几斤几两的“药”，既不多花钱，关键时候还能顶上去。
第一步：别猜，先看清楚自己几斤几两（容量摸底）
很多人的规划是从“我觉得”开始的——这基本就输了一半。你得先知道自己家底。
- 核心指标是啥？ 别光盯着CPU和内存。对于Web服务，每秒请求数（QPS/RPS）、应用响应时间、数据库连接数和慢查询，往往比CPU百分比更能说明问题。我见过一个站，CPU才60%，但数据库连接池早就爆了，页面卡得跟幻灯片一样。
- 找到你的“阿喀琉斯之踵”： 一次完整的用户请求，会经过网络、Web服务器、应用代码、缓存、数据库等等。你得用压测工具（比如自己搭个JMeter，或者用云厂商提供的工具），模拟真实用户行为，一直打到系统出现瓶颈为止。瓶颈可能出现在任何地方——可能是Nginx的并发连接数设低了，也可能是某段垃圾代码拖慢了整个接口，又或者是Redis内存爆了。
- （这里插一句私货：很多团队一上来就堆机器，结果最后发现瓶颈是一行没加索引的SQL。钱没少花，问题纹丝不动，你说冤不冤？）
- 画出你的流量心电图： 看看你的监控图表。每天的波峰波谷在什么时候？每周呢？是早十点晚八点的“工位型”曲线，还是深夜活跃的“修仙型”曲线？电商有“大促心电图”，内容站有“热点心电图”。把这些规律摸清了，你才知道资源该在什么时候往上加。
第二步：别硬扛，学学“弹性伸缩”这门艺术
摸清家底后，你就明白了：按最高峰配置固定资源，是最大的浪费。现在的云环境，核心玩法就是 “弹性”。
- 分层解耦，动静分离： 这是基本功，但很多人没做到位。把静态图片、JS、CSS全都扔到对象存储（OSS）和CDN上，你的源站压力瞬间能少一大半。CDN那点流量费，跟服务器成本比起来，九牛一毛。
- 无状态设计是弹性基石： 你的应用服务，最好设计成无状态的。用户Session存到Redis里，别粘在本地服务器上。这样，流量来了，你才能像指挥舰队一样，从容地增加或减少“舰船”（服务器实例）。如果服务有状态，扩容缩容就是一场灾难。
- 用好自动化伸缩组（AS）： 这才是云时代的“智能管家”。别手动调了！根据你第一步摸清的指标（比如CPU>70%，或者QPS>某个阈值），设置好规则，让云平台在流量上涨时自动扩容，在低谷时自动缩容。
- 举个例子：你一个在线教育平台，晚上8点是直播课高峰。你可以设置策略，让系统在晚上7点半开始，慢慢增加20%的机器，到10点后再慢慢缩回来。这感觉，就像给房间装了个自动空调，省心又省钱。
- 数据库别成短板： 应用能弹性了，数据库要是顶不住，全白搭。对于读多写少的场景，用读写分离，把查询压力分散到只读实例上。核心写库，可以考虑选用支持计算存储分离、能够快速升降配的云数据库。关键时刻，临时升个配，可能比加一堆应用服务器还管用。
第三步：别迷信，实战演练才是试金石
规划做得再漂亮，不上战场都是纸上谈兵。定期压测和演练，是避免“真打就露馅”的唯一方法。
- 全链路压测： 别只在测试环境小打小闹。找个业务低峰期（比如凌晨），在生产环境，用影子流量或者隔离的压测环境，模拟真实大促的流量，完整地走一遍。只有这样，你才能发现那些在测试环境永远发现不了的问题：比如，第三方支付接口的限流、短信网关的并发能力、甚至机房带宽的瓶颈。
- 制定降级和熔断策略： 真到了极限怎么办？得学会“舍车保帅”。非核心功能（比如商品评论、推荐列表）可以准备降级方案，流量太大时直接返回简化结果或静态页面。对依赖的第三方服务，设置熔断器，防止它挂了把你整个系统拖垮。
- 说白了，就是提前想好，万一不行了，先“牺牲”谁，才能保住用户还能下单、付款这个最核心的流程。
最后说点大实话
容量规划，到最后其实是一种成本、性能和风险之间的平衡艺术。没有一劳永逸的方案，它必须是一个持续监控、持续调整的活。
- 别追求100%的可靠性： 那成本是指数级上升的。根据你的业务价值，定一个合理的可用性目标（比如99.9%或99.99%），然后为这个目标配置资源。为了那0.01%的可能性多花一倍的钱，很多时候不值当。
- 监控和告警是你的眼睛： 没有完善的监控，所有的规划都是盲人摸象。关键指标要有实时仪表盘，异常情况要能第一时间告警到人（别只发邮件，要接短信、电话）。
- 保持沟通： 和业务、产品、运营团队保持沟通。下次大促是什么时候？要推哪个爆款？有没有可能上热搜？这些信息，比你盯着历史曲线有用得多。
行了，道理就这么多。说到底，容量规划就像给家里备伞——你不可能天天背着，但得知道伞在哪，雨来了知道怎么最快撑开。别等到用户都在喊“网站怎么崩了”，才手忙脚乱地打电话给机房。
现在，不如打开你的监控后台，先看看过去一周的流量曲线？你可能会发现，第一个优化点，就在眼前。