企业官网建设流程全解析

促销活动那天晚上八点，我盯着监控面板上那条一直往上蹿的线，手心里全是汗。QPS（每秒请求数，Queries Per Second）从平时的三千冲到两万四，翻了正好八倍。扩容按钮我按了四回，第五回按下去的时候，新节点还在慢慢启动，老节点的 CPU 已经烧到了 98%。那天晚上我没敢合眼，咖啡灌了三杯，天亮的时候流量终于退了，我也差点交代在工位上。

后来复盘，我意识到问题根本不在"手速不够快"，而在一个我一直没想明白的事——容量规划（Capacity Planning）这活儿，到底该不该由人临阵来做。

先跟你说说我以前的做法。每逢大促前一周，我就开始拍脑袋："按去年的量翻三倍估吧，多备三十台机器。"然后拿这个数字去找运维申请资源。结果就是两头挨打：要么备多了，机器空转一个月，账单看着肉疼；要么备少了，就像那晚一样，临时手动加节点，慢得让人绝望。手动拉起来一台机器，光初始化、注册、预热，怎么也得三五分钟，而流量根本不会等你这三五分钟。

这里得插一句闲话。我们组有个老哥，号称"手动扩容之王"，每次大促都守在机房，双手悬在键盘上，跟钢琴家似的。他真能在几十秒里敲完一串命令把三台机器拉起来，我们都挺服气。可服气归服气，那晚他也一样手忙脚乱——因为流量是乘八倍涨上来的，他手速再快也追不上那个斜率。

所以问题到底出在哪？出在我把"扩容"当成了一件"必须有人在现场做的活儿"。可它其实是两件事：一件是"知道该扩多少"，一件是"能多快扩起来"。前者叫容量规划，后者叫自动扩缩容（Auto Scaling）。

先聊聊自动扩缩容。在 Kubernetes 里，它有个很常见的实现叫 HPA（Horizontal Pod Autoscaler，横向 Pod 自动伸缩器）。你可以给它定一条规则：比如"当 CPU 平均使用率超过 60% 时自动把副本数往上加，低于 30% 时往下减"。就这么一条规则，机器自己知道什么时候长、什么时候缩。流量八点上来，它七点五十九就已经在偷偷加副本了，根本不用我伸手去按那个扩容按钮。

再插一句闲话。有次我把 HPA 的最小副本数设成 2，想着够用了。结果促销当天流量没起来，它就老往 2 上缩，缩到 2 又因为请求挤上来弹回 4，来回来去抖个不停，那画面跟神经衰弱似的。后来我才知道这现象叫"抖动"（Thrashing），得给扩缩加上冷却时间，别让它反应那么激进，否则资源白白空转。

自动扩缩容能解决"快"，但它解决不了"该扩多少"。要是底座本身一共就 10 台机器的容量，流量涨到 8 倍，HPA 再拼命扩也是白搭——它把集群撑爆也变不出那么多算力。所以容量规划还是得人来做，只不过不是"临阵拍脑袋"，而是用数据提前算好。

我把这套改过来之后，效果是这样的：大促前我不再拍脑袋，而是拉出过去半年每个小时的 QPS 曲线，叠上这次促销的预期增量，用简单的线性外推（Linear Extrapolation）估出一个峰值区间，把集群的"水线"抬到能扛住这个峰值的八成，剩下两成交给 HPA 去动态补。真到峰值来的时候，HPA 自己往上加，峰值走了它自己缩。那晚我不再需要守机房，流量涨到两万五的时候副本数已经悄悄翻了三倍，面板上风平浪静，我甚至泡了杯茶。

但我也得跟你说句实话，这套东西不是没有坑。HPA 依赖的指标要是没采集准，它就会瞎扩。有个特别经典的陷阱是拿 CPU 平均值当唯一依据——万一某个 Pod 卡在等待外部 API 返回，CPU 看着不高，可用户已经排起长队了，HPA 却一点反应都没有。所以更稳的做法是盯跟用户体验直接相关的指标，比如 P95 延迟（95% 的请求在多少毫秒内返回），或者干脆用自定义的业务指标。

聊到这儿，你大概也能自己掂量掂量了。这套"容量规划 + 自动扩缩容"的组合，谁适合碰？如果你经常对着流量峰值熬夜手动扩容，或者因为扩得慢被客户吐槽过，那真值得花一周把 HPA 和指标采集理清楚，投入产出比很高。那谁又不适合呢？如果你的系统流量特别平稳，一年到头波动不超过两三成，那手动预留一点余量就够了，硬上 HPA 反而多一套配置要维护，属于给简单问题添复杂，得不偿失。

我自己最大的感受是，这条路走下来，真正值钱的不是那套自动扩缩的配置，而是我被迫把"我的系统到底能扛多少"这件事想明白了。以前它是玄学，现在它是数字，是清清楚楚写在面板上、随时可以查证的指标。

今天就聊到这。你有没有哪次也是被流量峰值狠狠教育过？你现在是还在手动扩容，还是已经交给 HPA 了？评论区说说你的故事。下篇我打算聊聊扩容之后那些"看起来扩了、其实根本没扩到点上"的隐藏坑，挺有意思的，咱们下次见。