在实际的性能测试工作中，我们面临的往往是复杂的业务场景、技术架构以及突增的用户访问量，在这种情况下单纯的压测已经无法很好的解决问题。
要想很好的保障在这种复杂情况下的系统性能和稳定性，我们需要在性能测试的基础上更进一步，做好容量保障工作。
这篇文章，我们就来聊聊容量、容量保障、容量测试以及容量规划相关的话题。
一、容量
1、什么是容量？
软件系统是基于硬件服务器部署的，硬件服务器限于本身的配置，其处理能力是有限的。
容量，即系统处于最大负载状态或某项指标达到所能接受的最大阈值下对请求的最大处理能力。
具体来讲，系统的容量（处理能力）是有限的，容量是可度量的。
2、如何统计容量指标？
1）统计维度
通常可以从如下两个维度来定量系统的容量：
2）统计方法
通常采集数据的方法，有以下几种方式：
①埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进行数据采集。
②日志/数据库：通过日志服务（如ELK）或者运维监控（如Devops）采集分析数据。
③Agent/探针：在需要采集的节点添加Agent/探针，实时采集；数据存入时序数据库（比如influxdb），实时展示。
3）注意事项
采集对比的数据一定要采集线上的真实数据，这样才能反映真实客观的系统压力。
二、容量保障
1、什么是容量保障？
理解了软件系统的容量，就可以很好的理解容量保障的工作内容了。
我们日常工作中的功能测试工作，就是保障软件功能的正确性、易用性等，叫做质量保障。
而容量保障，就是通过运用各种方法和工具，保障软件系统的容量可以承载并处理各种业务，并具有一定的弹性能力。
2、为什么需要容量保障？
随着移动互联网的发展，业务场景越发多变，技术架构也随着微服务、云原生等技术的出现越来越复杂。
以电商业务为例，性能测试同学经常面临这几个问题：
GMV（商品交易总额）增长两倍，系统性能可以满足业务增长需要吗？
如果无法满足，扩容能否解决问题？如果扩容扩多少？
如果要搞双11大促，如何保障系统在大促期间的稳定性？
诸如上诉此类问题，都是当前性能测试同学甚至运维、架构师面临的技术挑战。而容量保障工作就是为了解决诸如此类问题的有效手段。
3、容量保障有哪些难题？
容量的不确定性：业务场景多样、技术架构复杂，导致容量在不同场景不同时间段有不同表现。
容量评估的复杂性：服务调用链路复杂，上下游服务彼此的制约导致很难评估出一个较为准确的预期值。
容量测试的不准确性：测试和生产环境的差异、服务配置差异、硬件资源差异、网络环境差异、业务场景差异。
容量规划治理的复杂性：业务场景不断变化、代码版本不断迭代、新技术的引入、人员的流动变化都让容量规划和治理变得难上加难。
三、容量测试
1、如何理解容量测试？
容量测试，是性能测试里的一部分，它的目的是测量系统的最大容量，为系统扩容、性能优化提供参考，节省成本投入，提高资源利用率。就是运用各种方法和工具在这种复杂的情况下去不断验证容量结果，最终保障线上软件系统容量可以支撑业务正常运行的过程。
这是一个持续验证的过程，相比于传统的性能测试压几个接口，得到结果，优化验证完发布上线而言。容量测试更提倡持续验证，做到对各环节的容量永不信任，持续验证，最终达到持续的保障线上系统稳定性。
当然，容量测试和传统性能测试类似的点也有很多，同样需要需求分析，场景设计，数据准备，实施压测以及性能优化。
可以理解为，容量测试和传统性能测试并没有本质上的区别，都是为了让软件系统满足业务需要，支撑业务目标更好的达成。只是容量测试所提倡的方法和理念，更适用于当前我们所面临的环境和挑战。
了解容量测试，然后忘掉各种高大上的新概念，做到持续验证持续保障即可。
2、如何做容量测试？
1）测试思路
① 根据具体的业务情况和系统架构，通过配置测试的手段，测量得到单个服务节点在对应的业务场景下最大的性能表现。
② 根据系统架构（集群、分布式、微服务）特点，通过启用≥2的服务节点，来得到服务节点的增加后系统性能的提升比例。
③ 通过线上采集的系统数据，分析出过去某段时间（或某个业务）的高峰流量，然后通过计算，得到容量扩容，需要投入的实际服务数量。
2）约束/停止条件
在测试过程中，只要限定的某项指标达到最大可接受阈值或某项资源达到最大使用状态，即刻停止测试。
3）选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时一般遵循如下原则：
数据密集型：即并发请求量较大的类型，一般TPS和RT（响应时间）是比较关注的指标。
数据存储型：即需要存储读写的数据量较大的类型，一般吞吐量和IO是比较关注的指标。
3、注意事项
容量测试环境的配置，一定要和线上保持一致（服务器数量可以不同，但配置尽可能保持一致）。
4、容量测试解决了什么问题？
常规的性能测试，是有了需求，然后进行需求分析，场景设计，数据准备，脚本编写和压测执行以及定位优化验证这些步骤，而容量测试的特点在于计划性和预期性。
可以理解为常规的性能测试更偏向先有需求再出结果，而容量测试更注重预先评估结果，针对结果进行计划性的有步骤的验证。
如果分类的话，可以将容量测试要做的事情，分为如下三种情况：
日常事件：日常的迭代压测、性能巡检。
计划事件：比如新服务上线、双十一大促。
突发事件：比如线上流量突增、异常告警、紧急扩容。
容量测试就是为了达成容量保障目标的一种持续验证手段，要解决的问题除了日常工作中的需求，还要有计划的应对未来的需求，以及预期可能出现的容量风险并做好应对措施。
四、容量规划
1、为什么需要容量规划？
对于业务越来越复杂的商业形态，每个业务都由一系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的目的在于让每一个业务系统能够清晰地知道：
什么时候应该增加服务节点，什么时候应该减少服务节点（比如服务端接受到的流量达到什么量级）？（比如双十一，大促，秒杀）
为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可用性、稳定性，又能节约成本？
2、容量规划四步走
①业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少的流量冲击。
②系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配比，然后计算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑。
③系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进行针对性的调整。
④流量分配调整阶段：根据压测的结果，设定限流、服务降级、熔断、隔离等系统保护措施，来预防当实际流量超过系统所能承受的最大流量时系统无法提供服务。
3、计算公式
容量规划常规的计算公式如下：
A服务单机容量在50%水位时，TPS=200，设定为T；线上流量转化预估TPS为3000，设定为S；为保障服务高可用，预留30%机器资源做扩容buffer，设定为B。
那么A服务最终线上需要部署的机器数量的计算公式为：
Count（A）= (1+B)*(S/T）
Count（A）= (1+30%)*(S/T）= 19.5台机器；取整，那么服务A线上容量规划时，需要部署20台机器。
注意：
水位，一个带有刻度的容器当前装有液体的水面位置则为水位，而服务的最大水位就是系统的极限TPS；而服务的当前水位 = 当前总TPS/（单台机器极限TPS*机器数）*100%
服务的处理能力是有限的，而且为了保障服务的稳定可用性，不能让服务器持续处于高负载的状态，因此要提前预留一定的资源可用比率，作为缓冲区。
4、扩容手段
1）垂直扩容
升级服务的硬件配置，让单个服务节点的容量更大，来提供更高的系统服务能力。比如：加大服务机器的CPU数量和内存，更换性能更好的高速缓存服务器，数据存储用NAS盘替换等。
2）水平扩展
增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能力。
常见的方式有：
服务集群：服务器的数量由1→N（但需要重点关注负载均衡）。
分布式：提供服务的节点由统一集中管理部署，分散到不同的地点。
容器：提供更灵活的弹性扩容机制，根据具体的访问流量大小来弹性扩容或者缩容。
最后：下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
获取方式：QQ社区：902061117这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
