6.2 容量规划与压测闭环

6.2 容量规划与压测闭环

本节摘要：可观测性让你看清系统状态，但看清之后要做什么？答案是容量规划——预测未来需要多少资源，提前准备。本节讲容量规划的核心方法（基于历史数据预测趋势、基于压测确定系统极限），以及全链路压测怎么做。核心是把可观测数据和压测结果转化为扩缩容决策，形成“观测→规划→压测→决策”的闭环，让系统始终有恰到好处的容量。

学习目标

阅读完本节，你应当能够：

1. 说清容量规划要解决的核心问题
2. 用历史数据预测未来的资源需求
3. 理解压测的目标和几种压测类型
4. 设计一个全链路压测方案
5. 建立从观测到规划到压测到决策的闭环

一、问题与直觉

容量规划回答一个看似简单的问题：我的系统接下来需要多少资源？这个问题答不好，要么资源不够（大促时系统挂），要么资源浪费（平时闲置一堆机器烧钱）。

很多团队的容量规划方式很粗糙：看现在的资源用了多少，按经验加个百分比就是下个季度的预算。这种方式的问题是不精确——它假设负载线性增长，但真实负载常有突变（一次营销活动流量翻十倍）；它只看整体不看局部（整体资源够，但某个瓶颈组件不够）。

科学的容量规划，要结合两个数据源：历史数据（看趋势，预测未来）和压测数据（看极限，知道天花板在哪）。前者告诉你“大概会涨到多少”，后者告诉你“最多能扛多少”。两者结合，才能定出既不浪费又不冒险的容量。

二、核心原理

2.1 基于历史数据的趋势预测

容量规划的第一步，是从可观测系统的历史数据里找规律。看过去几个月的 QPS、CPU 利用率、存储增长曲线，拟合出趋势，外推未来几个月的需求。

这个预测要考虑几个因素。自然增长：业务量随时间的自然增长趋势。周期性波动：日周期（白天忙晚上闲）、周周期（工作日忙周末闲）、年周期（大促、节假日的峰值）。已知事件：计划中的营销活动、新产品上线带来的预期流量。

预测出来的是个范围（乐观估计、悲观估计），规划要按悲观估计（高需求）准备，避免不够用。

2.2 基于压测确定系统极限

历史数据告诉你需求会涨到多少，但你的系统能扛多少？这要靠压测（压力测试）来确定。

压测的核心目标：在满足 SLO（如 P99 RT 小于 200 毫秒）的约束下，系统能承载的最大负载是多少。这个最大负载就是系统的容量极限。容量极限通常是某个瓶颈组件决定的——CPU 打满、数据库连接池耗尽、网络带宽占满。压测要找出这个瓶颈在哪。

压测有几种类型。基准压测：逐步加压，找到系统的最大稳定吞吐。峰值压测：瞬间打到极高负载，看系统在尖峰下的表现（会不会雪崩、限流是否生效）。持久压测：在中等负载下长时间运行，发现内存泄漏、资源耗尽等慢性问题。

2.3 全链路压测

单接口压测只能发现单个接口的极限，但真实故障往往发生在多个接口、多个服务联动的场景。全链路压测模拟真实用户行为，压测整条业务链路（如浏览→加购物车→下单→支付），发现联动的瓶颈。

全链路压测的难点是真实性——要模拟真实的流量模型（各接口的请求比例）、真实的数据量（数据库里有足够数据）、真实的依赖（所有下游服务都在）。很多团队的全链路压测在“影子库”或“压测环境”做，避免影响生产数据。也有在生产环境做的（用压测流量标记区分真实流量），更真实但风险高。

三、工程实践要点

3.1 压测环境的选择

压测在哪做是个权衡。在独立压测环境做，安全（不影响生产），但环境可能和生产有差异（机器配置、数据量、依赖版本），压测结果失真。在生产环境做，真实，但有风险（可能影响真实用户）。

折中方案是在生产环境做，但严格隔离压测流量——压测请求打特殊标记，路由到专门的压测实例或影子库，不污染真实数据和真实用户体验。这种方式既真实又安全，是大型互联网公司的主流做法。

3.2 找瓶颈比看总量重要

压测的产出不只是“系统能扛多少 QPS”，更重要的是“瓶颈在哪”。因为容量规划要按瓶颈组件来——整体资源够不够没用，瓶颈组件不够就挂。所以压测要深入分析每个组件的资源使用，找到最先达极限的那个，它就是容量天花板。

⚠️ 常见坑：压测只看“总 QPS 能到多少”，不看瓶颈在哪。结果扩容时所有组件一起加，瓶颈组件扩了但非瓶颈组件也扩了（浪费），或者瓶颈组件没扩够（还是挂）。压测必须定位瓶颈，扩容聚焦瓶颈组件。

3.3 形成闭环：观测→规划→压测→决策

容量规划不是一次性活动，而是持续闭环。可观测系统持续采集负载数据，定期（如每月）基于数据预测下个周期需求，压测验证系统能力，据此做扩缩容决策，决策执行后再回到观测验证效果。这个闭环持续转，系统容量始终匹配需求。

大促等已知峰值事件前，要提前做全链路压测，确认系统能扛住预期峰值，发现弱点提前修复。大促后再复盘，把这次的真实数据纳入下一轮规划。

💡 关键直觉：容量规划的本质是“用提前准备换稳定性，用精准预测换低成本”。提前准备好就不慌，精准预测就不浪费。一个有科学容量规划的系统，既不会在大促时挂，也不会在平时烧钱养闲置机器——这是运维成熟度的标志。

一页速查

• 容量规划问题：确定未来需要多少资源，答不好要么不够用要么浪费。
• 趋势预测：从历史数据拟合自然增长、周期波动、已知事件，外推未来需求。
• 压测定极限：在 SLO 约束下找最大负载，三类（基准、峰值、持久）发现不同问题。
• 全链路压测：模拟真实用户行为压测整条链路，发现联动瓶颈。
• 压测环境：独立环境安全但失真，生产环境真实但要隔离压测流量。
• 找瓶颈：压测核心产出是瓶颈定位，扩容聚焦瓶颈组件。
• 持续闭环：观测→规划→压测→决策→观测，循环转，大促前重点压测。

至此，高并发系统的指标、架构、应用层、数据层、可靠性、运维可观测都讲完了。附录汇总了指标定义和核心组件对照，方便查阅。

压测的三个常见自欺

压测做久了会见到三种典型的自欺模式，识别它们比学会压测工具更重要。第一种是"环境自欺"：用缩水的测试环境跑出漂亮数字再线性外推——缓存命中率、数据量、连接数分布都无法线性外推，压测环境要么全等规格、要么明确换算系数并留足余量。第二种是"流量自欺"：只压平均流量不压突发模型，真实世界的突刺是毫秒级翻倍的，压测脚本要有阶梯加压和瞬时脉冲两种模式。第三种是"指标自欺"：只看吞吐和响应时间，不看错误率、资源水位、中间件积压——系统在崩溃前 often 表现出吞吐维持、错误率悄悄爬升的假稳定，盯单一指标的压测结论是危险的。

全链路压测是终局形态，它的价值在于覆盖真实依赖的相互影响，但改造成本高（流量染色、影子存储、环境隔离）。建议的路径是从单接口压测起步，到核心链路串联压测，最后才是全链路。每一级的结论都要沉淀成容量基线数据——什么流量水位对应什么资源水位，这条对应关系曲线才是容量规划真正的输出物，比"压测通过"四个字值钱得多。

最后补一个把压测常态化的组织技巧：把大促前的集中压测改成每月的例行压测日。集中压测的问题在于间隔太长，每次都像第一次——环境对不上、脚本失效、人员生疏。例行化之后，压测资产（脚本、数据、基线）持续保鲜，容量曲线按月更新，大促前只需增量验证。运维成本几乎不变，容量感知的时效性却从半年提升到月，这笔账怎么算都划算。

最后补压测报告的写作要点：一份能用的压测报告必须包含环境规格与生产的差异声明、加压模型（阶梯还是脉冲）、各级水位下的四组数据（吞吐、响应分位、错误率、资源水位）、以及和上次压测的对比与差异归因。最常见的缺陷是缺最后一项——没有对比的报告无法回答"系统是不是在变差"，而回答这个问题才是压测的终极目的。报告模板固化下来，每次填空式完成，团队的容量认知就有了连续的档案。

再补充数据准备的细节：压测数据的构造要保真——数据量级、分布特征（热点键的比例）、数据年限（老数据的索引深度）都要贴近生产，用造数脚本随机生成的均匀数据会让性能结论系统性偏乐观。造数本身要建模板复用，每次大促压测前按当前生产规模刷新，这份造数资产和压测脚本同样值钱，值得专人维护。

最后补充压测与真实的换算残差问题：即便全链路压测，也难完全复现生产的异构负载——批处理任务、缓存命中率的昼夜差异、第三方依赖的真实延迟。因此压测结论永远要乘一个可信系数（经验值七到八成），并保留一到两倍的安全余量。把可信系数写进容量报告，比给出一个虚假的精确数字更专业，也更能经得起大促的检验。

还有一个容易被忽略的闭环环节：压测后的资源回收与复盘。压测期临时扩容的实例、造数产生的数据、加压端的探针，都要有回收清单和执行记录，否则成本报表里会积攒越来越多的僵尸资源。复盘则要回答三个问题——结论是什么、和上次比变了什么、下次压测的改进项是什么。三问都有答案，压测才从一次性活动变成滚动资产。