前言
前面的文章介绍了链路梳理，三大模型，算是对整体业务和技术体系有了一定了解，这是由面到点的梳理。但系统最终的承载能力，还是取决于它的容量。这篇文章，我想为大家介绍下容量评估和容量规划的相关知识。
理解容量
如何定义容量？
容量即系统处于 某种负载状态 或 某项指标达到所能接受的最大阈值 下对请求的 最大处理能力 。
如何理解容量？
- 容量是可度量的；
- 系统容量（处理能力）是有限的；
如何规划容量？
- 预期线上有X的流量下，希望系统在安全水位下具有Y的处理能力；
- 假设线上出现某种情况导致Xmax，那希望系统的Y可以水平扩展以应对；
如何测试容量？
假设线上预期流量为X，所需容量为Y，容量测试的预期指标为Z，那么：Y=X/Z。
容量测试的几点注意事项：
- 明确预期流量指标（线上峰值QPS为10W）；
- 明确可接受的时延和安全水位指标（CPU%≤40%，核心链路RT≤50ms）；
- 单机单服务的容量水位，建议通过混合场景来验证：
-
订单服务有四个核心API；
-
订单服务的服务器配置是4C8G；
-
容量测试脚本要综合考虑4个API的流量配比和流量模型；
-
CPU%≤40%，核心链路RT≤50ms下，测试结果就是单机容量；
容量评估
容量评估我在之前的文章《性能测试从零开始实施指南——容量评估篇》中已做过详细介绍，这里不多做赘述。关于容量评估，参考下面两张思维导图，更容易理解。
容量评估九步走流程图
容量评估职责内容划分
容量规划
容量规划的价值
互联网公司成本
- 人力成本；
- 硬件成本；
- 运营成本；
容量规划的价值
- 为性能优化提供参考；
- 提高资源使用率， 降低成本；
- 不断促进基础技术设施的建设和优化；
容量规划落地四步走
明确预期的指标和流量模型
- 没有明确的预期指标就是耍流氓；
- 流量模型很重要，类似漏斗的转化模型；
知道单点容量和扩容边际递减比率
- 线下单机单接口单服务压测很有必要；
- 理论上可以无限水平扩容，但节点越多，复杂度越高，性能提升比率越低；
不断评估线上流量增长趋势和流量模型
- 借助监控体系不断优化流量模型；
- 借助告警体系不断发现异常流量；
- 借助性能基线不断优化性能瓶颈；
- 借助流量巡检不断找到容量波动；
线下性能基线日常化和线上流量巡检日常化
测试如何做好容量规划
-
性能基线（参考文章：性能测试体系建设之路）
-
基准测试（参考文章：聊聊性能测试中的基准测试）
-
团结协作（和运维&DBA&基础架构打好关系）
-
线上全链路压测（参考文章：全链路压测常态化方案）
如果喜欢我文章，点赞、关注、在看三连走起。
如果想阅读更多的文章，可以关注我的公众号。
往期技术文章推荐