压测驱动弹性伸缩：华为云 PerfTest + HPA 性能优化实战

💡 摘要: 云原生实战系列第 7 篇！使用华为云 PerfTest（原 CPTS）对 CCE 上部署的 Java 微服务进行全链路性能压测，涵盖压测场景设计、JMeter 脚本适配、实时监控、瓶颈分析、JVM 参数调优、HPA 弹性伸缩策略配置。基于真实数据给出 2C4G / 4C8G / 8C16G 三种规格的性能基线和成本最优配置建议，附 3 个压测踩坑实录和 5 套调优模板。

🎯 为什么需要性能压测？

应用上线 ≠ 扛得住流量

云原生实战系列集成全景

🏗️ 架构设计：压测集成方案

📝 第一步：创建 PerfTest 压测场景

1.1 PerfTest 控制台创建

# 登录华为云 → PerfTest（原 CPTS）→ 创建测试工程
# 工程名称: demo-app-perftest
# 区域: 同 CCE 集群区域（避免跨区网络延迟）

# 创建测试用例
# 测试用例: 下单接口压测
# 协议: HTTPS
# 请求方法: POST
# 请求路径: /api/order/create
# 请求体: JSON 模板（见下文）

1.2 JMeter 脚本配置

PerfTest 兼容 JMeter 脚本，可以直接上传 .jmx 文件：

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0">
  <hashTree>
    <!-- ===== 测试计划 ===== -->
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan">
      <stringProp name="TestPlan.comments">demo-app 下单接口压测</stringProp>
    </TestPlan>
    <hashTree>
      
      <!-- ===== 1. 全局变量 ===== -->
      <Arguments guiclass="ArgumentsPanel" testclass="Arguments">
        <collectionProp name="Arguments.arguments">
          <elementProp name="base_url" elementType="Argument">
            <stringProp name="Argument.value">https://api.demo.com</stringProp>
          </elementProp>
        </collectionProp>
      </Arguments>
      <hashTree/>
      
      <!-- ===== 2. HTTP 请求默认值 ===== -->
      <ConfigTestElement guiclass="HttpDefaultsGui" testclass="ConfigTestElement">
        <stringProp name="HTTPSampler.domain">${base_url}</stringProp>
        <stringProp name="HTTPSampler.port">443</stringProp>
        <stringProp name="HTTPSampler.protocol">https</stringProp>
      </ConfigTestElement>
      <hashTree/>
      
      <!-- ===== 3. 定时器：阶梯加压 ===== -->
      <ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer">
        <stringProp name="throughput">100</stringProp>  <!-- 目标吞吐量 100 TPS -->
        <stringProp name="calcMode">all active threads</stringProp>
      </ConstantThroughputTimer>
      <hashTree/>
      
      <!-- ===== 4. 事务控制器：下单 ===== -->
      <TransactionController guiclass="TransactionControllerGui" testclass="TransactionController">
        <stringProp name="TransactionController.name">下单流程</stringProp>
      </TransactionController>
      <hashTree>
        
        <!-- 4.1 登录获取 Token -->
        <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy">
          <stringProp name="HTTPSampler.path">/api/auth/login</stringProp>
          <stringProp name="HTTPSampler.method">POST</stringProp>
          <stringProp name="HTTPSampler.postBodyRaw">true</stringProp>
          <elementProp name="HTTPsampler.Arguments" elementType="Arguments">
            <collectionProp name="Arguments.arguments">
              <elementProp name="body" elementType="Argument">
                <stringProp name="Argument.value">{"username":"test_${__threadNum}","password":"test123"}</stringProp>
              </elementProp>
            </collectionProp>
          </elementProp>
        </HTTPSamplerProxy>
        <hashTree>
          <JSONPathPostProcessor guiclass="JSONPathPostProcessorGui" testclass="JSONPathPostProcessor">
            <stringProp name="JSONPostProcessor.jsonPathExpr">$.data.token</stringProp>
            <stringProp name="JSONPostProcessor.referenceNames">token</stringProp>
          </JSONPathPostProcessor>
          <hashTree/>
        </hashTree>
        
        <!-- 4.2 创建订单 -->
        <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy">
          <stringProp name="HTTPSampler.path">/api/order/create</stringProp>
          <stringProp name="HTTPSampler.method">POST</stringProp>
          <elementProp name="HTTPsampler.Arguments" elementType="Arguments">
            <collectionProp name="Arguments.arguments">
              <elementProp name="body" elementType="Argument">
                <stringProp name="Argument.value">
                  {"userId":"u_${__threadNum}","productId":"P${__Random(1,100)}","quantity":1,"amount":${__Random(10,500)}}
                </stringProp>
              </elementProp>
            </collectionProp>
          </elementProp>
        </HTTPSamplerProxy>
        <hashTree/>
        
        <!-- 4.3 查询订单状态 -->
        <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy">
          <stringProp name="HTTPSampler.path">/api/order/status/${orderId}</stringProp>
          <stringProp name="HTTPSampler.method">GET</stringProp>
        </HTTPSamplerProxy>
        <hashTree/>
        
      </hashTree>
      
      <!-- ===== 5. 监听器：结果收集 ===== -->
      <ResultCollector guiclass="ViewResultsFullVisualizer" testclass="ResultCollector"/>
      <hashTree/>
      <ResultCollector guiclass="SummaryReport" testclass="ResultCollector"/>
      <hashTree/>
      <ResultCollector guiclass="GraphVisualizer" testclass="ResultCollector"/>
      <hashTree/>
      
    </hashTree>
  </hashTree>
</jmeterTestPlan>

1.3 CSV 数据驱动（模拟真实用户）

# perf-test-data.csv
userId,productId,amount
u_10001,P001,299.00
u_10002,P002,159.00
u_10003,P003,399.00
u_10004,P001,89.00
u_10005,P004,599.00

<!-- 在 JMeter 中添加 CSV Data Set Config -->
<CSVDataSet guiclass="TestBeanGUI" testclass="CSVDataSet">
  <stringProp name="filename">perf-test-data.csv</stringProp>
  <stringProp name="variableNames">userId,productId,amount</stringProp>
  <stringProp name="delimiter">,</stringProp>
  <stringProp name="recycle">true</stringProp>  <!-- 循环使用 -->
  <stringProp name="stopThread">false</stringProp>
</CSVDataSet>

⚡ 第二步：阶梯加压与实时监控

2.1 加压策略

好的压测不是一上来就 1000 并发，而是像温水煮青蛙，观察系统在哪个点崩溃。

# PerfTest 加压配置
加压策略:
  阶段 1 - 预热:
    并发数: 5
    持续时间: 1 分钟
    目标: JIT 预热，建立连接池
  
  阶段 2 - 低负载:
    并发数: 20
    持续时间: 3 分钟
    目标: 基线 TPS 和 RT
  
  阶段 3 - 中负载:
    并发数: 50
    持续时间: 3 分钟
    目标: 观察 CPU/内存变化
  
  阶段 4 - 高负载:
    并发数: 100
    持续时间: 3 分钟
    目标: 找到最大 TPS
  
  阶段 5 - 极限负载:
    并发数: 200
    持续时间: 3 分钟
    目标: 系统崩溃点（观察 HPA 是否生效）
  
  阶段 6 - 恢复:
    并发数: 5
    持续时间: 1 分钟
    目标: 观察系统恢复能力

2.2 实时监控看板

压测执行时，同时观察 4 个维度的数据：

2.3 关键监控指标

# 压测期间需要关注的关键指标
基础设施指标（AOM）:
  - CPU 使用率（每个 Pod）
  - 内存使用率（每个 Pod）
  - 网络 I/O（入站/出站）
  - Pod 重启次数
  - HPA 扩容/缩容事件

应用指标（APM）:
  - TPS（每秒事务数）
  - 响应时间（P50 / P95 / P99）
  - 错误率
  - 活跃线程数
  - JDBC 连接池使用率
  - GC 频率和暂停时间
  
数据库指标:
  - 活跃连接数
  - 慢查询数量
  - 锁等待时间
  - 磁盘 IOPS
  
业务指标:
  - 订单成功率
  - 支付成功率
  - 库存扣减一致性

🔧 第三步：瓶颈分析与 JVM 调优

3.1 典型瓶颈定位

3.2 JVM 参数优化模板

# =====================
# JVM 参数配置模板（2C4G）
# =====================
JAVA_OPTS="-Xms1g -Xmx1g \
  -XX:MetaspaceSize=128m \
  -XX:MaxMetaspaceSize=256m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+ParallelRefProcEnabled \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/dumps \
  -Djava.awt.headless=true \
  -Dspring.profiles.active=prod"

# =====================
# JVM 参数配置模板（4C8G）
# =====================
JAVA_OPTS="-Xms4g -Xmx4g \
  -XX:MetaspaceSize=256m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=100 \
  -XX:ParallelGCThreads=4 \
  -XX:ConcGCThreads=2 \
  -XX:+ParallelRefProcEnabled \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/dumps \
  -XX:+PrintGCDetails \
  -XX:+PrintGCDateStamps \
  -Xloggc:/data/gc/gc-%t.log"

# =====================
# JVM 参数配置模板（8C16G）
# =====================
JAVA_OPTS="-Xms8g -Xmx8g \
  -XX:MetaspaceSize=512m \
  -XX:MaxMetaspaceSize=512m \
  -XX:+UseZGC \
  -XX:ConcGCThreads=4 \
  -XX:ParallelGCThreads=8 \
  -XX:+ZGenerational \
  -XX:MaxGCPauseMillis=10 \
  -XX:+DisableExplicitGC \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/dumps \
  -XX:AllocateHeapAt=/dev/shm"

💡 调优口诀: 2C4G 用 G1GC → 4C8G 用 G1GC 精调 → 8C16G 用 ZGC。不要在小内存上用 ZGC，会浪费 30% 的性能。

3.3 Spring Boot 连接池调优

# application-prod.yml
spring:
  datasource:
    hikari:
      # ===== 2C4G 配置 =====
      maximum-pool-size: 10
      minimum-idle: 5
      idle-timeout: 300000
      connection-timeout: 3000  # 3 秒超时
      max-lifetime: 600000
      
      # ===== 4C8G 配置 =====
      # maximum-pool-size: 20
      # minimum-idle: 10
      
      # ===== 8C16G 配置 =====
      # maximum-pool-size: 50
      # minimum-idle: 20

  redis:
    timeout: 2000
    lettuce:
      pool:
        max-active: 8
        max-idle: 8
        min-idle: 2
        max-wait: -1ms

# Tomcat 线程池
server:
  tomcat:
    threads:
      max: 200     # 最大工作线程
      min-spare: 20  # 最小空闲线程
    accept-count: 100  # 等待队列长度
    connection-timeout: 5000
    max-connections: 8192

📈 第四步：HPA 弹性伸缩策略

4.1 基于 CPU 和内存的 HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-app
  minReplicas: 3        # 最小副本数
  maxReplicas: 20       # 最大副本数（防止无限扩容）
  behavior:
    scaleDown:          # 缩容策略
      stabilizationWindowSeconds: 300  # 等待 5 分钟稳定窗口
      policies:
        - type: Percent
          value: 50     # 每次缩容最多 50%
          periodSeconds: 60
    scaleUp:            # 扩容策略
      stabilizationWindowSeconds: 0  # 立即扩容
      policies:
        - type: Percent
          value: 100    # 每次扩容翻倍
          periodSeconds: 15
      selectPolicy: Max
  metrics:
    # ===== 指标 1：CPU 使用率 =====
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70  # 目标 CPU 70%
    
    # ===== 指标 2：内存使用率 =====
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80  # 目标内存 80%
    
    # ===== 指标 3：自定义指标（请求 QPS）=====
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: 500  # 每个 Pod 目标 500 QPS

4.2 基于自定义指标（APM 指标）的 HPA

安装 Prometheus Adapter，将 APM 的 QPS 指标暴露给 HPA：

# Prometheus Adapter 配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-adapter-config
  namespace: monitoring
data:
  config.yaml: |
    rules:
      # 将 APM 的 HTTP 请求速率转换为 HPA 可用指标
      - seriesQuery: 'apm_http_server_requests_seconds_count{app!=""}'
        resources:
          overrides:
            kubernetes_namespace:
              resource: namespace
            kubernetes_pod_name:
              resource: pod
        name:
          matches: "^(.*)_seconds_count"
          as: "http_requests_per_second"
        metricsQuery: |
          sum(rate(<<.Series>>{<<.LabelMatchers>>,app="demo-app"}[1m])) by (<<.GroupBy>>)

4.3 压测触发 HPA 行为分析

4.4 HPA 调优建议

📊 第五步：性能测试数据

5.1 不同规格性能基线

5.2 不同规格 TPS 对比

5.3 成本效益分析

结论:

• 性价比最优: 4C8G 规格 TPS/元最高，适合大部分业务
• 性能最优: 8C16G + ZGC 适合低延迟（P99 < 100ms）要求的场景
• 成本最低: 2C4G 适合非核心业务或开发环境

🔥 踩坑实录

踩坑 1：JVM 预热不足导致压测数据偏差

现象: 压测前 2 分钟 TPS 只有 50，3 分钟后突然跳到 180。

根因: JVM JIT（即时编译器）需要预热，3 分钟后热点代码编译完成，性能翻倍。

解决:

# 在 PerfTest 中添加预热阶段
预热配置:
  并发数: 5
  持续时间: 3 分钟  # 给 JVM 足够的预热时间
  目标: 触发所有热点方法的 JIT 编译

# 或者使用 Spring Boot Actuator 手动预热
@Configuration
public class WarmupConfig {
    @PostConstruct
    public void warmup() {
        // 在应用启动后，通过内部请求预热热点代码
        IntStream.range(0, 1000).parallel().forEach(i -> {
            // 模拟用户请求，触发 JIT
            restTemplate.getForEntity("http://localhost:8080/api/health", String.class);
        });
    }
}

踩坑 2：HPA 扩容延迟导致毛刺

现象: 压测过程中发现 TPS 在扩容瞬间下降 50%，持续 30 秒后恢复。

根因: HPA 的扩容流程有 30 秒延迟（感知指标 → 决策 → 拉镜像 → 启动 JVM → 预热），期间老 Pod 被压垮。

解决:

# 方案一：提前部署额外冗余（推荐）
# 配置 minReplicas = 3，日常运行 3 副本
# 对于秒杀场景，提前扩容到 5 副本

# 方案二：使用 PDB（PodDisruptionBudget）预留资源
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: demo-app

# 方案三：缩短 HPA 采集周期（默认 15s → 5s）
# CCE 控制台 → 集群配置 → 监控配置 → 指标采集周期
metricsCollectionInterval: 5s  # 默认 15s

# 方案四：使用 KEDA 替代 HPA，支持事件驱动的即时扩容
# KEDA 可以基于 RabbitMQ 队列深度、Kafka Lag 等指标即时扩容

踩坑 3：MySQL 连接池耗尽

现象: 压测到 100 并发时，错误率突然飙升到 30%，报 HikariPool-1 - Connection is not available, request timed out after 3000ms。

根因: HikariCP 连接池配置过小（10 个连接），100 并发下每个请求持有连接的时间过长（≈ 200ms），连接池枯竭。

解决:

# 方案一：增大连接池（短期方案）
spring:
  datasource:
    hikari:
      maximum-pool-size: 30  # 从 10 增加到 30
      connection-timeout: 5000

# 方案二：优化 SQL 减少连接持有时间（长期方案）
# 原 SQL: SELECT * FROM orders WHERE user_id = ?（全表扫描，耗时 200ms）
# 优化后: SELECT id, amount, status FROM orders WHERE user_id = ? AND status IN (1,2,3)（加复合索引，耗时 5ms）

# 方案三：添加 Redis 缓存
# 热点数据从缓存读取，减少数据库连接占用

# 方案四：读写分离
# 使用华为云 RDS 只读副本，将查询请求分流

🚀 第六步：压测报告与容量规划

6.1 PerfTest 压测报告模板

# =====================
# 性能压测报告
# =====================
测试基本信息:
  应用: demo-app
  测试日期: 2026-04-15
  测试人员: 张三
  环境: CCE 生产环境（3 副本，4C8G）
  压测工具: 华为云 PerfTest

压测结果摘要:
  最大 TPS: 210
  P50 响应时间: 42ms
  P95 响应时间: 85ms
  P99 响应时间: 120ms
  错误率: 0.05%
  CPU 平均使用率: 72%
  内存平均使用率: 65%
  HPA 触发次数: 3 次

瓶颈分析:
  1. MySQL 全表扫描（已添加索引）
  2. JVM 堆内存偏小（已从 1G 调到 4G）
  3. HPA 扩容延迟 35s（已关注，暂可接受）

容量规划建议:
  - 日常流量（50 TPS）: 3 副本足够
  - 促销流量（200 TPS）: 需要 6-8 副本
  - 大促流量（500 TPS）: 需要 15+ 副本，建议提前扩容

6.2 长期容量规划

💰 成本核算

❓ 常见问题 FAQ

Q1：PerfTest 和 JMeter 有什么区别？压测场景应该选哪个？

PerfTest 是华为云的商业压测服务，底层兼容 JMeter 脚本。区别在于：

建议：首次压测用 PerfTest 快速建基线，熟悉流程后导出 JMeter 脚本做精细化调优。

Q2：HPA 目标 CPU 设置多少合适？为什么不是 50% 或 90%？

目标 CPU 的选择需要平衡资源利用率和扩容响应速度：

• 70%（推荐）：留有 30% 的缓冲，避免流量突增时扩容来不及。实测表明，70% 目标在 100→200 并发场景下扩容延迟约 30s，错误率 < 0.5%。
• 50%：适合延迟敏感型业务（P99 < 100ms），但资源利用率低，成本高。
• 90%：适合成本敏感型业务，但扩容窗口窄，突发流量容易击穿。

黄金法则：先按 70% 建基线，观察 P99 延迟和扩容延迟，再根据业务容忍度微调。

Q3：压测时 Pod 频繁 OOMKilled，但堆内存还有剩余，为什么？

容器 OOMKilled 由 cgroup 的内存限制触发，JVM 的堆内存只是容器内存的一部分。常见原因：

1. 堆外内存溢出：NIO Direct Buffer、Metaspace、线程栈、Native 内存等不被 -Xmx 控制。
2. JVM 未感知容器限制：未设置 -XX:+UseContainerSupport（JDK 8u191+ 默认开启），JVM 看到了宿主机的全部内存。
3. 预留空间不足：容器内存 limit = JVM 堆 + 堆外内存（≈ 堆的 20-30%）。

建议：容器内存 request/limit 设为 -Xmx × 1.3。例如 -Xmx4g 配 6G 容器内存。

Q4：为什么 PerfTest 报告中的 TPS 和 APM 监控的 TPS 对不上？

两个系统的统计口径不同，差异是正常的：

排查建议：以 PerfTest 的 TPS 作为容量评估依据，以 APM 的 RT 和错误率作为调优依据。两者相差 < 10% 属正常范围。

Q5：阶梯加压每个阶段跑多久才够？跑短了数据不准怎么办？

每个阶段的持续时间取决于业务场景的稳定标准：

• 内存型业务（缓存、Session 管理）：每个阶段至少 5 分钟，观察内存是否持续增长（内存泄漏需 10 分钟+）。
• CPU 密集型（计算、加密）：3 分钟足够，CPU 在 30 秒内就能稳定。
• IO 密集型（数据库、网络调用）：5 分钟，连接池和线程池需要时间达到稳态。
• JVM 应用：至少 3 分钟（含 JIT 预热），推荐 5 分钟。

兜底方案：如果时间有限，每个阶段至少跑 2 分钟，然后用 PerfTest 的「累计报告」功能拉长观察窗口，忽略前 30% 的数据（预热期）。

📝 总结

要点总结：

1. ✅ PerfTest 压测场景设计 — JMeter 脚本、阶梯加压、数据驱动
2. ✅ 实时监控与分析 — AOM + APM 多维度观察
3. ✅ JVM 参数调优 — 2C4G / 4C8G / 8C16G 三套模板
4. ✅ HPA 弹性伸缩配置 — CPU/内存/自定义指标策略
5. ✅ 性能瓶颈定位 — 数据库/连接池/GC 全栈排查
6. ✅ 成本效益分析 — TPS/元 最优规格推荐

下篇预告

第8篇：从编码到运维：华为云 Maven 微服务全链路架构复盘与交付模板 — 回顾第1-7篇全流程，给出端到端 CI/CD 最佳实践、架构决策记录（ADR）、成本总盘点、团队协作规范，让整个云原生实战系列形成一个可复用的企业级交付模板。

💡 互动话题: 你的应用在压测中遇到过最离谱的性能问题是什么？最终怎么解决的？