为什么要进行系统容量评估？原因可能有很多，比如要确认承诺的SLA是否能满足、系统的稳定性是否有保障、资源用量成本是否能精简、当前架构是否能匹配业务增长等等。可以说系统容量评估是以业务为导向的资源与性能的平衡，着眼于当下，是资源的高效利用，着眼于未来，是资源满足业务发展和突发需求，最终目的是保障系统在各种负*条件下均能正常运行。
具体而言，系统容量评估的核心目标是量化系统在常态和峰值场景下的资源需求，确保系统能够支撑业务运行（不过*）且不造成资源浪费（不冗余）。其本质是将业务需求转化为技术指标，再将技术指标转化为资源配置的量化过程。从业务指标到技术指标体现系统的交互模型，从技术指标到资源指标体现系统的基准性能。
系统容量评估的基本流程一般包括如下几个步骤：
- 步骤 1：收集业务需求，明确核心业务指标
- 步骤 2：分析系统交互，需求转为技术指标
- 步骤 3：给定质量要求，获取组件性能基准
- 步骤 4：指标映射基准，计算组件所需资源
- 步骤 5：考虑业务发展，预测未来容量需求
- 步骤 6：验证组合瓶颈，确保系统容量匹配
步骤 1：收集业务需求，明确核心业务指标
业务需求是容量评估的终点，也是容量评估的源头。业务需求转成可量化的业务指标，主要与用户的规模量级、行为量级和数据量级有关。
常见的业务指标举例：
- 用户规模：注册用户数（总）、在线用户数（月活/日活）；
- 用户行为：页面访问（PV/UV）、消息发送（日均/峰值）、转化漏斗（折损率、成功率）；
- 用户数据：增量数据（日均，文本/图片/视频）、存量数据（存储周期，年/月/日）。
业务指标要具备一定前瞻性，以满足未来周期的业务需要。新业务上线可以根据产品需求目标进行制定，待上线运行一段时间后根据实际情况再考虑扩缩容，也可以优先小规模运行，随着流量变化再慢慢扩容。对于有稳定数据的存量系统，可以用时序分析法进行趋势分析，找出流量发展和波动规律，作为最终指标和峰值系数的参考。
业务指标需要标注业务场景，也要明确时间维度，区分“常态”和“峰值”的不同需求。具体业务场景示例：
|
业务场景 |
直播带货 |
|
业务指标 |
日活用户5000万 |
|
商品页日均访问量400万 |
|
|
峰值1小时订单30万 |
|
|
交易数据至少保存10年 |
步骤 2：分析系统交互，需求转为技术指标
业务指标需转化为系统可识别的技术指标，核心是建立从业务行为到系统交互的量化模型。业务场景对应系统的不同入口，技术指标主要包括入口的并发量、过程的调用量、生成的数据量，以及通道的传输量。
入口并发量的关键指标是并发用户数，指同一时间与系统交互的用户数，可以用在线用户数和并发率进行估算。
- 并发用户数=在线用户数×并发率
并发率根据业务经验进行评估，如果是新上线业务并无数据可以参考，那么可以参考行业经验（如友商发布的口径）或平行功能（如已发布的其他模块）。
- 峰值在线用户100万，并发率10%，则峰值并发用户数10万。
用户与系统交互产生对系统的请求，请求分为两类：
- QPS（Queries Per Second）：每秒查询量，侧重读压力；
- TPS（Transactions Per Second）：每秒事务量，侧重写压力。
从并发用户数到并发请求量，需要从交互入口及流量路径分析读写放大比。
- 10万并发用户，每个用户每秒刷新2次页面，则QPS=10万×2=20万；如果有10%的用户会下单，则TPS=10万×10%=1万；如果每笔交易会再产生3笔级联交易，则放大后TPS=1万×(1+3)=4万。
系统处理用户请求会产生需要存储的数据，数据总量与数据增量、存储周期和冗余架构有关。
- 单存储量=日均新增数据量×存储周期×(1+冗余系数)
- 总存储量=单存储量×副本数
其中，冗余系数与弹性需求有关（如业务波动、碎片膨胀、额外日志等），副本数与数据容灾架构有关（如主从集群2副本、分布式集群3副本）。
- 每日新增100GB数据，存储3年（1095天），数据集群1主2从，考虑冗余30%空间，则
- 单存储量=100GB×1095×1.3≈139TB
- 总存储量=139TB×3≈417TB
对于流量敏感型业务（如文件下*、视频点播），带宽对业务表现影响显著，传输带宽与传输速率有关。
- 峰值带宽=并发传输用户数×单用户平均传输速率
传输速率估算按业务形态有所不同，如音视频点播可按平均码率、数据传输可按抽取模式、远程调用可按协议大小与QPS等。
- 1000位用户同时下*码率为10Mb/s的视频，则峰值带宽=1000×10Mb/s≈10Gb/s。
步骤 3：给定质量要求，获取组件性能基准
系统由多个独*组件构成（如应用服务器、数据库、缓存、消息队列等），系统能否支撑指定的技术指标，实际上也是独*组件能否满足穿透的技术指标。
组件最大的承*能力要在合适的质量要求下才有意义，例如在10秒的响应时间下讨论应用服务的最大处理并发是没有意义的。但如何定义合适的质量要求也跟具体业务有关，没有统一的硬性标准，要具体情况具体分析，常用的参考指标有响应时间、资源水位、超时率、错误率、淘汰率等等。
获取组件性能基准的模型有经验法、线性法、类比法、压测法等。
- 经验法：直接拿行业基准或历史数据，例如已知单机4核8G的Redis能支持10万QPS；
- 线性法：有参考数据，但规格对不上，根据规格参数进行计算，例如根据上述经验，单机8核16G的Redis能支持20万QPS；
- 类比法：有参考数据，但类型对不上或不能线性计算，根据技术理解进行推算，例如根据上述经验，单机4核8G的Memcached也能支持10万QPS；
- 压测法：没有参考数据，或需要更精确地评估组件性能，通过压力测试获取组件的最大容量。
经验法、线性法、类比法既有主观判断，也有环境偏差，适合粗略评估，不宜精细计算。压测法通过压测工具模拟负*，记录组件在不同压力下的 “负*-性能” 曲线（如响应时间），找到 “性能拐点”（响应时间开始急剧上升），这个拐点即为该组件的最大容量。
- 应用服务器：当QPS=5000时，响应时间从100ms突增至2s，则最大QPS=5000；
- 数据库：当TPS=2000时，SQL执行超时率>2%，则最大TPS=2000；
- 缓存：当QPS=10万时，内存使用率达90%并触发淘汰，则最大QPS=10万。
步骤 4：指标映射基准，计算组件所需资源
步骤2得到峰值负*，步骤3得到基准负*，简单相除可以计算每个组件需要的实例数量或资源规格。冗余系数是必须要考虑的，一是应对业务流量的突发峰值，二是组件实例可能发生故障，三是组件性能不一定可以线性叠加。
- 组件规模=峰值负*÷基准负*×(1+冗余系数)
不可避*地，冗余系数也依赖主观判断，即使可以对规模化的组件进行再压测，业务突刺和故障概率也没法准确预计。一般来说冗余系数会在1倍以下，否则系统常态利用率不过半是极大的浪费。如果真有高出平时几倍流量的突发场景，应引入弹性伸缩机制，而不是静态容量建设来解决问题。
- 峰值订单TPS=5000，数据库单实例最大TPS=2500，冗余系统1.2，则数据库实例数=5000÷2500×1.2≈3，说明需要分拆到3组数据库同时提供服务，或用3倍规格的实例。
步骤 5：验证组合瓶颈，确保系统容量匹配
组件单独评测的容量，组合起来可能发挥不出来全功率。根据木桶原理，系统整体容量是由其中最短板的组件决定的，所以要对系统进行组合验证，以确保各组件的资源需求相匹配，避*其中某些组件成为瓶颈。
- 应用服务器5台支撑25000QPS，缓存3台支撑30000QPS，数据库4台支撑10000QPS，那么系统整体容量只能支撑10000QPS。这种情况要么存在资源浪费，要么得提升短板性能。
这里面有路径分析的因素，也有组件协同的因素。
路径推算越准确，对组件的读写评估就越准确。这依赖于更详尽的白盒分析，对研发人员有较高的技术要求和时间要求，但在复杂分布式系统中可能无以为继。如果有建设良好的全链路可观测能力，路径分析会事半功倍。
此外，可以通过全链路压测的方式对系统整体性能进行探底。压测可以帮助发现系统的天花板，但没办法指出系统的瓶颈在哪，发现瓶颈仍需要依赖可观测的能力。再者，压测只适用于对系统容量进行后验，当业务指标变化、组件架构变化或调用链路扩展时，如何先验地对组件进行升级调整，还是需要前述步骤的分析方法。
在资源与性能的平衡中，在组件的冲突与协调中，容量评估不仅是发现系统能力边界的过程，更是深入分析业务和系统运行机理，以让系统架构更加合理化的过程。容量评估既是终点也是起点。
