企业官网建设流程全解析

上篇回顾：Day 84 用 Arthas 在不重启 JVM 的情况下五分钟定位生产故障、热修复走紧急发布。但单点诊断解决的是"某个接口为什么慢"，压测要解决的是"整条链路在什么量会崩"。这篇给你真正生产可用的全链路压测体系。

单接口压测最大的陷阱是"假绿勾"：JMeter 把库存接口单机 QPS 压到 8000+，报告写满绿勾，结果大促 0 点刚过库存先崩、支付超时、订单雪崩——压测一个没压到。根子在三点：只压了单接口没跑完整链路、用测试数据而非生产真实分布、没有流量回放机制，测的是"假负载"。

一、为什么传统压测不顶用

新人做压测有个常见误区：JMeter 加并发到目标 QPS，看响应时间不超过 SLA 就完事了。但生产事故告诉你，这种压测至少漏掉了三层信息：

• 链路层：订单→库存→支付→风控一条链路，每一跳超时都会击穿上游。光压单点看不出"雪崩链"

• 数据层：生产 1 亿用户的真实分布 vs 测试 10 个用户的均分布，并发锁竞争、缓存命中率、SQL 执行计划全不一样

• 基线层：压完看绝对值没用，要看和昨天同时段/上周同时段基线对比，才知道是"代码退化"还是"真实压力"

所以真正的全链路压测，至少要解决五个问题：

┌─────────────────────────────────────────────────────────┐ │ 全链路压测完整度模型 │ ├─────────────────────────────────────────────────────────┤ │ 1. 流量来源： 生产流量录制回放 ✓ ← 决定负载真实性 │ │ 2. 数据隔离： 影子库/影子表 ✓ ← 决定污染风险 │ │ 3. 链路覆盖： 入口→下游全链路 ✓ ← 决定雪崩可见性 │ │ 4. 压测集群： 10万级QPS模拟 ✓ ← 决定容量上限 │ │ 5. 监控分析： 实时拐点+TP99 ✓ ← 决定瓶颈定位速度 │ └─────────────────────────────────────────────────────────┘

下文挨个讲解。

二、影子库：压测数据不污染生产的"平行宇宙"

全链路压测第一个要解决的事是：压测流量打出的数据不能污染生产。比如下了一笔订单，库存要扣、积分要加、支付要生成流水——这些数据跑进生产表就是脏数据，第二天对账要你命。

影子库（Shadow Table / Shadow DB）的思路：用同一套表结构，物理上隔离到独立数据源，压测流量走 shadow_ 开关的 shadow 数据源，但业务代码 0 改动。Spring 提供了AbstractRoutingDataSource让这事变得非常简单。

// ShadowRoutingDataSource.java — JDK 17 + Spring Boot 3.3 // 依赖：spring-boot-starter-jdbc // 思路：基于 ThreadLocal 的 routing key 决定走主库还是影子库 import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource; ​ public class ShadowRoutingDataSource extends AbstractRoutingDataSource { ​ // ThreadLocal 存储当前请求是否压测流量，true=走 shadow 数据源 private static final ThreadLocal<Boolean> isShadow = new ThreadLocal<>(); ​ public static void enterShadow() { isShadow.set(Boolean.TRUE); } public static void exitShadow() { isShadow.remove(); } public static boolean isShadow() { return Boolean.TRUE.equals(isShadow.get()); } ​ @Override protected Object determineCurrentLookupKey() { // 返回 lookupKey 即可，Spring 会根据 key 在 targetDataSources 里找对应 DataSource return isShadow() ? "shadow" : "main"; } }

数据源配置如下，主库和影子库同时注册进 Spring 容器，靠 ThreadLocal 决定走哪个：

链路接入点（Spring Cloud Gateway 过滤器或 Servlet Filter），识别到X-Shadow:

# application-stress.yml — 压测环境专用配置 spring: datasource: main: url: jdbc:mysql://prod-db:3306/order?useSSL=true username: order_app password: ${PROD_DB_PWD} hikari: pool-name: MainHikariCP maximum-pool-size: 50 ​ shadow: # 同构实例，物理隔离；压测完直接 TRUNCATE，无需清理 url: jdbc:mysql://stress-db:3306/order_shadow?useSSL=true username: stress_app password: ${STRESS_DB_PWD} hikari: pool-name: ShadowHikariCP maximum-pool-size: 100 # 压测需要更大连接池 ​ # 流量染色：用 Header 标记 "X-Shadow: true"，网关层识别后写入 ThreadLocal gateway: shadow: header: X-Shadow enabled: true

true就调用enterShadow()切换：

// ShadowTrafficFilter.java — JDK 17 + Spring Cloud Gateway 4.x // 关键：染色与切换必须在最早的位置完成，否则下方调用链已开始走主数据源 @Component public class ShadowTrafficFilter implements GlobalFilter, Ordered { ​ @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { boolean isShadow = "true".equalsIgnoreCase( exchange.getRequest().getHeaders().getFirst("X-Shadow")); if (isShadow) { ShadowRoutingDataSource.enterShadow(); } // Reactor 上下文：Reactive 场景下 ThreadLocal 会失效，需用 Context 传递 return chain.filter(exchange) .doFinally(signal -> ShadowRoutingDataSource.exitShadow()); } ​ @Override public int getOrder() { return -100; } // 越早越好 }

注意一个坑：用了 WebFlux/Reactor 之后，ThreadLocal 是失效的，因为请求处理可能跨多个线程。要么用Reactor Context传递染色标记，要么就在 controller 层用阻塞模式（MVC）。上例是兼容写法，演示流程；真实生产用Mono.deferContextual才是稳的。

为什么这套设计能成立？因为业务代码不变：业务 SQL 看的是同一个DataSourceBean（虽然里面是 RoutingDataSource），不知道下面切了；哪天不想压测了，把 header 拿掉就回主库。

三、流量录制：把生产真实流量搬到压测

压测最大的谎言是"我用的测试数据跟生产差不多"——其实生产数据分布永远不会跟测试样例一样。真正的解法是录下生产流量，去敏化后回放。

Java 生态里生产流量录制主流方案有两种：Nginx access log 解析回放与JVM 字节码录制（如 jvm-sandbox）。后者更准，能抓到内部 RPC，但成本高。我们用前者——网关层 access log 已经记录了 99% 的请求参数：

// TrafficRecorder.java — JDK 17 // 思路：异步批量写文件，避免影响生产 RT // 部署位置：网关层 Filter，每 30 秒刷盘一次 @Component public class TrafficRecorder { ​ private final BlockingQueue<String> buffer = new LinkedBlockingQueue<>(100_000); private final AtomicBoolean running = new AtomicBoolean(true); ​ // 配置：开启压测的 URL 前缀（防止误抓用户隐私接口） @Value("${stress.record.path-prefix:/api/}") private String pathPrefix; ​ @PostConstruct public void start() { Executors.newSingleThreadExecutor().submit(this::flushLoop); } ​ public void record(String method, String path, int status, long costMs, Map<String, String> headers, byte[] body) { // 关键：去敏化——身份证、手机号、密码一律打码 String sanitizedBody = sanitize(body); ​ // 用 JSON Lines 格式，每行一个请求 String line = String.format( "{\"ts\":%d,\"m\":\"%s\",\"p\":\"%s\",\"s\":%d,\"cost\":%d,\"h\":%s,\"b\":\"%s\"}", System.currentTimeMillis(), method, path, status, costMs, toJson(headers), Base64.getEncoder().encodeToString(sanitizedBody)); buffer.offer(line); } ​ private void flushLoop() { while (running.get()) { try (BufferedWriter w = Files.newBufferedWriter( Paths.get("/data/stress/traffic-" + System.currentTimeMillis()/1000 + ".jsonl"), StandardOpenOption.CREATE, StandardOpenOption.APPEND)) { // 每批最多 1000 条，或 1 秒刷一次 for (int i = 0; i < 1000; i++) { String line = buffer.poll(1, TimeUnit.SECONDS); if (line == null) break; w.write(line + "\n"); } } catch (Exception e) { log.error("flush traffic log failed", e); } } } ​ private byte[] sanitize(byte[] body) { // 正则替换身份证/手机号——务必接入合规团队的脱敏库 String s = new String(body, StandardCharsets.UTF_8); s = s.replaceAll("\\d{17}[\\dXx]", "***ID***") // 身份证 .replaceAll("1[3-9]\\d{9}", "***MOBILE***") // 手机号 .replaceAll("\"password\"\\s*:\\s*\"[^\"]*\"", "\"password\":\"***\""); // 密码 return s.getBytes(StandardCharsets.UTF_8); } }

录制文件天然就是压测脚本，不用写压测用例。复现 1 万 QPS 的真实负载，比写一个"等价"的 JMeter 脚本可信度高 10 倍。

四、压测集群：把 JMeter 从单机推到 10 万 QPS

单机 JMeter 极限约 2000 并发就到顶了——JMeter GUI 模式下连本机 socket 都会成为瓶颈。要做 10 万 QPS 量级，必须把 JMeter 拆成主从模式：

Slave 集群用 Docker Compose 一键拉起：

# docker-compose-stress.yml # 启动 50 个压测节点，每节点 2000 并发，总 10 万 QPS version: '3.8' services: jmeter-controller: image: apache/jmeter:5.6.2 command: -n -t /scripts/order.jmx -R jmeter-slave-1,jmeter-slave-2,... volumes: - ./scripts:/scripts - ./results:/results ​ jmeter-slave: image: apache/jmeter:5.6.2 command: -s -Jserver_port=1099 -Jserver.rmi.ssl.disable=true deploy: replicas: 50 environment: - JVM_ARGS=-Xms2g -Xmx2g -XX:+UseG1GC # 关键：不限制 CPU，让一个 Slave 把 CPU 打满看吞吐上限

核心 trick：JMeter 用jp@gc - Throughput Shaping Timer控制 QPS 增速曲线——比如按"5 分钟从 0 线性爬到 50000"，便于找到系统的拐点。

最常犯的错：直接 2000 并发起跑。结果要么压挂了没留时间分析，要么压不出真实承载上限。要"先慢后快"，让系统有时间预热。

五、压测监控：3 个核心指标 + 实时告警

压测过程你必须在 Grafana 上盯三样东西：吞吐量、响应时间分布、错误率。这三者任何一个先崩，那个点就是系统瓶颈。我把这三板斧提炼成一套 PromQL 告警：

# alert.rules.yml — 压测专用告警规则 groups: - name: stress_test_alerts rules: - alert: P99_ResponseTime_TooHigh # 关键：TP99 大于 SLA 阈值 expr: | histogram_quantile(0.99, sum by (le, service) (rate(http_server_requests_seconds_bucket{service=~".*"}[1m])) ) > 0.5 for: 2m labels: { severity: critical, stage: stress } annotations: summary: "{{ $labels.service }} TP99 已超过 500ms" ​ - alert: ErrorRate_Spike # 错误率大于 1% 持续 1 分钟 expr: | sum by (service) (rate(http_server_requests_seconds_count{status=~"5.."}[1m])) / sum by (service) (rate(http_server_requests_seconds_count[1m])) > 0.01 for: 1m labels: { severity: critical, stage: stress } ​ - alert: Throughput_Plateau # 关键：吞吐量不再增长但并发还在加 = 拐点已到！ expr: | sum(rate(http_server_requests_seconds_count[30s])) < sum(rate(http_server_requests_seconds_count[5m])) * 0.95 and on() sum(http_server_requests_active) > 1000 for: 3m annotations: summary: "吞吐量已到拐点"

Throughput_Plateau这条最值钱——当 QPS 不再随并发上升、错误率却开始抬头，那就是系统的真实容量上限，比"测试报告里写满了"的字强得多。

六、结果分析：找拐点，比绝对值更重要

测试报告里最该写的不是"SLA 满足"或"SLA 不满足"，而是"系统在什么并发下出现拐点"。下面是常见的三种拐点形态，每种对应不同的根因：

判断方法：把并发数和 QPS 双轴画图，曲线斜率突变的点就是拐点。比如：

• 拐点在 8000 QPS：可能 DB 连接池满，扩容数据库或上连接池分库分表

• 拐点在 5000 QPS：可能 Redis 大 Key 拉跨，看 Redisslowlog get找 TOP3 大 Key

• 拐点在 3000 QPS：可能锁竞争严重，jstackdump 看 BLOCKED 线程数

下面这段代码自动解析 JMeter JTL 文件，输出真实的拐点和 P99 报告：

// StressReportAnalyzer.java — JDK 17 // 解析 JMeter 的 JTL 输出，输出系统真实容量画像 public class StressReportAnalyzer { ​ // JTL 文件示例：timeStamp,elapsed,label,responseCode,success,bytes,threadName public CapacityProfile analyze(Path jtlFile) throws IOException { List<Long> latencies = new ArrayList<>(); Map<Integer, AtomicLong> qpsBySecond = new TreeMap<>(); Map<Integer, AtomicLong> errorsBySecond = new TreeMap<>(); ​ Files.lines(jtlFile).skip(1).forEach(line -> { // skip CSV header String[] f = line.split(","); if (f.length < 6) return; long elapsed = Long.parseLong(f[1]); long ts = Long.parseLong(f[0]); boolean success = "true".equalsIgnoreCase(f[4]); int secondBucket = (int) (ts / 1000); ​ latencies.add(elapsed); qpsBySecond.computeIfAbsent(secondBucket, k -> new AtomicLong()).incrementAndGet(); if (!success) errorsBySecond .computeIfAbsent(secondBucket, k -> new AtomicLong()).incrementAndGet(); }); ​ Collections.sort(latencies); long p50 = latencies.get((int)(latencies.size() * 0.50)); long p99 = latencies.get((int)(latencies.size() * 0.99)); long p999 = latencies.get((int)(latencies.size() * 0.999)); ​ // 拐点检测：找连续 3 秒 QPS 下降超过 10% 但并发还在涨 int knee = detectKneePoint(qpsBySecond); ​ return new CapacityProfile(p50, p99, p999, knee, qpsBySecond.values().stream().mapToLong(AtomicLong::get).sum(), (double) errorsBySecond.values().stream().mapToLong(AtomicLong::get).sum() / Math.max(1, qpsBySecond.values().stream().mapToLong(AtomicLong::get).sum())); } ​ private int detectKneePoint(Map<Integer, AtomicLong> qps) { List<Map.Entry<Integer, AtomicLong>> sorted = new ArrayList<>(qps.entrySet()); sorted.sort(Map.Entry.comparingByKey()); ​ // 找到 QPS 首次下降超过 10% 的位置即视为拐点 long peak = sorted.get(0).getValue().get(); for (int i = 1; i < sorted.size(); i++) { long cur = sorted.get(i).getValue().get(); if (cur < peak * 0.9) { return sorted.get(i).getKey(); } peak = Math.max(peak, cur); } return -1; // 没找到拐点 = 系统完全健康，大胆加压 } ​ public record CapacityProfile( long p50, long p99, long p999, int kneeSecondBucket, // 拐点出现的时间桶 long totalRequests, double errorRate ) { @Override public String toString() { return String.format(""" ===== 压测报告 ===== P50: %d ms | P99: %d ms | P99.9: %d ms 总请求数: %d | 错误率: %.2f%% %s 系统拐点: %s """, p50, p99, p999, totalRequests, errorRate * 100, errorRate > 0.01 ? "❌" : "✅", kneeSecondBucket > 0 ? "在第 " + kneeSecondBucket + " 秒出现拐点，需排查" : "未出现拐点，系统健康"); } } }

跑一遍直接输出形如：

===== 压测报告 ===== P50: 38 ms | P99: 412 ms | P99.9: 1890 ms 总请求数: 12487650 | 错误率: 0.32% ✅ 系统拐点: 在第 387 秒出现拐点，需排查

我们之前双十一那次压测报告从来没填过"拐点"——只写了"系统通过 SLA"，结果真出问题只能现场手忙脚乱。

七、给团队的三条实战建议

1. 压测起步从"链路幂等性检查"开始，别从高并发开始。第一次压测只跑 200 QPS，验证链路每一步是否幂等、是否有脏数据。压测生产环境一旦出现非幂等写入，重则资金损失。比如我们的红包服务第一次压测就丢了一堆红包——后端用了INSERT ... ON DUPLICATE KEY UPDATE，并发下却调用了两遍，无可挽回。所以建议：先低并发慢压，观察数据库增量，确认业务幂等再上量。

2. 一定要做"减压测试"，不只做加压测试。95% 的团队只测"加压时会不会挂"，但生产事故 30% 发生在流量回退阶段——双十一结束后流量从 50 万 QPS 急速回落到 5 万 QPS，缓存预热、连接池收缩、JVM 触发 GC……一系列连锁反应可能造成服务震荡。建议每轮压测最后加个"5 分钟降到 0"阶段。

3. 建立"双链路对比基线"而非"绝对值基线"。系统每周都会因为依赖升级、配置变更、SQL 微调导致性能漂移。每月固定时间做一次标准压测（5000 QPS，维持 5 分钟），把 P99、错误率、CPU/内存画像入库；上线发版后跑同样测试对比，差异 >5% 必须复盘。这套基线比加压到极限还重要。

压测这件事，最容易踩的坑就是把它当"测试"做——JUnit 写个 case、JMeter 跑一下、出报告完事。

但压测本质是"生产事故的预演"——你要用压测回答的核心问题只有一个："线上出问题前，我能不能提前 1 个月发现？"

一个系统能扛多大流量不取决于压测峰值，而取决于你对拐点了解多深。

下篇预告（Day86）：AI 时代架构师的新命题：从 CRUD 到 AI 工程的思维跃迁——同样是做技术选型，AI 时代多出了"大模型依赖"这一维度。我会拆解 AI 原生架构与 AI 增强架构的本质差异，给你一份"加 AI 时应该怎么想"的新清单。