全链路压测前的容量评估：一次真实大促前的准备复盘

做了十一年IT咨询，带客户过大促前的全链路压测，几乎是每年都要上演的固定节目，一牙咬着不放。要说压测本身，工具和脚本都是现成的，拿来就能用，真正决定成败的，是压测之前那一轮容量评估做得扎实不扎实，这一步是分水岭。评估做透了，压测就是走个过场验个数据，顺顺当当；评估做得糊，压测现场就会变成大型翻车现场，一遥遍地重来，谁都难受，客户在旁边看着也揪心。这一篇就拿去年一家零售客户的大促备战来当例子，把容量评估的整套流程，从头到尾摊开来讲，讲给正在备战大促的同行们听，少走些弯路。

一、容量评估要回答的三个问题

开工之前先要把目标定清楚，目标不清，后面全乱。容量评估说到底，就是回答清楚三个问题：系统当前的容量水位在哪里、大促的峰值流量到底会有多大、中间的缺口又该用什么方案去补上。这三个问题一个都绕不开，缺了一个，后面的活都是白干，拖到末了还得回头补课。为什么要把问题定在前面？因为容量评估从来不是一次性交差的报告，而是一场能持续一个月的持久战，中间随时都要回头改数字、改方案、改优先级，目标不定牢，改着改着就改成了一锅浆糊，谁也说不清当初为什么这么定。

1.1 现有水位怎么摸清

摸水位的办法就是拿历史数据说话，数据从来不说谎，人嘴才会。我们把客户系统过去十二个月的监控数据全部拉出来，按天算出核心接口的调用量曲线，再挑出几个历史峰值日做基准：日常的均值是多少、历史的峰值是日常的几倍、峰值又持续了多长时间，三个数字一列，现有系统的家底就基本清楚了，心里就有了一本明明白白的账。这一步千万不能拍脑袋，一拍就要坏事，监控数据就是唯一可信的依据，别的一概不算数，凭印象估出来的数字，后面全都要还债，一牙还得比一牙疼。

1.2 峰值流量怎么预估

大促的流量预估要拆开来算。运营那边给出活动页面的预估访问量，交易那边给出预计的订单量和下单的转化路径，再结合历史上几次大促的放大倍数，一层一层地推算出各个核心接口的峰值调用量来。这里头有个实用的小技巧：不要只算一个总的峰值，要按时间轴拆出流量曲线，开场起初的那十分钟往往是洪峰里的洪峰，秒杀开始的那一秒更是尖峰里的尖峰，一个比一个狠，容量就得按尖峰来配，不能按平均去配，这条原则一寸都不让。按平均配容量，跟穿短袖过冬天是一个道理，非冻出毛病不可。还有一个细节容易忽略：预热流量。大促开始前的几天，用户会反复地翻购物车、反复地比价、反复地刷新页面，这些零碎的小动作一层一层叠加起来，往往在大促前一天就把系统压得喘不过气，预估流量的时候就必须把这一段也一并算进去，不能光盯着正日子那几个小时看，眼光要放长一点。

二、依赖梳理：把链路画全

容量评估的第二步要干的活是把系统的依赖链路画全，画到一张图上，一张不落。这一步格外地费工夫，也格外地容易出纰漏，十个项目里有八个都要在这里绊上一跤。画图的办法很土：拉上开发、运维、业务三方坐进一间屋，从用户点下下单的那个按钮开始，一个调用接着一个调用地往下过，谁也别嫌烦，过完一遍再倒回来查漏补缺，查出来的每一根线都给它上图，一张图越画越全。

2.1 强依赖与弱依赖分清

一条链路上的依赖要分成两类：强依赖挂了，业务直接中断，比如库存服务、支付通道；弱依赖挂了，体验受损但业务还能走，比如推荐服务、积分服务。做这个分类的意义就在于资源怎么分配：强依赖要按尖峰容量做冗余，一台都不能少；弱依赖只要保住降级路径就行。去年这个客户一上来没做分类，所有服务都要求双倍资源，预算直接就爆了；分清强弱之后，资源预算砍掉了三分之一，保障反而更到位，老板看了也直点头。

2.2 容易被漏掉的第三方

链路梳理里格外容易漏的是第三方依赖：短信的通道、风控的接口、对象存储的带宽、数据库的连接池，这些要么有配额上限，要么有并发限制，压测的时候本地测得好好的，真到峰值一打，先倒下的往往就是它们，一倒还带出一串连锁反应。我们的做法是把每一个第三方的配额上限列成清单，逐一去确认、去申请扩容，一个都不许跳过；这一步做完了，心里的底才算落下一半，剩下的一半要靠后面的压测去验。去年这家客户就查出来，短信通道的配额只申请了日常的三倍，可预估的峰值却是日常的八倍，差着老大一截，提前申请扩到了十倍，大促当天一条验证码都没卡住，顺顺当当，这就是清单的功劳。

三、瓶颈推演与预案

3.1 单接口压测摸天花板

全链路压测之前，先要做单接口的小范围压测，把每一个核心服务的容量天花板都摸出来：应用服务器单机能扛多少并发、数据库能撑住多少连接、缓存又能扛多少读写，一个个都得有准数。这些数字拿到手，全链路压测的加压策略才有依据，不然加压就是盲加，加到哪里算哪里，出了问题都不知道该往哪里看。单接口压测还有个附带的好处：能把短板提前暴露出来。去年就是在这一个环节里，发现订单服务的连接池给配小了，单机压到四百的并发就开始报错，改了配置之后，单机的容量直接翻了一倍，一台机器当两台用，省下来的可都是真金白银，看得见摸得着。

3.2 一段容量估算的脚本

容量推算的时候，我习惯用一个简简单单的脚本把各服务的缺口算出来，免得手算出错，大致长这样：

# 容量缺口估算：峰值QPS与单机容量的推算
services = {
    "gateway":  {"peak_qps": 12000, "single_cap": 3000, "replicas": 4},
    "order":    {"peak_qps":  4500, "single_cap":  900, "replicas": 4},
    "inventory":{"peak_qps":  6000, "single_cap": 1500, "replicas": 3},
    "payment":  {"peak_qps":  3000, "single_cap":  800, "replicas": 4},
}

for name, s in services.items():
    capacity = s["single_cap"] * s["replicas"]
    gap = s["peak_qps"] - capacity
    status = "OK" if gap <= 0 else f"NEED +{int(-(-gap // s['single_cap']))} 台"
    print(f"{name:10s} 峰值={s['peak_qps']:>6} 现容量={capacity:>6} {status}")

脚本本身不难，难的是里面那几个数字要拿真实的压测数据填进去，一个数字都不许编，编了就是埋雷。数字不真，算得再漂亮也是自欺欺人，上了线就要现原形，谁也瞒不住。每一年我都会把这个脚本翻出来跑一遍，数字年年都在更新，框架却年年不变，一直好用得很。

四、预案与降级的排练

容量评估到末了的产出不只是那几页数字，更重要的是一套预案：哪个服务过载了就触发什么降级、降级之后用户的体验怎么保、由谁来拍板执行，一条一条都写得清清楚楚、明明白白。预案写出来之后还必须要演练，不演练的预案等于没写，纸上看都好，真拉出来一遇事就歇菜。演练就要真刀真枪地干：在预发的环境里模拟服务过载，看降级开关生不生效、看值班的人知不知道自己该干什么、看告警发出来多久有人认领，一样一样地过。去年演练的时候我们发现积分服务的降级开关压根不生效，提前两周发现的，又用两周把它修好；要是拖到大促当天才发现，那后果真不敢想，想想都后怕。演练这件事，练的不只是系统，更是人，是整个团队在高压之下的肌肉记忆，这个记忆只有靠一遍又一遍地练才能长出来，没有捷径可走，谁也偷不了这个懒，练一次有一次的底。

五、小结

全链路压测前的容量评估，做的是大促之前头等要紧的一门功课：历史数据摸清家底、流量预估定准目标、依赖梳理找齐短板、单接口压测摸明天花板、预案演练兜住底部，这五步一步都不能省，省了哪一步，哪一步后面就要出事，次次都是如此，没有例外。评估做得越细，压测的时候心里就越有底，大促当天晚上觉也睡得越踏实，不用睁着眼睛到天亮。容量这件事，从来没有临场发挥这一说，只有提前算好的账；账算清了，人才不慌，事才不乱，这一行的规矩从来就是这样，谁来了也一样。