沙场春点兵：全链路压测与系统容量评估实战手册

每年开春我都会给系统做一次大检阅，今年正好赶上项目第20个迭代节点，于是有了这场“沙场春点兵”。这里的“沙场”不是别的，就是线上生产环境的那几十个核心服务；“兵”则是每个接口、每条链路、每台机器、每份缓存数据。说白了，点兵就是一次系统级的性能容量盘点，把平时不敢碰、不想碰、假装没看见的问题全部拉出来遛一遛。

这篇文章想记录的，就是这次第20章点兵的全过程：从目标设定、压测准备、脚本编写，到监控定位、问题调优、团队复盘，是一份可以直接参考的操作手册。适合正在做性能测试、容量评估、架构巡检的运维、后端开发和SRE同学，也适合那些想把系统稳定性从“差不多”做到“心里有数”的技术团队。

1. 第20章点兵的由来：从业务背景到目标设定

1.1 为什么要在开春做一次全链路检阅

先说个背景。我们的系统是典型的电商中台架构，核心链路涉及商品、库存、订单、支付、营销五个域，平时日均请求量还行，但每逢节假日和平台大促，流量会突然蹿升到平时的三到五倍。往年吃过几次亏，都是促销刚开始半小时、数据库连接池先被打满，或者某个冷门接口因为缓存没预热直接拖垮了下游。

所以今年定了个规矩：每个大版本迭代结束，都要做一次“点兵”。第20个迭代刚好是春季版本，除了常规的功能上线，还涉及一次底层的订单分库分表方案调整，风险等级比平时高不少。与其等线上出问题再救火，不如把这些服务当作战场上的士兵，挨个点名、逐个考核，确认它们能在高并发场景下顶得住。

这种思路在工程上其实很朴素，就相当于运动员备战比赛前要拉一次体能测试。你做再多的代码评审、单元测试，都只能证明“功能是对的”，但证明不了“系统在压力下是稳的”。只有真正把流量打上去，看它扛不扛得住、哪里先垮、垮了能不能快速恢复，才算完成了点兵的核心目标。

1.2 点兵范围：谁是“兵”

点兵首先要搞清楚点谁。我们这次的清单分成了四层：

• 入口层：Nginx网关、API Gateway、鉴权服务
• 业务层：商品详情、购物车、下单、支付回调、库存扣减等12个核心接口
• 数据层：MySQL主库与从库、Redis集群、Elasticsearch、MQ消息队列
• 基础设施：容器CPU/内存水位、磁盘IO、网络带宽、连接池数量

每一层都指定了责任人。责任人的任务不只是“在场看着”，而是要对自己负责的“兵”写出能力基线——正常情况下它能扛多少QPS，极限情况下是什么表现，瓶颈大概在哪个环节。这些信息汇总起来，就是这次点兵的“花名册”。

另外还划了一条红线：只压测核心链路和冒烟场景，不碰用户真实数据，不做任何会产生脏数据的写操作。像支付回调这种接口，我们用的是Mock第三方返回值的方式，确保压测不影响线上账单和账务数据。安全永远是第一位的，点兵是为了发现风险，不是为了制造事故。

1.3 目标量化：把“稳”变成指标

光说“要稳”没用，得把稳翻译成可验收的指标。这次我们定了四项目标：

• 核心下单链路在双倍峰值流量下，接口RT的P99不超过500毫秒
• 全链路错误率低于0.1%，不允许出现雪崩式的级联超时
• 单接口极限压测时，QPS至少要比日常峰值高30%才算合格
• 所有依赖组件在压测期间不能出现连接池耗尽、磁盘写满、内存溢出等资源类故障

这几项目标不是拍脑袋定的，参考依据是过去三个月的监控数据。比如日常峰值时下单接口的QPS是800，那压测目标就是1200左右；P99平时在250毫秒上下，预留一倍余量，500毫秒算是合理值。目标定得太低测不出问题，定得太高又容易为了达标而过度优化，反而拖慢节奏。

我还特意要求把每个目标的验收条件写清楚，避免“差不多”“好像还行”这种模糊结论。比如“错误率低于0.1%”就明确为“以压测工具上报的成功请求数为准，排除压测客户端本身的超时误报”；“连接池不耗尽”就定为“连接池活跃数不超过最大值的80%，且等待队列长度始终为0”。指标越明确，后续复盘的时候就越有据可依。

2. 点兵前的准备：环境、脚本与数据

2.1 压测环境选择：为什么不能用线上裸打

说到压测环境，很多团队第一反应是“直接对线上压不就完了，最真实”。我的观点是：不到万不得已，不要这么干。线上环境掺杂着真实用户流量，你很难区分哪些RT上升是压测造成的，哪些是用户行为波动造成的；而且一旦压测流量触发了限流或熔断，遭殃的是真实用户。

我们这次采用的方式是“线上旁路+独立压测环境”混合。具体来说，新架构验证和极限压测放在独立的预发环境，这个环境的机器配置、数据库容量、网络拓扑和生产完全一致，数据用脱敏后的线上快照；而从入口网关到核心服务的完整链路摸底，则选择凌晨低峰期，用染色流量在线上做小流量验证。

这样做的好处有两个。第一，预发环境可以放开手脚压，压挂了也不影响线上；第二，线上小流量染色能验证一些预发环境覆盖不到的细节，比如跨机房延迟、真实的网络抖动、第三方依赖的真实响应时间。两边的数据互相补充，基本能还原出系统在真实压力下的全貌。

2.2 场景设计与脚本编写要点

压测脚本不是随便写几个HTTP请求就完事的，场景设计直接决定了点兵有没有意义。我们这次把场景分成了三类：

• 单接口基准压测：每个核心接口单独压，确认单个服务的处理能力和资源瓶颈
• 核心链路混合压测：模拟真实用户从浏览商品到下单支付的完整链路，按比例混合调用
• 突发流量冲击测试：模拟瞬时流量尖峰，观察系统的限流、熔断、降级策略是否生效

以最核心的下单接口为例，脚本里除了POST请求本身，还需要模拟登录态的Token、必要的请求头参数、随机化的商品ID和用户ID。压力模型用的是阶梯式递增，每30秒增加200并发，一直到接口出现明显拐点为止。这样做的目的是找到系统从“稳定”到“劣化”的临界点，而不是一上来就把流量拉满然后看它怎么死。

脚本编写上有一点特别提醒：参数化一定要做足。如果所有请求都用同一个商品ID和用户ID，Redis和数据库里那一条数据会被打爆，其他数据全都是空闲的，测出来的结果完全失真。我们这次用户ID用100万个脱敏账号做随机，商品ID从线上活跃商品池里随机取5000个，优惠券、收货地址等数据也做了对应的参数映射。实测下来，这样做出的结果和真实流量形态非常接近。

2.3 基础数据与参数准备

点兵最怕的是“测了个寂寞”，其中最常见的原因就是数据没准备好。举个例子，如果你在预发环境的订单表里只有一万条数据，而线上是几千万条，那么压测时数据库索引命中、缓存淘汰策略、冷热数据分布全都对不上，测出来的性能数据根本没有参考价值。

我们的处理方法是：提前三天从线上拉一份核心库的全量快照，经过脱敏后恢复到预发环境。所谓脱敏，就是把用户手机号、姓名、地址等敏感字段替换成假数据，但保持字段长度和分布特征不变；订单金额、商品数量、库存余量这些业务属性则原样保留。数据量级对齐之后，压测结果的置信度会高出很多。

另外一个容易踩的坑是数据膨胀。压测过程中会产生大量新的订单、流水、日志数据，如果不做清理，压测环境很快就会被撑爆。我们专门写了清理脚本，每轮压测结束后自动删除压测标记的脏数据，并且对订单表、库存流水表做一次表空间回收。数据准备和清理这两件事虽然不起眼，但直接决定了点兵过程能不能顺利推进。

3. 核心环节：点兵的实操过程

3.1 从单机到全链路：压测节奏怎么排

点兵的实操环节，我们严格执行“先单点、再局部、后全局”的节奏，绝不一上来就全链路压测。道理很简单：如果单个服务连基准线都达不到，全链路压测只会把问题混在一起，到时候你想定位到底是哪个服务拖了后腿，又得重新排查一遍。

具体安排如下：

• 第一天上午：对12个核心接口做单机基准压测，每个服务分别压出QPS上限和RT曲线
• 第一天下午：针对库存、订单、支付这三个在链路上最复杂的服务做局部链路压测，验证服务间的依赖是否健康
• 第二天全天：全链路混合压测，按真实流量模型分配各接口比例，观察全局表现

压测工具我们用的是开源的JMeter + 自研的流量染色网关。JMeter负责生成压力流量，染色网关负责给压测请求打上特殊标记，让下游知道这是测试流量，从而走独立的日志链路和监控报表。整个过程通过Grafana大盘实时观察每个节点的QPS、RT、错误率和CPU、内存、磁盘、网络等指标。

实操中有一个很关键的动作：每一轮压测开始前，主负责人要先喊一句“开始压测”，确认所有观察人员都在看大盘；压测结束后再喊一句“停止压测”，确认流量归零。这个约定看似多余，但能防止“压测都结束了，监控组还在盯着一堆假数据分析”的乌龙。点兵是团队协作，不是一个人闷头压。

3.2 监控与定位：一边压测一边看什么

压测跑起来之后，最难的不是产生流量，而是在一堆跳动的指标里快速判断系统到底行不行。我自己的经验是：不要眉毛胡子一把抓，而是按“先看全局、再看链路、最后看单点”的顺序来。

全局层面，第一个看的是错误率曲线。只要错误率开始抬头，不管RT多好看，都要立刻停止加压，先查清楚错误是从哪个节点冒出来的。我们这次压测到第40分钟的时候，错误率从0突然蹿到0.5%，排查后发现是压测客户端的连接复用配置有问题，跟服务端本身没有关系——这类误报很常见，所以定结论之前一定要先排除工具侧的因素。

链路层面，重点盯Trace中的耗时分布。我们接了OpenTelemetry，压测期间所有请求都会生成完整的调用链数据。打开下单接口的Trace，能看到Redis访问耗时、数据库SQL耗时、MQ发送耗时分别占了多少。一旦RT上升，顺着Trace就能快速定位是哪个依赖变慢了，而不是靠猜。

单点层面，关注的指标是CPU使用率、内存GC频率、线程池活跃数、数据库连接池活跃数。这里分享一个小技巧：不要只看平均值，要看P99和MAX。很多服务的CPU平均值看起来只有40%，但压测时瞬间冲到90%，这时候其实已经接近瓶颈了。我们有一台中间件节点就是这种情况，平均CPU不到30%，但每次流量抖动时线程数都会翻三倍，最终锁定了线程池大小配置不合理的问题。

3.3 关键指标解读：QPS、RT、错误率与资源水位

点兵结束后，我们收到了几百张监控截图和几十万行压测日志，这时候最考验人的就是指标解读能力。我一贯的观点是：不要单看某一个指标下结论，要把QPS、RT、错误率、资源水位串起来看。

举一个这轮点兵中很典型的例子：商品详情接口在QPS达到1500时，RT从120毫秒涨到800毫秒，但错误率依然为0。单看错误率，系统好像没问题，单看RT，又觉得已经不可用了。这时候把CPU和内存数据拉出来看一眼，真相立刻浮出水面——该服务所在的容器CPU已经跑满，GC暂停时间从平均5毫秒涨到200毫秒。结论就很清楚了：CPU资源不足，需要扩容或优化逻辑，而不是数据库或缓存的问题。

反过来也有一种情况：QPS上不去，但CPU、内存都还有大量余量，错误率也很低。这时候通常不是性能问题，而是限流阈值或者线程池大小卡住了。我们这次在营销优惠券接口就遇到了这种情况，排查后发现是Sentinel限流规则里配置的单机QPS阈值写低了，还是去年大促时定的值。这提醒我们：限流配置要定期review，尤其是业务增长快的时候，老阈值很可能成为新的瓶颈。

4. 点兵发现的问题与调优实录

4.1 典型案例：数据库连接池被打满

点兵进行到全链路混合压测的第一轮，下单接口的P99直接飙到1.2秒，错误率1.8%。当时的直观感受是：兵还没出发，马厩先着火了。顺着Trace一路查下去，发现瓶颈出在订单库的连接池上。

连接池的初始配置是最大50个连接，平时跑业务完全够用，但压测流量一上来，瞬间有大量请求同时申请数据库连接，活跃连接数很快撞到50的上限，后续请求只能排队等待。数据库侧的CPU和磁盘其实都还有余量，纯粹是连接池这个“门口”太窄了。

调优方案分两步走。第一步是应急调整：把连接池最大值从50提升到150，同时调大等待队列长度，让请求在排队时不至于立刻超时。第二步是长远优化：对下单链路的SQL做了一次审计，发现有些慢查询本来可以走索引却走了全表扫描，根源是ORM框架生成的SQL里关联条件顺序不对，导致优化器选错了索引。修正后，单条SQL的执行时间从80毫秒降到了10毫秒。

雷排完之后，我们又做了一轮回归压测，同样的流量模型，P99落到了280毫秒，错误率归零。这件事给团队的教训是：连接池参数不能“配一次用三年”，每次大版本迭代后都要根据预估流量重新计算。

4.2 典型案例：缓存穿透与热点Key

另一个有意思的问题是库存服务的缓存热点Key。压测混合场景里，有大量请求都在查询同一个爆款商品的库存余量，这个商品的Key在Redis里被访问的频率比其他Key高出两个数量级，直接导致Redis单分片的CPU使用率达到95%，请求延迟从0.5毫秒涨到30毫秒。

一开始我们以为是Redis集群节点分布不均，后来用redis-cli --hotkeys查了一下，发现热点高度集中。解决方案是热点Key本地缓存：在应用层增加了一层Caffeine本地缓存，热点数据先查本地，本地没有再去查Redis，并且设置了一个较短的过期时间（5秒）来保证数据不过期太久。改造之后，Redis单分片CPU降到60%以下，接口P99下降了40%。

这个问题的核心教训是：缓存不是越多的越好，而是要在不同层级之间做合理分流。Redis再快，也扛不住单Key的极端热点；本地缓存再近，也要考虑数据一致性。用“本地缓存兜底热点、Redis承载常规流量”的组合方式，是目前我们在热点问题上比较成熟的解法。

4.3 调优后的对比数据

上面两个典型案例调完之后，我们专门做了一轮完整的回归压测，把调优前后的数据放在一起对比：

数据不会说谎。点兵前我们自我感觉系统状态还行，点兵后才发现有这么多隐藏问题。如果不是提前做了这轮压测，这些问题大概率会在春季大促当天集中爆发，到时候一边接客诉一边救火，代价就完全不一样了。

5. 点兵也点人：团队协作与应急预案

5.1 职责分工与复盘机制

“沙场春点兵”还有一种解读：点的不只是系统，也是人。系统是士兵，但指挥士兵的是团队。第20章点兵执行下来，我发现分工和复盘机制比压测工具本身更能决定成败。

我们在点兵启动前就拉了一个在线文档，明确每个人在压测期间的职责。压测总指挥负责控制流量节奏，只有他有权决定加不加压；监控组负责盯大盘和告警，一旦出现异常立即在群里同步；服务责任人负责对自己服务的指标做解读和初步排查；应急小组负责处理压测引发的真实故障，比如误伤线上数据或服务假死。每个角色都有AB角，避免压测到一半负责人被拉去开会导致现场无人盯防。

复盘会放在点兵结束后的第二天。不是对着PPT念稿子，而是直接把压测期间的监控看板和故障时间线投影出来，从第一个异常指标开始，逐环节问三个问题：为什么当时没发现？发现了为什么没及时处理？处理了为什么还会再次出现？这种追问式的复盘可能会让一些人觉得压力大，但确确实实能把问题挖到根上。

5.2 应急预案演练：从脚本到实战

这次点兵还干了一件事：把应急预案从“文档里的字”变成了“实操中的动作”。我们挑选了三个最常见的故障场景做演练，分别是核心服务宕机、数据库连接池耗尽、依赖的第三方接口长时间无响应。

演练方式不是简单地把服务停掉然后重启，而是通过混沌工程工具随机杀掉一个Pod、模拟网络丢包、注入数据库慢查询，让团队在不知情的状态下处理故障。第一次演练结果不太好看：服务宕机后，值班同学花了6分钟才完成告警确认和重启操作，远超SLO里规定的2分钟。第二次演练在告警规则和重启脚本做了优化后，耗时降到了1分40秒，勉强达标。

2024年有一个很受重视的工程理念叫“混沌工程”，核心思想就是通过主动注入故障来验证系统的韧性。这回点兵我们算是真正实践了一把。演练结束后，我们把应急预案里的关键操作全部脚本化、工具化，比如一键重启、一键摘流量、一键降级，尽量让应急处理不需要靠某个人的“临场发挥”，而是靠标准动作。

5.3 归档与持续跟踪

点兵最大的价值，不在于压测那两天发现了多少问题，而在于结束后有没有把成果固化下来。我们做了三件归档的事：

第一，是更新了服务能力基线文档。每个核心接口当前能扛多少QPS、P99是多少、瓶颈在哪个环节，全部写清楚。这份文档是后续容量规划和扩容决策的重要依据。

第二，是建立了问题跟踪清单。点兵中发现的每一个问题，无论大小，都分配到具体负责人并设定了解决期限。这些问题会挂在迭代看板上，状态从“待修复”到“已修复”，再到“回归验证通过”，每一步都有记录。

第三，是沉淀了自动化的压测流程。我们把压测脚本、数据准备、监控大盘、报表生成全部固化到CI/CD流水线里。以后只要在流水线上触发一个参数，就能在预发环境快速跑一轮冒烟压测，不用再像这次一样手动准备半天。做这件事的初衷很简单：点兵不能只是每年一次的大工程，更应该变成随时可以发起的“日常体能训练”。

归档完成的那一刻，我最大的感受是：第20章虽然叫“沙场春点兵”，但点兵的真正意义从来不在“点”这个动作，而在“点完之后系统是不是真的变得更稳了”。如果你所在的团队正准备做类似的性能盘点，我的建议是：别把目标定得太复杂，先解决“哪些兵必须点、点完怎么验收、发现问题谁来跟”这三件事，后面的一切都会顺很多。