4. 压测工具选型：主流压测工具对比

在将压测能力集成到 Backstage 之前，必须选择一款适合平台化、模板化、自助化场景的压测引擎。本节从架构模式、脚本语言、分布式能力、CI/CD 集成度、Backstage 适配性五个维度，对 JMeter、Locust、Gatling、k6 四款主流工具进行横向对比，并给出推荐结论。

4.1 四款工具核心特性一览

4.2 架构模式对比：单体 vs 微服务 vs 云原生

压测工具的架构决定了它在 Backstage 中作为“压测引擎”的集成复杂度。下图从部署形态、控制方式、扩展能力三个层面展示四款工具的架构差异。

4.3 脚本语言与模板化能力对比

Backstage 压测模板的核心是“脚本即模板”。开发者通过模板参数动态生成压测脚本，因此脚本语言的表达力、可读性、参数化能力至关重要。

• JMeter（XML）：脚本为 XML 格式，参数化需通过 CSV 数据文件或 JMeter 属性，模板化需拼接 XML 字符串，维护成本高。
• Locust（Python）：Python 脚本灵活，支持类继承、装饰器、动态参数，但 Python 在容器镜像中体积较大（~200MB）。
• Gatling（Scala DSL）：DSL 表达力强，但 Scala 编译链较重，模板化需 Maven 构建，不适合轻量级自助接入。
• k6（JavaScript）：ES6 语法，支持 __ENV 环境变量、__VU 虚拟用户变量、__ITER 迭代变量，天然适合模板参数注入。

// k6 脚本模板 — 通过环境变量注入压测参数
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: __ENV.VUS || 10,          // 虚拟用户数，默认 10
  duration: __ENV.DURATION || '30s', // 压测时长，默认 30 秒
};

export default function () {
  const baseUrl = __ENV.BASE_URL || 'http://localhost:8080';
  const res = http.get(`${baseUrl}/api/health`);
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

4.4 分布式压测与云原生适配

当压测规模超过单机能力时，分布式执行能力成为关键。Backstage 压测模板需要支持一键拉起分布式压测集群。

4.5 选型结论：k6 作为 Backstage 压测模板首选引擎

综合以上对比，本课程选择 k6 作为 Backstage 压测模板的默认压测引擎，理由如下：

1. 脚本语言对齐：JavaScript 是 Backstage 前端插件的主要开发语言，开发者无需学习新语言即可编写压测脚本。
2. 容器化轻量：k6 官方镜像仅 ~50MB，适合 CI/CD 流水线快速拉取和启动。
3. 云原生分布式：k6-operator 提供 Kubernetes 原生分布式能力，与 Backstage 的 Kubernetes 插件天然集成。
4. 指标输出标准化：内置 Prometheus 输出，可直接对接 Backstage 的监控面板。
5. API 可编程性：k6 提供 REST API 和 JavaScript SDK，方便 Backstage 模板引擎动态控制压测生命周期。