旺季是一年之中物流集成要么证明自己、要么当众崩溃的时刻。订单量、费率请求、打单操作和承运商流量挤进同一个窄窗口，每一层都同时承压。活过 Q4 的团队，都是十月份就找到了自己断点的团队，而不是十二月份。这篇文章给你一套覆盖集成两侧的压测框架：上游承运商 API 和你自己拥有的系统。它是写给两类读者看的：工程师拿到可直接执行的场景（目标、触发方式、通过标准），管理层拿到决策闸门（签字放行需要什么证据、每轮压测该盯哪些信号）。全文只遵守一条规则：框架里的每一个目标数字，都来自你自己的流量预测和基线测量，不编造。
Q4 的额外负载不是均匀铺开的。订单量、费率请求和打单操作挤进同几天，经常在几小时内达到日常流量的数倍[^1]。一个应付得了普通周二的 API，在 Cyber Monday 可能毫无余量，因为峰值不是平稳的增长，而是把整个月压缩进几个小时。
让压力测试边界与Shipping API 技术总览保持一致，包括报价返回后的步骤；再结合WMS 接入验收测试同时检查恢复过程和数据一致性。
三层会各自独立地失败，只看其中一层的压测会漏掉大部分伤害。上游承运商 API 以限流和超时的形式失败；你的集成以线程耗尽、队列积压和丢失任务的形式失败；下游运营以对账缺口、重复面单和爆掉的客服队列的形式失败。每一层都有自己的故障模式、自己的触发方式、自己的修复方法，所以本文的场景按层组织，而不是按症状组织。
经典的失败链是机械且可预测的：
承运商的限流[^2]一到，重试就开始堆积，队列积压，打单变慢，链条末端是塞满「我的面单在哪」的客服收件箱。这条链上的每一步都可以在发生之前被测试。压测的意义，就是趁还有时间修复，自己先找到断点，而不是等承运商的限流器替你来找。
三个指标最重要，也最容易混为一谈。吞吐是系统在可接受延迟下每分钟能处理多少费率请求和打单。限流是系统在承运商文档标明的速率限制处、以及刚好越过它时如何表现。延迟是从请求发出到面单确认的端到端时间，包括在队列里等待的时间。一个系统可能在吞吐上通过、在延迟上失败：它最终处理了所有请求，但面单在客户预期之后十分钟才确认。
测试顺序和测量本身一样重要。先测吞吐，再测故障模式，然后恢复，最后一致性。吞吐失败最常见、修起来最便宜。故障模式的 bug 最危险，因为它们只在真实负载下现身。恢复和一致性关心的是出问题之后发生的事，只在快乐路径被证明之后才值得测。
本文的每个场景都是一张四字段卡片：目标、触发方式、通过标准、负责人。负责人不是装饰。正因为每张卡片写明了谁对目标和修复负责，工程师和管理层才都能审阅结果。每张卡片还写明数据来源，这样没人能在压测中途悄悄换上一个编造的数字。
目标：在性能不退化的情况下撑住预测的峰值费率请求量。触发方式：从基线开始逐步加压到你的峰值预测，每一步停留到系统稳定为止。通过标准：记录每一步的 P95 延迟[^5]和错误率；在到达预测峰值之前，错误率越过你的阈值或 P95 超出预算，就算失败。负责人：集成负责人。数据来源：你自己的流量预测，由去年峰值按增长调整而来。
目标：验证打单请求并行到达时的排队和超时行为。触发方式：以等于或高于峰值速率并发发出打单请求。通过标准：测量实际确认的面单速率，而不只是接受的速率；验证请求会排队而不是耗尽工作线程；确认没有任何请求在超时预算内无限挂起却不快速失败。负责人：后端负责人。数据来源：基线并发测量加上承运商文档标明的限制。
目标：证明重发同一个请求会返回同一个结果。触发方式：重放完全相同的请求，包括第一次尝试超时的请求，使用同一个幂等键[^3]。通过标准：每一次都不产生重复面单、不产生重复扣费、相同键返回相同响应。负责人：集成负责人。数据来源：你自己吞吐压测中的重放日志和超时日志。
这一节的预期产出，是一份按承运商、按端点记录的吞吐上限，以及幂等在重放下成立的证据。这些数字成为故障模式场景的预算：不了解健康时的上限，就无法判断一次宕机的伤害有多大。
目标：验证 webhook 迟到或乱序到达时，系统能收敛到真实状态。触发方式：在测试环境里延迟或打乱 webhook 投递，同时打单正常进行。通过标准：状态轮询和对账在你的恢复窗口内把真实状态捡回来，全程无需人工干预。负责人：集成负责人。
目标：验证 webhook 从未到达时的恢复能力。触发方式：把某个 webhook 完全丢弃，让面单停留在待处理状态。通过标准：重新同步或轮询任务自动恢复面单状态，缺口浮现在死信或对账报告里，而不是变成一张客服工单。负责人：后端负责人。
目标：验证承运商挂住时系统能快速失败。触发方式：模拟一个接受请求后永不响应的承运商，拖过你的超时预算。通过标准：请求在超时边界中止并移入重试队列，而不是占住一个工作线程；线程被及时释放，队列继续前进。负责人：后端负责人。
目标：验证一个承运商宕机、其他承运商正常时故障转移路由是否有效。触发方式：在测试环境把一家承运商离线，继续向它路由新流量。通过标准：流量故障转移到备用承运商或进入有界队列等待，而且团队能说明队列在多长时间内是安全的，超过才会错过截单。负责人：运营负责人。
目标：防止由恢复本身引发的第二次宕机。触发方式：用一个巨大的排队积压结束模拟宕机，然后一次性释放所有重试。通过标准：带抖动的指数退避[^4]防止承运商被第二次淹没，你自己的重试流量绝不越过承运商的速率限制。负责人：后端负责人。
目标：验证深积压下的干净重启。触发方式：停掉 worker，让队列增长，重启，然后测量排空过程。通过标准：排空顺序符合你的优先级规则，恢复过程不产生重复，恢复耗时达到你自己按批次截单设的目标，而不是拍脑袋。负责人：运营负责人。
目标：验证失败窗口内发生作废时，系统能收敛到一致状态。触发方式：在承运商超时或 webhook 丢失期间作废一张面单。通过标准：两侧系统在恢复窗口内收敛到已作废或已退款，没有任何面单停留在永久歧义状态。负责人：财务负责人与集成负责人共同承担。
目标：证明部分失败之后，账单记录仍然匹配现实。触发方式：在一轮部分请求失败、超时或重试的场景之后，把账单事件与实际创建的面单做对比。通过标准：没有无面单的扣费、没有无扣费的面单，每一处差异都可解释、有日志。负责人：财务负责人。
API 降级时，运营仍然要发货。每套压测框架都需要一条人工路径，而且这条路径要被测过，而不是想当然：验证后台手动建单流程，包括数据录入、承运商选择和确认步骤。
兜底必须在负载下测试，而不是只测一次。一个单个人工用户用起来没问题后台，在故障期间二十个操作员同时涌上来时可能就不可用了，所以要用峰值时预期的操作员并发数去跑兜底。
每一次兜底动作都必须有日志：手动建单、手动作废、手动改费率。如果兜底没有日志，它就会制造一致性场景抓不到的缺口，因为人工路径绕过了 API 正常的审计轨迹。一条有日志的人工操作是一个账单事件；一条没有日志的，是一张未来的争议。
推荐顺序是：先基线，再吞吐，然后并发、故障模式、恢复、一致性。先在普通的一天测量当前的吞吐、延迟和错误率，因为每个场景的目标都从这条基线和你的流量预测推导而来。每个场景都是一张写着目标、触发方式、通过标准、负责人和数据来源的卡片，整轮压测就是一张清单：工程执行，管理层审计。
每轮压测盯五个信号：队列深度、错误率、P95 延迟、重试次数、死信数量。它们会在一个场景正式失败之前，就告诉你系统正在接近边缘，而且它们就是旺季生产环境里要盯的那组数字。
决策闸门的形状很简单，做起来很难：只有当每个场景的每条通过标准都满足、至少一轮完整的故障模式跑下来零人工干预、而且签字人是带日期的具名负责人时，才放行。这个具名负责人让闸门变得真实，它把「API 大概没问题」变成「API 准备好了，这是证据」。
放行之后，任何变化都要重测：集成代码改动、承运商变化（新限流、新端点、新截单）、配置变化（超时、重试次数、队列大小、并发池）。重测不需要每次都跑完整序列，跑触及变化面的场景，重跑决策闸门即可。旺季惩罚那些用编造数字压测过的集成，奖励那些对着自己真实预测压测过的集成。
