微服务压测：JMeter+Gatling对比，瓶颈定位与容量规划
2026/4/30大约 9 分钟
微服务压测：JMeter+Gatling对比，瓶颈定位与容量规划
适读人群：有微服务实战经验的后端工程师 | 阅读时长：约26分钟 | Spring Boot 3.2 / JMeter 5.6 / Gatling 3.10
开篇故事
大促前的压测是每个做电商的技术团队都要经历的必修课。我第一次独立负责压测是大概三年前，当时心里没底，就按照"拍脑袋"的方式配了机器，心想用量乘以5倍应该够了吧。
结果活动当天，流量刚到预期的60%，订单服务就开始报超时，P99从100ms飙到3000ms。运营催着手动扩容，但是扩容需要时间，这段时间里已经流失了一波用户。
事后复盘，发现压测做得太粗糙：只测了整体QPS，没有测链路瓶颈；只测了稳态性能，没有做梯度压测；压测报告只有TPS和平均响应时间，没有P99、P95这些更重要的数据。
那次之后我系统学习了压测方法论，在Gatling和JMeter都用熟了，每次大促前都会按标准化流程做压测，找到瓶颈后优化，直到压测通过才上活动。今天把这套压测方法论和工具使用写出来。
一、核心问题分析
微服务压测和单体应用压测有明显区别：
链路压测 vs 单接口压测：微服务的业务流程跨越多个服务，单接口压测只能发现本服务的瓶颈，发现不了调用链路上下游的瓶颈。链路压测才能发现真实的系统瓶颈。
JMeter vs Gatling 的选型：JMeter是GUI驱动的，上手快，但脚本维护麻烦；Gatling是代码驱动的（Scala DSL），可以版本化管理，报告更详细，对高并发场景性能更好（Gatling本身是NIO异步的，不像JMeter是线程模型）。我的建议是：初步探测用JMeter快速验证，正式压测用Gatling生成标准化报告。
容量规划的方法：通过梯度压测找到系统的吞吐量拐点（即CPU/内存/连接池某个资源达到瓶颈的点），这个拐点就是单实例的容量上限，除以安全系数（通常0.7），就是单实例的规划容量，再根据业务峰值QPS计算所需实例数。
二、原理深度解析
2.1 压测方法论：梯度加压
2.2 瓶颈定位决策树
2.3 JMeter vs Gatling 对比
三、完整代码实现
3.1 Gatling压测脚本（下单链路）
package simulations
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
/**
* 电商下单链路压测脚本
* 链路：登录 -> 查询库存 -> 创建订单 -> 支付
*/
class OrderSimulation extends Simulation {
// HTTP配置
val httpProtocol = http
.baseUrl("http://api-gateway:8080")
.acceptHeader("application/json")
.contentTypeHeader("application/json")
.header("X-Source", "gatling-load-test")
// 测试数据：从CSV文件加载用户账号
val userFeeder = csv("users.csv").random
// 场景定义：完整下单链路
val orderScenario = scenario("下单链路压测")
.feed(userFeeder) // 从CSV加载用户数据
// 步骤1：登录获取Token
.exec(
http("登录")
.post("/auth/login")
.body(StringBody("""{"username":"${username}","password":"${password}"}"""))
.check(
status.is(200),
jsonPath("$.data.accessToken").saveAs("accessToken")
)
)
.pause(1.seconds) // 模拟用户思考时间
// 步骤2：查询商品库存
.exec(
http("查询库存")
.get("/api/v2/inventory/product/SKU001")
.header("Authorization", "Bearer ${accessToken}")
.check(
status.is(200),
jsonPath("$.data.stock").saveAs("stock")
)
)
.pause(500.milliseconds, 2.seconds) // 随机思考时间
// 步骤3：创建订单
.exec(
http("创建订单")
.post("/api/v2/order")
.header("Authorization", "Bearer ${accessToken}")
.body(StringBody(
"""{
| "productId": "SKU001",
| "quantity": 1,
| "addressId": "${addressId}"
|}""".stripMargin
))
.check(
status.is(200),
jsonPath("$.data.orderId").saveAs("orderId")
)
)
.pause(2.seconds)
// 步骤4：支付订单
.exec(
http("支付订单")
.post("/api/v2/payment")
.header("Authorization", "Bearer ${accessToken}")
.body(StringBody(
"""{
| "orderId": "${orderId}",
| "paymentMethod": "ALIPAY"
|}""".stripMargin
))
.check(status.is(200))
)
// 负载模式：梯度加压
setUp(
orderScenario.inject(
// 预热阶段：1分钟内加到50用户
rampUsers(50).during(1.minute),
// 稳定阶段：50用户持续2分钟
constantUsersPerSec(50).during(2.minutes),
// 加压阶段：1分钟内增到100用户
rampUsersPerSec(50).to(100).during(1.minute),
// 峰值阶段：100用户持续3分钟
constantUsersPerSec(100).during(3.minutes),
// 继续加压：到200用户
rampUsersPerSec(100).to(200).during(1.minute),
// 观察极限：200用户持续2分钟
constantUsersPerSec(200).during(2.minutes)
)
).protocols(httpProtocol)
// 断言：P99不超过2秒，错误率不超过1%
.assertions(
global.responseTime.percentile(99).lt(2000),
global.failedRequests.percent.lt(1.0)
)
}3.2 JMeter脚本（用于快速验证的配置示例）
<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2">
<hashTree>
<TestPlan testname="订单服务压测">
<ThreadGroup testname="下单用户组" num_threads="100" ramp_time="60" loops="100">
<hashTree>
<!-- 登录请求 -->
<HTTPSamplerProxy testname="登录">
<stringProp name="HTTPSampler.path">/auth/login</stringProp>
<stringProp name="HTTPSampler.method">POST</stringProp>
<boolProp name="HTTPSampler.postBodyRaw">true</boolProp>
<stringProp name="Argument.value">{"username":"testuser","password":"test123"}</stringProp>
</HTTPSamplerProxy>
<!-- 从响应中提取Token -->
<JSONExtractor name="提取Token">
<stringProp name="JSONExtractor.jsonPathExprs">$.data.accessToken</stringProp>
<stringProp name="JSONExtractor.referenceName">accessToken</stringProp>
</JSONExtractor>
<!-- 创建订单 -->
<HTTPSamplerProxy testname="创建订单">
<stringProp name="HTTPSampler.path">/api/v2/order</stringProp>
<stringProp name="HTTPSampler.method">POST</stringProp>
<HeaderManager>
<stringProp name="Header.name">Authorization</stringProp>
<stringProp name="Header.value">Bearer ${accessToken}</stringProp>
</HeaderManager>
</HTTPSamplerProxy>
<!-- 聚合报告 -->
<AggregateReport testname="压测报告">
<stringProp name="filename">result.csv</stringProp>
</AggregateReport>
</hashTree>
</ThreadGroup>
</TestPlan>
</hashTree>
</jmeterTestPlan>3.3 压测期间的监控查询（PromQL）
# 实时QPS
sum(rate(http_server_requests_seconds_count{application="order-service"}[30s]))
# P99响应时间（毫秒）
histogram_quantile(0.99,
sum(rate(http_server_requests_seconds_bucket{application="order-service"}[30s])) by (le)
) * 1000
# 错误率
sum(rate(http_server_requests_seconds_count{status=~"5..",application="order-service"}[30s]))
/
sum(rate(http_server_requests_seconds_count{application="order-service"}[30s])) * 100
# CPU使用率
rate(process_cpu_usage{application="order-service"}[30s]) * 100
# 数据库连接池活跃连接
hikaricp_connections_active{application="order-service"}
# 线程池等待任务数
executor_queue_remaining_capacity{name="bizThreadPool",application="order-service"}3.4 容量规划计算模型
package com.laozhang.capacity;
/**
* 容量规划计算工具
*/
public class CapacityPlanner {
/**
* 根据压测结果计算所需实例数
*
* @param peakQps 业务峰值QPS
* @param singleInstanceCapacity 单实例在满足SLO（P99<2s，错误率<1%）时的最大QPS
* @param safetyFactor 安全系数（通常0.7，即只用70%容量作为规划上限）
* @param redundancy 冗余实例数（至少1个，用于滚动更新时不降级）
* @return 推荐实例数
*/
public static int calculate(
int peakQps,
int singleInstanceCapacity,
double safetyFactor,
int redundancy
) {
// 单实例规划容量（打折后的）
int effectiveCapacity = (int) (singleInstanceCapacity * safetyFactor);
// 满足峰值需要的最小实例数
int minInstances = (int) Math.ceil((double) peakQps / effectiveCapacity);
// 加上冗余
return minInstances + redundancy;
}
public static void main(String[] args) {
// 压测结果：单实例在200QPS时P99=1.8s，刚好在阈值内
int singleInstanceCapacity = 200;
// 业务峰值：大促期间预计800QPS
int peakQps = 800;
// 安全系数0.7
double safetyFactor = 0.7;
// 冗余2个实例
int redundancy = 2;
int required = calculate(peakQps, singleInstanceCapacity, safetyFactor, redundancy);
System.out.printf("单实例容量: %d QPS%n", singleInstanceCapacity);
System.out.printf("有效容量(70%%): %d QPS%n", (int)(singleInstanceCapacity * safetyFactor));
System.out.printf("业务峰值: %d QPS%n", peakQps);
System.out.printf("最少需要实例数: %d%n", (int)Math.ceil((double)peakQps / (singleInstanceCapacity * safetyFactor)));
System.out.printf("含冗余实例数: %d%n", required);
// 输出：含冗余实例数: 8
}
}四、生产配置与调优
4.1 压测环境准备清单
1. 压测环境隔离：使用独立的压测环境，不要在生产或测试环境压测
2. 数据准备：准备足够数量的测试账号（避免单账号被限流）
3. 基准监控：压测前记录各项指标的基线值
4. 告警屏蔽：压测期间屏蔽告警，避免误报
5. 日志采样：压测期间降低日志采样率，避免日志量影响性能4.2 常见瓶颈的快速定位
# 查看JVM线程堆栈（定位线程阻塞）
jstack -l <pid> | grep -A 5 "BLOCKED"
# 查看GC日志
-Xloggc:/var/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
# Arthas实时诊断
java -jar arthas-boot.jar
# 进入后
> dashboard # 实时监控
> thread -n 5 # 最消耗CPU的5个线程
> trace com.laozhang.service.OrderService createOrder # 方法链路追踪五、踩坑实录
坑一：压测结果虚高，线上实际性能比压测低30%。
压测时用的是本地直连，没有经过完整的链路（网关、Nacos服务发现、各种过滤器）。每个组件都有一点开销，叠加起来导致线上实际性能比压测低很多。
解决方案：压测必须走完整链路，从网关入口压测，覆盖所有中间件，才能反映真实的系统性能。
坑二：只看平均响应时间，忽略了P99，结果大量用户体验差。
平均响应时间50ms，看起来很好。但P99是2000ms，说明1%的请求需要等待2秒。平均值被大量快速请求拉低了，掩盖了长尾问题。
压测报告必须看P50、P95、P99，平均值只是参考。SLO应该基于P99定义，而不是平均值。
坑三：压测数据不符合真实业务分布，找到的瓶颈不是真实瓶颈。
压测时只测了"下单"接口，但实际业务中"查询"接口的请求量是"下单"的100倍。压测找到了下单接口的瓶颈并优化了，但查询接口的缓存命中率问题没有被发现，大促时大量缓存穿透打垮了数据库。
压测的流量模型必须符合实际业务比例，用真实的接口分布做压测场景。
六、总结
微服务压测的核心是：走完整链路（不要只压单接口），用梯度加压找拐点，关注P99而不是平均值，压测结果对应容量规划。Gatling适合正式压测（异步模型、详细报告、脚本可版本化），JMeter适合快速探测。找到瓶颈后，用Prometheus+Grafana定位具体的资源瓶颈（CPU/内存/连接池/线程池），针对性优化。