参考：
https://www.cnblogs.com/imyalost/p/9630846.html
https://www.cnblogs.com/imyalost/p/11623716.html
浅谈容量测试与容量规划
在性能测试中，需要根据具体的性能需求和系统架构等情况，采用不同的测试策略，其中最常见的策略就有容量测试。
这篇博客，就来聊聊容量测试以及容量规划的一些内容。。。
一、什么是容量？如何理解？
在开始之前，有一点需要知道：系统的处理能力是有限的！
1、容量定义
所谓容量，即系统处于最大负载状态或某项指标达到所能接受的最大阈值下对请求的最大处理能力。
2、如何理解
①、系统的容量（处理能力）是有限的；
②、容量是可度量的；
二、如何统计容量指标？
1、统计维度
一般来说，可以从如下两个维度来定量系统的容量：
| 维度类型 | 列举说明 |
| 最大负载状态 | 服务器CPU使用率达到100% |
| 内存使用达到最大值 | |
| 磁盘IO延时超过所能接受的最大时延 | |
| 磁盘使用率超过最大限制 | |
| 网络使用率达到上限（最大吞吐量） | |
| 最大接受阈值 | 每秒请求数/事务数（QPS/TPS） |
| 响应时间（ART/99%RT） | |
| 事务成功率（一般要求99.99%甚至更高） | |
| 超时/异常错误率 | |
| 配置参数，比如：最大连接数、最大线程数、JVM内存分配上限 |
2、统计方法
一般来说，常用的采集数据的方法，有以下几种方式：
①、埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进行数据采集；
②、日志/数据库：通过日志服务（比如ELK）或者运维监控（现在很流行的Devops），采集分析数据；
③、Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存入时序数据库（比如influxdb），实时展示；
3、注意事项
①、采集对比的数据一定要采集线上的真实数据，这样才能反映真实客观的系统压力。
②、容量测试环境的配置，一定要和线上保持一致（服务器数量可以不同，但配置尽可能保持一致）。
三、容量测试
容量测试是性能测试里的一种测试方法，它的目的就是测量系统的最大容量，为系统扩容，性能优化提供参考，节省成本投入，提高资源利用率。
1、测试思路
①、根据具体的业务情况和系统架构，通过配置测试的手段，测量得到单个服务节点在对应的业务场景下最大的性能表现；
②、根据系统架构（集群、分布式、微服务）特点，通过启用≥2的服务节点，来得到服务节点的增加和系统性能的提升比例；
③、通过线上采集的系统数据，分析出过去某段时间（或某个业务）的高峰流量，然后通过计算，得到容量扩容，需要投入的实际服务数量；
2、约束/停止条件
在测试过程中，只要限定的某项指标达到最大可接受阈值或某项资源达到最大使用状态，即刻停止测试。
3、选择合适的容量指标
考虑到业务需求和系统架构的不同，在选取容量指标时一般遵循如下原则：
①、数据密集型：即并发请求量较大的类型，一般TPS和RT是比较关注的指标；
②、数据存储型：即需要存储读写的数据量较大的类型，一般吞吐量和IO是比较关注的指标；
四、容量规划
1、为什么需要容量规划？
对于业务越来越复杂的商业形态，每个业务都由一系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的目的在于让每一个业务系统能够清晰地知道：
①、什么时候应该增加服务节点，什么时候应该减少服务节点（比如服务端接受到的流量达到什么量级）？（比如双十一，大促，秒杀）
②、为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可用性、稳定性，又能节约成本？
2、容量规划四步走
①、业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；
②、系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配比，然后计算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑；
③、系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进行针对性的调整；
④、流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最大流量时，系统无法提供服务；
3、扩容手段
①、垂直扩容
升级服务的硬件配置，让单个服务节点的容量更大，来提供更高的系统服务能力。比如：
加大服务机器的CPU数量和内存，更换性能更好的高速缓存服务器，数据存储用NAS盘替换等。
②、水平扩展
即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能力。常见的方式有：
服务集群：服务器的数量由1→N（但需要重点关注负载均衡）；
分布式：提供服务的节点由统一集中管理部署，分散到不同的地点；
容器：提供更灵活的弹性扩容机制，根据具体的访问流量大小来弹性扩容或者缩容；
4、更多参考
关于容量规划，可以看这里：阿里巴巴全链路压测
关于集群和分布式，看这里：分布式与集群的区别是什么？
性能测试从零开始实施指南——容量评估篇
大概去年这时候，写过一篇博客：浅谈容量测试与容量规划，里面聊了一些我个人对于容量测试和容量规划的一些了解以及想法。
由于今年我司要搞双十一大促，因此全链路压测中很重要的一环——容量测试和容量规划被列入了待办事项。
与之相对的，想正确的进行容量测试，对线上容量规划提供重要的参考依据，容量评估，就是我们在准备阶段需要做好的事情。如何做呢？？？
这篇博客，简述一下我在准备阶段，是如何开展容量评估工作以及遇到的一些问题，以及解决方案。。。
容量评估九步走——流程图
一、划分流量来源
在容量评估阶段，首先要做的是划分流量来源，这点需要根据具体的业务特点来划分。一般分为如下三种来源：
1、PC端：以电商平台为例（淘宝、京东、拼多多......），指的是从PC端发起的用户请求流量；
2、移动端：这里的移动端包括手机、平板等各类移动设备（目前移动端的流量也是占比最大的一个流量来源渠道）；
3、小程序：近几年随着小程序的兴起，来源于小程序以及H5的流量也是不可忽视的一部分流量渠道；
敲黑板：如果为了更精确细化的进行流量划分，还可以根据流量来源的区域（国内/国外、包邮区/偏远地区）来划分，这样做的目的是可以根据地区来进行机房分配以及DNS网络配置！
问题：如何监控不同区域的流量？专业解决方案提供商（监控宝）、根据请求地址相关数据进行日志解析，生成监控热点图（grafana监控大盘）；
二、确认统计类型
这里的统计类型是从系统架构的角度来划分的，根据不同的系统架构、技术组件来确认流量落地的比例，主要分为如下四种类型：
1、DB容量：具体来说，比如MySQL集群中，不同业务库最近一小时的峰值QPS（需要结合数据采集的场景以及是否进行了分库分表、主从分离的配置）；
2、服务容量：如果是一体式服务，则无须考虑业务划分；如果是微服务类型或SOA类型，则需要根据业务拆分的不同服务，进行容量统计（需考虑到服务依赖的情况）；
敲黑板：服务容量的评估（指标还是QPS），还需要统计单机服务实例的配置、目前生产环境的机器数量！
3、消息容量：消息主要指的是消息队列，比如MQ、kafka（同样需要根据业务属性来划分）。
敲黑板：消息容量的统计，主要统计这几类数值：集群类型、Topic、ConsumeGroup、消息总量、与日常倍数、是否堆积、峰值QPS！
4、缓存容量：这里的缓存指的是Redis（CDN我目前还未接触到，这里不做概述），同样，需要按照不同的业务进行垂直划分。
敲黑板：容量评估时，需考虑到Redis的实例配置、模式（哨兵/集群）、峰值QPS、存储容量、机器数量、可用区（容灾）！
问题：涉及到热Key、大Key问题，建议提前进行大Key治理，热Key散列分布（记得检查会话保持策略）！
三、接入监控组件
1、Cat
①、简介：CAT是基于Java开发的实时监控平台，主要包括移动端监控，应用侧监控，核心网络层监控，系统层监控等。提供实时监控报警，应用性能分析诊断的工具。
②、功能特性：可参考这里：大众点评CAT开源监控系统剖析
2、Jeager
①、简介：open source, end-to-end distributed tracing.
②、架构图
3、Sentinel
①、简介：阿里中间件团队开源，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。
②、架构图
③、侧重点
多样化流量控制；
熔断降级；
系统保护(LOAD，RT，线程数，入口QPS，CPU使用率)；
实时监控和控制台配置；
4、Prometheus
①、简介：开源的系统监控和报警框架，灵感源自 Google 的 Borgmon 监控系统。2012 年，SoundCloud 的 Google 前员工创造了 Prometheus，并作为社区开源项目进行开发。
2015 年，该项目正式发布。2016 年，Prometheus 加入云原生计算基金会（Cloud Native Computing Foundation），成为受欢迎度仅次于 Kubernetes 的项目。
②、特性
多维的数据模型（基于时间序列的 Key/Value 键值对）；
灵活的查询和聚合语言 PromQL；
提供本地存储和分布式存储；
通过基于 HTTP 的 Pull 模型采集时间序列数据；
可利用 Pushgateway（Prometheus 的可选中间件）实现 Push 模式；
可通过动态服务发现或静态配置发现目标机器；
支持多种图表和数据大盘；
四、选取采集场景
数据采集场景的选取，与核心链路梳理有强依赖关系，建议按照如下三种方式进行。
1、日常峰值
选取生产环境日常的峰值流量进行统计，这里的峰值指的是区间峰值，区间一般可以选择30min；
2、核心链路
关于核心链路梳理，可以参考上一篇博客：性能测试从零开始实施指南——场景模型篇。示意图如下：
3、全量推送
对于电商业务而言，经常会有一些消息或者活动推送的玩法，建议选择在活动推送期间的峰值流量来作为数据采集场景的流量参考；
敲黑板：全量推送后会有一小段的高峰流量涌入，会对整个系统服务产生一定的影响！
五、汇总流量数据
流量统计表格Mode如下，仅供参考：
1、服务容量
2、消息容量
3、缓存容量
4、DB容量
六、获取投放引流
运营投放引流的渠道、力度以及转化率是很重要的一个参考指标，可以让我们对大促时期的预期流量有更准确的预估。主要从如下三点来考虑：
1、时段
一般来说，电商这种大促，都是从月初持续到活动当天，不断蓄水炒氛围，活动当天流量达到峰值，然后有2-3天的返场，总体来说时间大概为半个月左右。
获取到整个活动期间每个时间段有哪些活动，目的是确定峰值流量冲击的时间段，重点关注监控；
2、类型
主要是上述的时间段内，有哪些运营活动，比如：秒杀（超卖场景）、抢购（热点key的问题）、签到、抽奖、分享等；
3、量级
量级主要分为全量推送、特定用户推送、推送触达率、返场转化率等指标，这样方便我们更好的评估实时的流量峰值；
问题：为什么要获取运营投放和引流的数据呢？——为了更精准的评估峰值流量，针对性的部署演练专项预案！
七、确定验收水位
验收水位的作用，主要从以下两方面考虑：
1、监控告警阈值
确定运维保障的线上监控告警阈值，针对流量冲击，进行针对性的自动扩容；
2、资源可用缓冲
服务的处理能力是有限的，而且为了保障服务的稳定可用性，不能让服务器持续处于高负载的状态，因此要提前预留一定的资源可用比率，作为缓冲区。
达到或超过运维的告警监控阈值，则自动扩容或者触发限流策略。因此最终的性能验收水位，要结合上述两点来综合考虑。
如果能对流量做到精准控制，运维的自动化程度比较高的话，可以以单机的50%资源使用率作为扩容依据（淘宝貌似就是这个值）。
如果没有太精细化的控制，运维自动化程度不太高，建议以40%来作为验收水位。
八、执行容量测试
执行容量测试，应该是执行阶段要做的事情，由于容量测试测定的单机水位对容量评估和容量规划是承上启下的连接点，因此这里顺带提及一下。
容量测试的目的，就是获取单机容量（什么状态什么阈值下的容量，和上述第七点结合）！
九、线上容量规划
前面做了这么多准备工作，最终的目的是对线上容量规划有准确的参考和实施依据。容量规划常规的计算公式如下：
A服务单机容量在50%水位时，TPS=200，设定为T；线上流量转化预估TPS为3000，设定为S；为保障服务高可用，预留30%机器资源做扩容buffer，设定为B；
那么A服务最终线上需要部署的机器数量的计算公式为：Count（A）= (1+30%)*(S/T）= 19.5台机器；取整，那么服务A线上容量规划时，需要部署20台机器。
最后，别忘了在线上针对性的进行高可用验证！！！