全链路压测(9)：容量评估和容量规划
前言
前面的文章介绍了链路梳理，三大模型，算是对整体业务和技术体系有了一定了解，这是由面到点的梳理。但系统最终的承载能力，还是取决于它的容量。这篇文章，我想为大家介绍下容量评估和容量规划的相关知识。
理解容量
如何定义容量？
容量即系统处于某种负载状态或某项指标达到所能接受的最大阈值下对请求的最大处理能力。
如何理解容量？
容量是可度量的；
系统容量（处理能力）是有限的；
如何规划容量？
预期线上有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&基础架构打好关系）
线上全链路压测（参考文章：）
如果喜欢我文章，点赞、关注、在看三连走起。
往期技术文章推荐