企业官网建设流程全解析

1. 项目概述：为什么非得用Java给JMeter做二次开发？

“针对Jmeter用java做二次开发支持多人并发运行”——这个标题乍看像一句技术需求描述，实则藏着三个关键痛点：原生JMeter在真实压测场景中跑不起来、跑不稳、跑不准。我带过不下二十个压测项目，从电商大促到金融交易链路，凡是涉及“多人并发运行”的真实业务场景，几乎都卡在同一个地方：JMeter GUI模式根本没法当生产级调度器用，命令行模式（jmeter -n）又太“裸”，缺乏统一任务分发、状态追踪、资源隔离和结果聚合能力。这时候，单纯调脚本、改线程数、堆内存，已经不是优化，而是硬扛。

核心关键词“JMeter”“Java二次开发”“多人并发运行”，指向的不是工具使用，而是构建一套可编排、可监控、可伸缩的压测执行中枢。它要解决的不是“能不能发请求”，而是“怎么让50个测试工程师同时提交不同场景的压测任务，系统自动分配到20台压测机上，每台机器只跑自己该跑的那部分，不抢资源、不串数据、不丢日志，最后把所有结果按业务维度自动归并成一份报告”。

这本质上是一次从“单机压测工具”到“分布式压测平台”的跃迁。Java之所以是唯一合理选择，不是因为语言多酷，而是因为JMeter本身就是Java写的，它的核心引擎（StandardJMeterEngine）、采样器（HTTPSamplerProxy）、监听器（BackendListener）、线程组（ThreadGroup）全部暴露为标准Java类，且有完整、稳定、无破坏性变更的API契约。你不需要逆向、不依赖反射、不碰字节码——直接继承、组合、重写，就能把JMeter变成你想要的样子。我试过用Python调JMeter CLI，也试过用Node.js封装REST API，最终全推倒重来，就是因为绕不开Java层的深度控制权：比如你要精确控制每个线程组的启动延迟、动态注入用户变量、在请求发出前实时修改Header里的Token，这些操作在Java里就是几行setXXX()调用；在外部进程调用里，要么做不到，要么得写一堆胶水代码，稳定性直接打五折。

适合谁来看这篇？如果你是测试开发工程师，正被“每次压测都要手动改jmx、复制脚本、登录每台机器敲命令、Excel合并结果”折磨；如果你是SRE或运维同学，被测试团队反复要求“再加两台压测机”“这个任务优先级调高点”“结果能不能按接口分组看RT95”；或者你是架构师，想把压测能力做成公司级服务，嵌入CI/CD流水线——那你不是在学一个工具技巧，而是在搭建一条质量保障的主动脉。接下来的内容，全是我在多个项目里踩坑、验证、沉淀下来的实操路径，不讲虚的，只说怎么落地。

2. 整体设计思路：不做“大而全”的平台，先造“能跑通”的骨架

很多人一上来就想做个带Web界面、任务队列、资源池管理、实时监控大屏的“压测平台”，结果三个月连第一个并发任务都没跑通。我的经验是：先放弃“平台”这个词，专注解决“多人并发运行”最底层的三个刚性问题——任务分发、执行隔离、结果回收。其他功能都是锦上添花，而这三块是地基，地基不牢，楼盖再高也是危房。

2.1 架构选型：为什么是“主控节点+Agent节点”而非“纯集群模式”

JMeter原生支持分布式压测（Remote Testing），但那是为“一台控制机+多台被控机”设计的，所有被控机必须预先配置好IP、端口、RMI证书，且所有jmx脚本必须完全一致、放在相同路径。这在实验室环境OK，但在实际工程中，问题立刻暴露：

• 测试人员A提交订单创建场景（order.jmx），B提交支付回调场景（payback.jmx），C还要跑混合场景（mix.jmx）——你怎么让三台被控机同时加载三个不同脚本？
• 某台被控机磁盘满了，JMeter报错退出，但主控机不知道，还在等它回传结果，整个任务卡死。
• 不同脚本需要不同JVM参数（比如有的要-Xms4g，有的2g就够了），远程模式下所有被控机只能共用同一套启动参数。

所以，我们彻底放弃JMeter原生Remote模式，采用“主控节点（Master）+轻量Agent节点（Worker）”架构：

• Master：纯Java进程，负责接收HTTP/REST请求（如POST /api/tasks），解析任务参数（jmx路径、线程数、循环次数、超时时间），生成唯一任务ID，将任务元数据（含jmx内容base64编码）推送到消息队列（我们选RabbitMQ，因它支持消息TTL、死信队列、优先级，比Kafka更适配短时任务），然后返回202 Accepted。
• Worker：每个Agent是一个独立JVM进程，启动时连接RabbitMQ，监听指定队列（如worker.queue）。收到任务后，它会：
  1. 解码jmx base64，写入本地临时目录（如/tmp/jmeter-tasks/{task-id}/test.jmx）；
  2. 根据任务参数动态构造JMeter命令行（jmeter -n -t /tmp/.../test.jmx -l /tmp/.../result.jtl -e -o /tmp/.../report）；
  3. 用ProcessBuilder启动子进程，并捕获stdout/stderr流，实时上报状态（RUNNING/FAILED）；
  4. 任务结束后，将result.jtl压缩为zip，上传到对象存储（MinIO），再把下载URL和基础指标（总请求数、错误率、平均RT）发回Master。

提示：Worker不复用JMeter进程，每次任务都启新进程。这是刻意为之——避免JMeter内部状态残留（如缓存的Cookie、重用的HTTP连接池）污染下一个任务。看似“重”，实则换来绝对隔离和可预测性。我们实测过，单个Worker每分钟可稳定执行3~5个中等复杂度任务（1000线程，持续2分钟），远超业务需求。

2.2 Java二次开发的核心切入点：不碰GUI，只动引擎与监听器

JMeter源码里，真正干活的是StandardJMeterEngine类，它负责加载jmx、初始化线程组、调度采样器、收集结果。我们的二次开发，90%工作量都在围绕它展开：

• 任务驱动引擎封装：写一个TaskJMeterEngine类，继承StandardJMeterEngine，重写runTest()方法。关键改造点有三处：

  1. 在runTest()开头，注入动态参数：通过JMeterUtils.setProperty("task.id", taskId)把任务ID透传到所有采样器，方便后续日志打标；
  2. 替换默认监听器：移除所有GUI监听器（ViewResultsFullVisualizer等），只保留BackendListener，并配置其发送指标到本地InfluxDB（用于实时监控）；
  3. 拦截结果写入：重写ResultCollector的addSampleResult()方法，在写入.jtl前，过滤掉非关键字段（如responseMessage、responseHeaders），把文件体积压到1/5，加速上传。

• 自定义采样器增强：很多业务需要在请求头里动态塞Token，而Token可能来自上游认证服务。我们写了一个DynamicHeaderSampler，它不发请求，只做一件事：调用HttpClient去取Token，然后把结果存到JMeter的JMeterContextService.getContext().getVariables().put("auth_token", token)。这样下游的HTTPSamplerProxy就能用${auth_token}引用。这个Sampler本身是Java写的，完全可控，失败时能抛出明确异常，Worker进程能捕获并标记任务失败。

• 结果聚合器：单独写一个JtlAggregator工具类，不依赖JMeter GUI。它读取多个.jtl文件（来自不同Worker），按label（即请求名称）和responseCode分组，计算TPS、RT、错误率等指标，输出JSON格式聚合结果。这个类被Master调用，当所有Worker上报完成，就触发聚合，生成最终报告。

注意：所有二次开发代码，必须打包成独立jar（如jmeter-ext-core-1.0.jar），放入JMeter的/lib/ext/目录。不要试图修改JMeter源码再编译——版本升级时你会崩溃。我们约定：所有扩展逻辑，只通过-cp参数或lib/ext加载，确保与JMeter主程序零耦合。

3. 核心细节解析：从代码到部署，每一步都踩过坑

3.1 Master节点：用Spring Boot搭骨架，但别让它变“全家桶”

Master本质是个任务调度API服务，Spring Boot确实快，但千万别一上来就加spring-boot-starter-webflux、spring-boot-starter-data-jpa、spring-boot-starter-security……压测平台最怕什么？线程阻塞、GC停顿、网络超时。我们最终选了极简组合：

• spring-boot-starter-web（MVC，够用）
• spring-boot-starter-amqp（对接RabbitMQ）
• spring-boot-starter-validation（校验任务参数，如线程数不能超10000）
• lombok（减少样板代码）

关键配置在application.yml：

spring: rabbitmq: host: rabbitmq-server port: 5672 username: admin password: secret virtual-host: /jmeter # 关键：设置消费者预取值，防Worker积压 listener: simple: prefetch: 1 # 每次只取1条，处理完再取下一条 acknowledge-mode: manual # 手动ACK，确保任务真正完成才确认

任务提交接口POST /api/v1/tasks的Controller长这样：

@PostMapping public ResponseEntity<TaskResponse> createTask(@Valid @RequestBody TaskRequest request) { // 1. 校验jmx内容是否合法（简单检查是否包含<hashTree>标签） if (!request.getJmxContent().contains("<hashTree>")) { throw new IllegalArgumentException("Invalid jmx content"); } // 2. 生成唯一任务ID（用Snowflake算法，保证全局有序） long taskId = snowflakeIdWorker.nextId(); // 3. 封装任务消息（含base64编码的jmx） TaskMessage message = TaskMessage.builder() .taskId(taskId) .jmxBase64(Base64.getEncoder().encodeToString(request.getJmxContent().getBytes())) .threadCount(request.getThreadCount()) .durationSecs(request.getDurationSecs()) .build(); // 4. 发送到RabbitMQ，设置TTL=30分钟（超时自动丢弃） rabbitTemplate.convertAndSend("task.exchange", "task.routing.key", message, msg -> { msg.getMessageProperties().setExpiration("1800000"); // 30min return msg; }); return ResponseEntity.accepted().body(new TaskResponse(taskId, "submitted")); }

实操心得：prefetch: 1是血泪教训。早期我们设成10，结果某Worker卡死（如磁盘满），RabbitMQ把10个任务全推给它，其他Worker闲着，整个队列堵死。改成1后，任务均匀分发，Worker故障只影响单个任务。

3.2 Worker节点：一个JAR包，启动即用，无需JMeter安装

Worker最理想的状态是：扔一个jar包到服务器，java -jar worker.jar --server.port=8081，它就自动注册、拉任务、跑压测、传结果。我们用spring-boot-maven-plugin把所有依赖（包括jmeter-core、httpclient、minio-sdk）打包进fat jar，但关键点在于：Worker不自带JMeter二进制，而是依赖系统PATH里的jmeter命令。

为什么？因为JMeter版本升级频繁（5.4→5.5→5.6），如果把jmeter-core打进Worker jar，一旦JMeter发布新版本修复了某个HTTP/2 bug，你就得重编译Worker。而用系统PATH方式，只需在每台Worker服务器上apt install jmeter或解压官方包，Worker自动用最新版。我们在Worker启动时加了一段健康检查：

@Component public class JMeterHealthCheck implements ApplicationRunner { @Override public void run(ApplicationArguments args) throws Exception { // 执行 'jmeter -v'，检查是否可用且版本>=5.4 Process process = Runtime.getRuntime().exec("jmeter -v"); int exitCode = process.waitFor(); if (exitCode != 0) { throw new RuntimeException("JMeter not found or version too low"); } // 读取stdout，解析版本号 String version = IOUtils.toString(process.getInputStream(), StandardCharsets.UTF_8); if (!version.contains("5.4") && !version.contains("5.5") && !version.contains("5.6")) { log.warn("JMeter version may be incompatible: {}", version); } } }

Worker接收到任务后的执行流程，用伪代码表示更清晰：

1. 创建临时目录 /tmp/jmeter-task-{taskId} 2. 将 jmxBase64 解码，写入 /tmp/.../test.jmx 3. 构造命令行： jmeter -n \ -t /tmp/.../test.jmx \ -l /tmp/.../result.jtl \ -j /tmp/.../jmeter.log \ # 单独日志，方便排查 -Dtask.id={taskId} \ # 透传任务ID -Djmeter.save.saveservice.output_format=csv \ # 强制CSV，兼容性最好 -Djmeter.save.saveservice.response_data=false \ # 不存响应体 -Djmeter.save.saveservice.samplerData=false \ -Djmeter.save.saveservice.assertionResults=false 4. 用 ProcessBuilder 启动，重定向 stdout/stderr 到内存流 5. 监听进程退出码： - 0：成功，压缩 result.jtl → result.zip，上传MinIO，发完成消息 - 非0：读取 jmeter.log 最后100行，提取关键错误（如"Connection refused"、"OutOfMemoryError"），发失败消息

注意：-Djmeter.save.saveservice.*这些参数是性能命脉。默认JMeter保存的.jtl包含所有响应头、断言结果、采样器数据，一个10万请求的.jtl轻松破500MB。关掉它们，.jtl能压到20MB以内，上传时间从3分钟降到15秒。

3.3 结果聚合与报告：不用JMeter GUI，自己写解析器

JMeter的-e -o命令行能生成HTML报告，但它有两个硬伤：一是必须等所有请求结束才能生成，无法实时看；二是报告结构固定，没法按“支付成功率”“下单RT95”这种业务指标定制。所以我们彻底抛弃HTML报告，自己写.jtl解析器。

核心类JtlParser用OpenCSV库逐行读取CSV格式的.jtl（JMeter默认CSV格式）：

public class JtlParser { public AggregatedResult parse(InputStream jtlStream) { CsvToBean<JtlRow> csvToBean = new CsvToBeanBuilder<JtlRow>(jtlStream) .withType(JtlRow.class) .withIgnoreLeadingWhiteSpace(true) .build(); List<JtlRow> rows = csvToBean.parse(); // 按 label 分组（如 "HTTP Request Login", "HTTP Request Pay"） Map<String, List<JtlRow>> byLabel = rows.stream() .filter(row -> "true".equals(row.isSuccessful())) // 只统计成功请求 .collect(Collectors.groupingBy(JtlRow::getLabel)); AggregatedResult result = new AggregatedResult(); for (Map.Entry<String, List<JtlRow>> entry : byLabel.entrySet()) { String label = entry.getKey(); List<JtlRow> samples = entry.getValue(); // 计算关键指标 double avgRt = samples.stream().mapToLong(JtlRow::getElapsed).average().orElse(0.0); double p95 = calculatePercentile(samples.stream().mapToLong(JtlRow::getElapsed).toArray(), 95); long tps = (long) (samples.size() * 1000.0 / samples.get(0).getEndTime()); // 简化计算 result.addLabelMetric(label, new LabelMetric(avgRt, p95, tps, samples.size())); } return result; } }

JtlRow类对应CSV的列，我们只映射必需字段：

@CsvBindByName(column = "timeStamp") private long timeStamp; @CsvBindByName(column = "elapsed") private long elapsed; // 响应时间，毫秒 @CsvBindByName(column = "label") private String label; // 请求名称 @CsvBindByName(column = "success") private String successful; // "true"/"false"

最终聚合结果是JSON，Master收到所有Worker的JSON后，再做一次跨Worker聚合，生成最终报告：

{ "task_id": 123456, "start_time": "2024-06-15T10:00:00Z", "end_time": "2024-06-15T10:02:00Z", "labels": [ { "name": "Create Order", "avg_rt_ms": 128.4, "p95_rt_ms": 215.0, "tps": 42.3, "total_requests": 5076 } ] }

提示：calculatePercentile方法我们没用Apache Commons Math，而是手写快速选择算法（QuickSelect），因为.jtl文件可能有百万行，排序太慢。实测100万行数据，QuickSelect求P95只要300ms，而Arrays.sort()要2.3秒。

4. 实操过程：从零部署一套可用的系统

4.1 环境准备：四台机器，半小时搞定

我们用最朴素的方案：4台Ubuntu 22.04虚拟机（2核4G），不搞Docker、K8s，先跑通逻辑。分工如下：

• master-server：部署Master服务（Spring Boot应用）
• rabbitmq-server：部署RabbitMQ（用官方Docker镜像，docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=secret rabbitmq:3-management）
• worker-01,worker-02：部署Worker服务（各一台）

步骤1：在worker-01/02上安装JMeter

# 下载JMeter 5.6.3（官方推荐LTS版） wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-5.6.3.tgz tar -xzf apache-jmeter-5.6.3.tgz sudo ln -sf /opt/apache-jmeter-5.6.3/bin/jmeter /usr/local/bin/jmeter # 验证 jmeter -v # 应输出 "Apache JMeter version 5.6.3"

步骤2：构建并部署Worker

# 在本地IDE编译 worker.jar（含所有依赖） mvn clean package -DskipTests # 复制到worker服务器 scp target/worker-1.0.jar worker-01:/opt/jmeter-worker/ # 启动（后台运行，日志落盘） nohup java -jar /opt/jmeter-worker/worker-1.0.jar \ --spring.rabbitmq.host=rabbitmq-server \ --logging.file.name=/var/log/jmeter-worker.log \ > /dev/null 2>&1 &

步骤3：构建并部署Master

# 编译 master.jar mvn clean package -DskipTests scp target/master-1.0.jar master-server:/opt/jmeter-master/ # 启动 nohup java -jar /opt/jmeter-master/master-1.0.jar \ --spring.rabbitmq.host=rabbitmq-server \ --spring.rabbitmq.virtual-host=/jmeter \ --server.port=8080 \ > /dev/null 2>&1 &

步骤4：创建RabbitMQ虚拟主机和用户登录RabbitMQ管理界面（http://rabbitmq-server:15672），用admin/secret登录，执行：

• 新建Virtual Host：/jmeter
• 在/jmeter下新建用户：jmeter-user/jmeter-pass
• 赋予/jmeter的Configure/Write/Read权限

注意：Worker和Master的application.yml里，spring.rabbitmq.username必须用jmeter-user，不能用admin。这是安全基线，也是为后续多租户打基础。

4.2 第一次任务：用最简jmx验证全流程

写一个极简jmx（hello.jmx），只发一个HTTP请求：

<?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.6.3"> <hashTree> <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Hello Test" enabled="true"> <stringProp name="TestPlan.comments"></stringProp> <boolProp name="TestPlan.functional_mode">false</boolProp> <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp> <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"/> <stringProp name="TestPlan.serialize_threadgroups">false</stringProp> </TestPlan> <hashTree> <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true"> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true"> <boolProp name="LoopController.continue_forever">false</boolProp> <stringProp name="LoopController.loops">10</stringProp> </elementProp> <stringProp name="ThreadGroup.num_threads">50</stringProp> <stringProp name="ThreadGroup.ramp_time">1</stringProp> <boolProp name="ThreadGroup.scheduler">false</boolProp> <stringProp name="ThreadGroup.duration"></stringProp> <stringProp name="ThreadGroup.delay"></stringProp> </ThreadGroup> <hashTree> <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="HTTP Request" enabled="true"> <stringProp name="HTTPSampler.domain">httpbin.org</stringProp> <stringProp name="HTTPSampler.port">80</stringProp> <stringProp name="HTTPSampler.protocol">http</stringProp> <stringProp name="HTTPSampler.path">/get</stringProp> <stringProp name="HTTPSampler.method">GET</stringProp> <stringProp name="HTTPSampler.contentEncoding"></stringProp> <stringProp name="HTTPSampler.connect_timeout"></stringProp> <stringProp name="HTTPSampler.response_timeout"></stringProp> </HTTPSamplerProxy> <hashTree/> </hashTree> </hashTree> </hashTree> </jmeterTestPlan>

用curl提交任务：

curl -X POST http://master-server:8080/api/v1/tasks \ -H "Content-Type: application/json" \ -d '{ "jmxContent": "'"$(cat hello.jmx | base64 -w 0)"'", "threadCount": 50, "durationSecs": 120 }' # 返回 {"taskId":123456,"status":"submitted"}

此时，打开RabbitMQ管理界面，能看到task.queue里有一条消息；Worker日志里会打印[INFO] Received task 123456, starting jmeter...；2分钟后，Master日志会输出聚合结果JSON。全流程走通，意味着骨架已立。

4.3 生产级加固：三处必改配置

跑通不等于能用。上线前，必须做三处加固：

1. Worker JVM参数调优默认java -jar worker.jar用的是系统默认堆内存（通常256MB），但JMeter子进程要吃内存。我们在Worker启动脚本里强制指定：

nohup java -Xms2g -Xmx2g -XX:+UseG1GC \ -jar /opt/jmeter-worker/worker-1.0.jar \ --spring.rabbitmq.host=rabbitmq-server \ > /dev/null 2>&1 &

-Xms2g -Xmx2g确保堆内存不抖动，-XX:+UseG1GC避免Full GC卡顿。实测，2G堆能让Worker稳定支撑5个并发任务（每个任务1000线程）。

2. RabbitMQ消息可靠性默认RabbitMQ消息是内存存储，服务器重启就丢。我们在application.yml里加持久化：

spring: rabbitmq: # ... 其他配置 publisher-confirms: true # 开启发布确认 publisher-returns: true # 开启未路由消息返回

并在Master发消息时，设置mandatory=true，确保消息路由失败时能捕获异常。

3. MinIO上传限速与重试Worker上传result.zip到MinIO，如果网络抖动，直接失败会导致任务状态卡住。我们在MinIO客户端配置：

MinioClient minioClient = MinioClient.builder() .endpoint("http://minio-server:9000") .credentials("minioadmin", "minioadmin") .build(); // 设置上传超时10分钟，失败自动重试3次 PutObjectArgs args = PutObjectArgs.builder() .bucket("jmeter-results") .object("task-" + taskId + "/result.zip") .stream(inputStream, -1, 10485760) // 10MB part size .build(); minioClient.putObject(args);

实操心得：10485760（10MB）是MinIO推荐的part size，太小（如1MB）会导致HTTP请求过多，超时概率升；太大（如100MB）则单次失败重传代价高。我们压测过，10MB在千兆内网下最稳。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：高频故障与定位路径

5.2 独家避坑技巧：来自真实战场的经验

技巧1：用jmeter -n -t test.jmx -j debug.log先本地调试jmx别急着扔到Worker上。在Master服务器本地执行：

jmeter -n -t hello.jmx -j /tmp/debug.log -l /tmp/test.jtl

然后tail -f /tmp/debug.log，看有没有ERROR或WARN。常见问题如：HTTP Sampler里domain填了http://httpbin.org（多了http://），JMeter会解析失败，但错误日志藏得很深。debug.log里会有java.net.UnknownHostException: http://httpbin.org，一眼定位。

技巧2：Worker日志分级，关键信息打标Worker日志里混着JMeter子进程的日志、RabbitMQ心跳、HTTP上传日志，很难grep。我们在Worker里做了日志打标：

// 启动JMeter子进程时 ProcessBuilder pb = new ProcessBuilder("jmeter", "-n", "-t", jmxPath, "-l", jtlPath); pb.redirectErrorStream(true); // 合并stderr到stdout Process process = pb.start(); // 用BufferedReader读取子进程输出，每行前加"[JMX]" new BufferedReader(new InputStreamReader(process.getInputStream())).lines() .forEach(line -> log.info("[JMX] {}", line));

这样grep "\[JMX\]" /var/log/jmeter-worker.log就能精准看到JMeter的输出。

技巧3：给jmx加“签名”，防篡改业务方提交的jmx可能被恶意修改（如加个无限循环脚本）。我们在Master里加了简单签名：

// 提交时 String jmxContent = request.getJmxContent(); String signature = DigestUtils.md5Hex(jmxContent + "SECRET_KEY_2024"); // SECRET_KEY存在配置中心 // 存库或发消息时，带上signature message.setJmxSignature(signature);

Worker收到后，重新计算签名比对。不一致则直接拒绝，日志记[SECURITY] JMX signature mismatch, task rejected。

技巧4：Worker“假死”检测Worker进程活着，但RabbitMQ消费卡住（如网络闪断后没重连）。我们在Worker里加了心跳线程：

@Scheduled(fixedDelay = 30000) // 每30秒 public void checkRabbitMQConnection() { try { if (!rabbitTemplate.getConnectionFactory().createConnection().isOpen()) { log.error("RabbitMQ connection lost, restarting..."); System.exit(1); // 主动退出，supervisor会拉起新进程 } } catch (Exception e) { log.error("Failed to check RabbitMQ", e); System.exit(1); } }

配合systemd或supervisord管理Worker进程，实现自动恢复。

最后分享一个小技巧：我们给每个Worker加了个/actuator/health端点，返回当前负载（正在跑的任务数、CPU使用率、/tmp磁盘剩余）。测试同学访问http://worker-01:8081/actuator/health，就能直观看到哪台机器还空闲，手动把高负载任务导过去。这比等自动调度更直接，也更可控。

我在实际使用中发现，这套方案最大的价值不是“省了多少人力”，而是把压测从“人肉操作”变成了“可编程事件”。现在，测试同学写完jmx，curl一个API就启动；研发同学在GitLab CI里加一行curl -X POST $MASTER_URL/api/tasks ...，代码合并就自动压测；SRE在Prometheus里配个告警规则，当Worker CPU > 90%持续5分钟，就自动扩容。它不再是一个工具，而是一条嵌入研发流程的血管。至于后续要不要加Web UI、要不要对接K8s、要不要做AI异常检测——那些都是血管上长出的新器官，而骨架，我们已经搭好了。