促销活动那天晚上八点我盯着监控面板上那条一直往上蹿的线手心里全是汗。QPS每秒请求数Queries Per Second从平时的三千冲到两万四翻了正好八倍。扩容按钮我按了四回第五回按下去的时候新节点还在慢慢启动老节点的 CPU 已经烧到了 98%。那天晚上我没敢合眼咖啡灌了三杯天亮的时候流量终于退了我也差点交代在工位上。后来复盘我意识到问题根本不在手速不够快而在一个我一直没想明白的事——容量规划Capacity Planning这活儿到底该不该由人临阵来做。先跟你说说我以前的做法。每逢大促前一周我就开始拍脑袋按去年的量翻三倍估吧多备三十台机器。然后拿这个数字去找运维申请资源。结果就是两头挨打要么备多了机器空转一个月账单看着肉疼要么备少了就像那晚一样临时手动加节点慢得让人绝望。手动拉起来一台机器光初始化、注册、预热怎么也得三五分钟而流量根本不会等你这三五分钟。这里得插一句闲话。我们组有个老哥号称手动扩容之王每次大促都守在机房双手悬在键盘上跟钢琴家似的。他真能在几十秒里敲完一串命令把三台机器拉起来我们都挺服气。可服气归服气那晚他也一样手忙脚乱——因为流量是乘八倍涨上来的他手速再快也追不上那个斜率。所以问题到底出在哪出在我把扩容当成了一件必须有人在现场做的活儿。可它其实是两件事一件是知道该扩多少一件是能多快扩起来。前者叫容量规划后者叫自动扩缩容Auto Scaling。先聊聊自动扩缩容。在 Kubernetes 里它有个很常见的实现叫 HPAHorizontal 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 了评论区说说你的故事。下篇我打算聊聊扩容之后那些看起来扩了、其实根本没扩到点上的隐藏坑挺有意思的咱们下次见。
