k6 负载测试完整指南：从第一个脚本到多机分布式压测

k6 负载测试完整指南从第一个脚本到多机分布式压测【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 是一款用 Go 和 JavaScript 编写的负载测试工具适合需要在发版前把接口压测、下单全链路、前端交互验证真正跑起来的团队测试脚本进代码仓库CI 每次提交都压一遍多机分段分担负载指标直接灌进监控系统。 你正被哪类压测问题卡住假设你手上有一个订单服务要上线/api/checkout 这个接口能不能扛住 100 个并发用户、p99 延迟稳不稳在 2 秒内现在没人敢打包票。更麻烦的是登录、加购、支付这一整条链路串起来跑通了吗前端页面的交互瓶颈到底在前端还是在后端接口这三个问题对应三类不同的压测方式——划及格线、压完整业务流、模拟真实页面操作。下面按这个顺序陪你把每种都跑起来。为什么是 k6一句话定位k6 让你把压测脚本写成 JavaScript而不是在图形界面里拖配置。和传统压测工具比它有几个明显的不同脚本是代码能进 Git 做版本管理和 code reviewgit diff能直接看出这次压测方案改了什么交付是二进制的一个 Go 编译的可执行文件就能跑k6 run的退出码可以直接告诉 CI 管道这次压测过没过协议面宽HTTP/1.1、HTTP/2、WebSocket、gRPC 都有对应模块internal/js/modules/k6/浏览器交互还能驱动真实 Chromium 页面examples/browser/负载模型多固定并发、阶梯爬坡、按到达速率压都是内置执行器不用自己算。 5 行代码跑通第一个测试先把 k6 装好从源码构建的话仓库地址是 https://gitcode.com/GitHub_Trending/k6/k6然后写一个最小脚本 first.jsimport http from k6/http; export default function () { http.get(https://quickpizza.grafana.com); }执行k6 run first.js这能验证什么服务可用性。跑完看终端报告重点盯四个数checks的成功率应为 100%、http_req_duration的 p(95)/p(99)别只看 avg均值会把长尾平均掉、请求总数是否和预期一致。如果默认报告缺了你想要的分位数加--summary-trend-stats参数调整。看到结果了再往下写更复杂的场景。 按你想验证的东西写脚本给核心接口划一条及格线把阈值写进options.thresholds指标越线时k6 run直接以非零退出码结束——CI 就能靠它卡门禁。examples/thresholds.js 展示了更细的写法export const options { thresholds: { http_req_duration: [p(99)2000], // 99% 请求响应低于 2 秒 http_req_duration{name:/api/checkout}: [p(95)800], }, stages: [ { duration: 30s, target: 15 }, // 30s 从 0 爬到 15 个并发用户 { duration: 1m, target: 15 }, // 保持 1 分钟 { duration: 20s, target: 0 }, // 20s 收尾 ], };这能验证什么接口在爬坡和平台期能否守住 99% 2s且可以只对 /api/checkout 这一个接口单独划 95% 800ms 的更严线。压一整条业务流把接口串成流程登录拿 token下单时带上 token。步骤之间用返回值传数据每一步都用check断言import http from k6/http; import { check } from k6; export default function () { const login http.post(https://test.k6.io/login_get, { username: admin, password: password }); const token JSON.parse(login.body).token; check(login, { login ok: (r) r.status 200 token }); const order http.post(https://test.k6.io/create_order, { product: 2 }, { headers: { Authorization: Bearer ${token} } }); check(order, { order created: (r) r.status 200 }); }这能验证什么登录→下单这条链路端到端能不能走通以及哪一步先出问题。模拟真实用户点页面只测 API 测不出前端的问题。浏览器模块驱动真实 Chromium能点按钮、填表单、等导航import { browser } from k6/browser; import { check } from k6; export default async function () { const page await browser.newPage(); try { await page.goto(https://test.k6.io/, { waitUntil: networkidle }); await page.locator(input[namelogin]).type(admin); await Promise.all([ page.waitForNavigation(), page.getByRole(button, { name: Go! }).click(), ]); await check(page.locator(h2), { 欢迎标题出现: async (el) (await el.textContent()) Welcome, admin!, }); } finally { await page.close(); } }这能验证什么表单提交后页面是否真的跳转、登录后的状态比如欢迎标题有没有出现。注意浏览器模块仍属实验特性需要用带 Chromium 的 k6 构建如 grafana/k6 的 browser 镜像才能运行examples/browser/fillform.js 是一个含会话 cookie 断言的完整版本。 单机压不动时把负载摊到多台机器一台机器受 CPU、网卡和文件描述符限制并发再往上堆瓶颈会先出现在压测机自己身上。k6 的解法是 execution segment把整个测试区间 0–1 切成若干不重叠的小段每个实例只认领自己那一段各自只初始化该跑的那部分 VU同时开始、同时结束。只要所有段的并集覆盖 0–1总负载和一台大机器跑完整测试的行为一致。4 台机器分担 1 个测试的写法k6 run --execution-segment0:1/4 --execution-segment-sequence0,1/4,1/2,3/4,1 test.js k6 run --execution-segment1/4:1/2 --execution-segment-sequence0,1/4,1/2,3/4,1 test.js # 第 3 台 1/2:3/4第 4 台 3/4:1跑起来之后绕开三个老问题不再受单机硬件上限约束测试可以完全留在内网流量不必出到第三方云服务负载来源天然分散不同机房/区域的机器各跑一段就能模拟更接近真实分布的用户来源。指标汇总、阈值判定这类全局计算要集中处理docs/design/020-distributed-execution-and-test-suites.md 完整记录了分段执行的架构设计与已知缺口建议动手前先读一遍。 把压测变成团队的日常散落在个人电脑上的脚本撑不起团队。推荐这样的目录组织tests/ ├── api/ # 接口压测脚本 ├── browser/ # 页面交互脚本 ├── common/ # 登录等公共函数 └── scenarios/ # 完整业务流场景公共逻辑抽出来复用examples/es6sample.js 演示了 ES module 的写法。CI 里用官方镜像跑退出码直接卡管道performance-test: stage: test image: grafana/k6:latest script: - k6 run tests/api/checkout.js only: - main - /^release/最后把结果接进监控指标别让它留在终端里# 流式写入 InfluxDB配 Grafana 实时看压测曲线 k6 run --out influxdbhttp://influx:8086/k6 tests/api/checkout.js # 或用 OpenTelemetry 走 OTLP 通道 k6 run --out otlphttp://collector:4318 tests/api/checkout.js对应的输出实现分别在 internal/output/influxdb/ 和 internal/output/opentelemetry/接上之后P95/P99、成功率这些曲线就和日常监控长在一个面板里了。下一步三条建议按顺序做先选一个最核心的接口写p(99)2000这样的阈值当基线让每次构建都有及格线可对照基线稳定后把登录到支付的完整链路和浏览器场景接进来验证真实用户的体验路径单机扛不住时优先用 execution segment 把负载摊到多台机器而不是先想着买更大的压测机。现在就 clone 仓库把 examples/ 里的脚本挑一个跑起来——先看到报告再谈优化。想深入分布式执行的设计取舍读 docs/design/020-distributed-execution-and-test-suites.md想抄作业直接从示例开始。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考