一、痛点场景：单点压测全绿，一上大促全崩
双11大促是对物流架构的终极考验。很多团队在备战期会做压测：单独压测订单创建接口，能扛5000 QPS；单独压测分拣接口，也没问题。但真正到了零点，系统却瞬间瘫痪。
原因在于：单点压测是“假安全”。单接口压测时，下游依赖往往被Mock（模拟）掉了。但当真实流量洪峰到来时，网关、应用、数据库、消息队列、第三方接口在同一秒内争抢资源。一个不起眼的慢SQL，或者第三方电子面单接口的超时，就能引发雪崩式的线程池耗尽。
双11备战的本质，是在资源有限的前提下，建立“弹性扩容、链路压测、分级降级”的三位一体防线。
二、弹性扩容：从“人工预估”到“指标驱动”
2.1 为什么传统扩容会失效
以往双11，团队会提前三天手动把服务器数量翻倍。但这带来了极大的资源浪费（峰值往往只有几个小时），且一旦流量预测偏差，系统依然会崩。
2.2 K8s HPA 与业务指标结合
云原生时代，我们使用 K8s 的 HPA（Horizontal Pod Autoscaler）实现自动扩容。但千万不能只依赖 CPU 和内存。在 Java 应用中，CPU 达到 80% 时，系统可能已经处于假死或队列严重积压状态，此时扩容已经来不及了。
必须引入自定义业务指标（Custom Metrics），如“消息队列积压长度”、“Tomcat活跃线程数”或“打单队列排队数”。
yaml
# HPA 配置示例：基于业务积压量扩容 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 10 maxReplicas: 100 metrics: - type: Pods pods: metric: name: order_queue_backlog # 自定义指标：订单积压数 target: type: AverageValue averageValue: 500 # 单个Pod积压超过500时触发扩容
避坑：Java 服务扩容时，JVM 冷启动需要时间。大促前必须保留一定数量的“预热Pod”，或者使用阿里云的 JVM 启动加速技术，避免扩容的机器还在启动，旧机器已经被压垮。
三、全链路压测：流量染色与影子库
3.1 压测不能污染生产数据
直接在生产环境压测，会产生大量假订单，导致库存被扣减、财务账目错乱。解决方案是流量染色（Traffic Coloring）。
压测请求在网关层被强行打上特定的 HTTP Header（如X-Stress-Test: true）。该标记会沿着微服务调用链（通过 OpenFeign 或 Dubbo 的隐式传参）一直透传到底层。
java
// 数据源路由拦截：识别压测流量，切换到影子库 public class ShadowDataSourceInterceptor implements Interceptor { @Override public void beforeQuery(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { if (isStressTestRequest()) { // 将压测流量的SQL重写，路由到影子表 // 例如：order_table 替换为 order_table_shadow throw new RedirectToShadowException(boundSql.getSql()); } } }3.2 压测覆盖全链路
压测场景必须覆盖：零点峰值建单、并发扫码揽收、批量分拣、轨迹回传。压测不仅是测应用服务，还要看数据库连接池、Redis QPS、Kafka 消费延迟。只有找出系统最先达到 100% 负荷的那个节点（木桶的最短板），才能针对性地做扩容。
四、分级降级：丢车保帅的工程艺术
当系统压力超过极限，必须主动放弃非核心功能。
我们设计了四级降级策略：
L1（接口延迟）：关闭实时报表查询，将运营看板的刷新频率从5秒降为60秒。
L2（依赖超时）：对第三方轨迹查询接口实施熔断，返回缓存的最后一次轨迹。
L3（数据库保护）：关闭历史数据查询（超过30天的运单），强制走离线归档库。
L4（核心保底）：暂停营销通知下发，全力保障“建单、分拣、发货、轨迹入库”四个核心动作。
降级的触发必须是自动的，基于 Sentinel 的熔断规则，而不是靠人工盯盘。降级期间的错误提示必须对用户友好（如“系统繁忙，稍后重试”），而不是抛出满屏的 500 错误。
五、总结
应对大促，架构师不能靠“拍脑袋”扩容。要靠 K8s 的自定义指标弹性伸缩抗住增量，靠全链路压测和流量染色找出系统短板，靠四级降级策略守住核心底线。真正的高可用，不是系统永远不宕机，而是系统在极端压力下，依然能“优雅地降级”，并在洪峰后自动恢复。
下一篇预告：说完了后端基础设施，我们把目光转向仓库。大促发货多，客户经常投诉“少件/多件”，明天聊称重校验如何从源头把差异拦截在出库之前。
> 本文作者：深圳＋Eyf•半字节科技▪技术产品团队
> 物流、快递、快运作业管理系统，让每一票，都清晰可控。从任务分配到签收回传，一站式管理每个作业环节。
