系统容量规划与压测实战从1万到100万QPS的科学扩容大家好我是迪哥。2026 年 618 前我们的预估峰值从 10 万 QPS 涨到了 100 万 QPS压测发现瓶颈在数据库连接池扩容了 20 倍才顶住。今天聊聊如何科学地做容量规划和压测不让你的系统死在峰值。为什么要做容量规划2023 年我们踩过坑❌ 618 峰值预估 5 万实际来了 20 万系统直接雪崩❌ 为了保险提前扩容了 10 倍成本超了 3 倍❌ 不知道瓶颈在哪瞎扩容钱花了性能没上去容量规划三步法1. 建立性能基准线单机性能测试# 用 JMeter 或者 wrk 压测 wrk -t12 -c400 -d30s http://localhost:8080/api/order # 结果示例 Running 30s test http://localhost:8080/api/order 12 threads and 400 connections Thread Stats Avg Stdev Max /- Stdev Latency 20.5ms 15.2ms 200.5ms 89.00% Req/Sec 5000.0 200.0 6000.0 90.00% 1800000 requests in 30.00s, 2.50GB read Requests/sec: 60000.00 ← 单机 6 万 QPS基准表指标数值单机 QPS60000单机 CPU 峰值80%单机内存峰值8GB数据库最大连接数20002. 预估峰值 冗余系数预估峰值 QPS 历史峰值 × 增长系数 × 突发系数 5万 × 2倍 × 1.5倍 15万 QPS 需要机器数 预估峰值 / 单机 QPS × 冗余系数 15万 / 6万 × 1.3 ≈ 4台 但实际是 100 万所以需要 100万 / 6万 × 1.3 ≈ 22台经验值日常冗余系数1.3-1.5大促冗余系数2-3新业务3-5倍冗余3. 识别瓶颈 扩容压测实战JMeter安装 JMeter下载https://jmeter.apache.org/download_jmeter.cgi测试计划Test Plan └── Thread Group (1000 threads, 10s ramp-up, 300s duration) ├── HTTP Request (POST /api/order) ├── View Results Tree └── Summary Report关键监控指标层级指标告警阈值系统CPU 80%系统Load Average CPU 核数系统内存 85%系统网络带宽 80%JVMHeap Used 80%JVMGC 次数Full GC 3次/5分钟应用错误率 0.1%应用P99 延迟 500ms中间件数据库连接池 90%中间件Redis 连接池 90%瓶颈定位示例现象应用 QPS 上不去CPU 只有 30%错误率上升提示GetConnectionTimeoutException定位# application.yml spring: datasource: hikari: maximum-pool-size: 20 ← 太小了优化spring: datasource: hikari: maximum-pool-size: 200 # 改成 200全链路压测单系统压测不够要全链路压测工具 → 网关 → 订单服务 → 库存服务 → 数据库 ↓ Redis关键点✅ 影子表数据库隔离✅ 消息隔离避免污染真实数据✅ 灰度流量从 10% 开始逐步放大压测脚本Go 版本package main import ( fmt net/http sync time ) func main() { concurrency : 1000 requests : 1000000 var wg sync.WaitGroup client : http.Client{Timeout: 10 * time.Second} start : time.Now() for i : 0; i concurrency; i { wg.Add(1) go func(workerID int) { defer wg.Done() for j : 0; j requests/concurrency; j { resp, err : client.Get(http://localhost:8080/api/order) if err ! nil { continue } resp.Body.Close() } }(i) } wg.Wait() duration : time.Since(start) qps : float64(requests) / duration.Seconds() fmt.Printf(QPS: %.0f, Duration: %v\n, qps, duration) }容量规划表格系统单机 QPS预估峰值冗余系数所需机器现状机器是否要扩容订单服务60000100万1.52510✅ 是库存服务8000080万1.5158✅ 是用户服务4000030万1.51112❌ 否网关15万100万1.5105✅ 是经验总结不要瞎拍脑袋基于历史数据 增长预期先压测再扩容不然钱花了性能没上去容量规划是动态的每季度重估一次监控是前提没有监控谈何容量规划灰度很重要别一上来全量从 10% 开始说到容量规划我家那只叫 Docker 的哈士奇最近饭量从 1 碗涨到了 4 碗我要是早做容量规划就不至于三天买一次狗粮了 我是迪哥我们下期再见往期推荐《Spring Cloud Alibaba 微服务全家桶》《Go 语言高并发服务性能调优》
系统容量规划与压测实战：从1万到100万QPS的科学扩容
系统容量规划与压测实战从1万到100万QPS的科学扩容大家好我是迪哥。2026 年 618 前我们的预估峰值从 10 万 QPS 涨到了 100 万 QPS压测发现瓶颈在数据库连接池扩容了 20 倍才顶住。今天聊聊如何科学地做容量规划和压测不让你的系统死在峰值。为什么要做容量规划2023 年我们踩过坑❌ 618 峰值预估 5 万实际来了 20 万系统直接雪崩❌ 为了保险提前扩容了 10 倍成本超了 3 倍❌ 不知道瓶颈在哪瞎扩容钱花了性能没上去容量规划三步法1. 建立性能基准线单机性能测试# 用 JMeter 或者 wrk 压测 wrk -t12 -c400 -d30s http://localhost:8080/api/order # 结果示例 Running 30s test http://localhost:8080/api/order 12 threads and 400 connections Thread Stats Avg Stdev Max /- Stdev Latency 20.5ms 15.2ms 200.5ms 89.00% Req/Sec 5000.0 200.0 6000.0 90.00% 1800000 requests in 30.00s, 2.50GB read Requests/sec: 60000.00 ← 单机 6 万 QPS基准表指标数值单机 QPS60000单机 CPU 峰值80%单机内存峰值8GB数据库最大连接数20002. 预估峰值 冗余系数预估峰值 QPS 历史峰值 × 增长系数 × 突发系数 5万 × 2倍 × 1.5倍 15万 QPS 需要机器数 预估峰值 / 单机 QPS × 冗余系数 15万 / 6万 × 1.3 ≈ 4台 但实际是 100 万所以需要 100万 / 6万 × 1.3 ≈ 22台经验值日常冗余系数1.3-1.5大促冗余系数2-3新业务3-5倍冗余3. 识别瓶颈 扩容压测实战JMeter安装 JMeter下载https://jmeter.apache.org/download_jmeter.cgi测试计划Test Plan └── Thread Group (1000 threads, 10s ramp-up, 300s duration) ├── HTTP Request (POST /api/order) ├── View Results Tree └── Summary Report关键监控指标层级指标告警阈值系统CPU 80%系统Load Average CPU 核数系统内存 85%系统网络带宽 80%JVMHeap Used 80%JVMGC 次数Full GC 3次/5分钟应用错误率 0.1%应用P99 延迟 500ms中间件数据库连接池 90%中间件Redis 连接池 90%瓶颈定位示例现象应用 QPS 上不去CPU 只有 30%错误率上升提示GetConnectionTimeoutException定位# application.yml spring: datasource: hikari: maximum-pool-size: 20 ← 太小了优化spring: datasource: hikari: maximum-pool-size: 200 # 改成 200全链路压测单系统压测不够要全链路压测工具 → 网关 → 订单服务 → 库存服务 → 数据库 ↓ Redis关键点✅ 影子表数据库隔离✅ 消息隔离避免污染真实数据✅ 灰度流量从 10% 开始逐步放大压测脚本Go 版本package main import ( fmt net/http sync time ) func main() { concurrency : 1000 requests : 1000000 var wg sync.WaitGroup client : http.Client{Timeout: 10 * time.Second} start : time.Now() for i : 0; i concurrency; i { wg.Add(1) go func(workerID int) { defer wg.Done() for j : 0; j requests/concurrency; j { resp, err : client.Get(http://localhost:8080/api/order) if err ! nil { continue } resp.Body.Close() } }(i) } wg.Wait() duration : time.Since(start) qps : float64(requests) / duration.Seconds() fmt.Printf(QPS: %.0f, Duration: %v\n, qps, duration) }容量规划表格系统单机 QPS预估峰值冗余系数所需机器现状机器是否要扩容订单服务60000100万1.52510✅ 是库存服务8000080万1.5158✅ 是用户服务4000030万1.51112❌ 否网关15万100万1.5105✅ 是经验总结不要瞎拍脑袋基于历史数据 增长预期先压测再扩容不然钱花了性能没上去容量规划是动态的每季度重估一次监控是前提没有监控谈何容量规划灰度很重要别一上来全量从 10% 开始说到容量规划我家那只叫 Docker 的哈士奇最近饭量从 1 碗涨到了 4 碗我要是早做容量规划就不至于三天买一次狗粮了 我是迪哥我们下期再见往期推荐《Spring Cloud Alibaba 微服务全家桶》《Go 语言高并发服务性能调优》
