一、项目背景

网关流量随业务起伏很大，大促期间峰值能到平时的五六倍。但团队心里完全没底：这台网关到底能扛多少，什么时候该扩容。先前大促前只能按经验拍个倍数盲目加机器，闲置时又浪费。一次大促曾因预估不足，开场十分钟网关延迟飙升，部分请求超时，被业务投诉了一整天，运维同学连夜加机器才勉强压住。事后复盘，根本说不清到底是容量不够还是某个配置错了，两拨人互相甩锅。

二、落地场景

我们建立了一套常态化的压测与容量评估机制：用流量回放加阶梯加压的方式，从日常水位逐步打到极限，全程采集延迟、错误率、吞吐和资源占用。测试不是一次性，而是每月固定跑、大促前必跑。跑完产出一份容量拐点报告，明确标出安全水位、告警水位、崩溃水位三条线，扩容决策直接照线执行，不再靠谁嗓门大。报告同时给出推荐实例数和成本测算，让容量决策有据可依，老板看一眼三条线就知道这次该花多少钱。

三、关键技术挑战与解决思路

压测最难的不是打压力，是打像的压力。我们用了线上流量回放，把真实请求按比例抽样重放，比纯随机请求更贴近实际。难点在拐点判定：延迟缓涨不算拐点，我们定义错误率突破 1% 且 P99 延迟翻倍为崩溃水位，P99 延迟达目标值两倍但错误率仍低于 0.5% 为告警水位。为避免压测本身影响线上，我们全在隔离环境跑，用生产同规格实例，保证结论可迁移。回放时还特意混入长短请求混合比，复现真实毛刺。压测脚本按场景参数化，换业务线只需改配置，不用重写。

四、效果数据

机制运行约五个月，完成常态化压测九次、大促专项三次。最近一次评估给出：单网关实例安全水位约每秒一千二百请求，告警水位约一千八百，崩溃水位约两千二。据此大促前精准扩容到三实例，开场峰值约每秒一千六百请求平稳承接，零超时。相比此前盲目扩五台的惯例，单次大促节省闲置资源约四成。告警水位触发后的自动降级预案也在演练中验证过，可在一分钟内生效，那次大促即便真有突发也能兜底，运维终于敢安心回家了。

五、可复用经验总结

容量评估别靠猜，靠压测数据说话，这是我们交了超时投诉的学费换来的。流量回放比合成流量靠谱太多，前者能暴露真实请求里长短句混杂带来的性能坑，后者永远一片祥和。拐点定义要量化，拍脑袋的差不多到顶了最害人，出了问题谁都担不起。压测环境必须和生产同规格，否则结论就是空中楼阁，我们试过用低配机压测导致误判，后来一律对齐规格。报告里的三条水位线，比任何经验值都好使，也方便跟老板解释为什么这次只加三台而不是五台。

结语

容量评估这件事，我们是用一次大促超时投诉的学费换来的重视。那回开场十分钟网关延迟飙升，业务骂了一整天，我们连夜加机器才压住，事后还吵不清是容量还是配置的问题。从那以后压测成了铁律，每月跑、大促前必跑，谁也别想省略。流量回放是我们踩过合成流量坑之后才坚定用的，前者能暴露真实请求里长短句混杂的性能问题，后者永远一片祥和骗自己。现在三条水位线往那一摆，扩容决策不用再拍脑袋，老板看一眼就知道该花多少钱。告警水位触发后的自动降级预案也演练过，压测环境必须和生产同规格这条也是用低配机误判交过的学费，说到底容量不是扩出来的而是测出来的，这句话我们现在逢新人都讲一遍。

告警水位触发后的自动降级预案也演练过，真有突发能在一分钟内兜底，不再像以前那样干瞪眼。压测环境必须和生产同规格这条，也是用低配机误判交过的学费，现在谁提省这台机器都会被否。说到底容量不是扩出来的而是测出来的，省得后人再踩一遍我们踩过的坑。

现在我们每个月固定跑一次全量压测，大促前再加一场专项，报告里的三条水位线直接进扩容评审，谁想省机器都得先过这关，再没人能靠拍脑袋把容量定下来。压测脚本参数化得很好，换业务线改配置就能复用，运维同学也从救火队员变回了规划者，这件事对整个团队的节奏改善比多扛几倍流量都实在。

案例片段（已脱敏）： 阶梯加压结果（单实例）： 800 req/s：P99=180ms，错误率 0% 1200 req/s：P99=260ms，错误率 0.1%（安全水位） 1800 req/s：P99=520ms，错误率 0.4%（告警水位） 2200 req/s：P99=1100ms，错误率 1.3%（崩溃水位） 结论：日常峰值约 900 req/s，预留余量后大促按 1600 req/s 规划，部署三实例，单实例负载约 530 req/s，处安全区。实际大促峰值 1580 req/s，P99 稳定在 240ms，未触发任何告警，扩容方案一次命中，事后复盘无争议。