大概去年这时候，写过一篇博客：浅谈容量测试与容量规划，里面聊了一些我个人对于容量测试和容量规划的一些了解以及想法。
由于今年我司要搞双十一大促，因此全链路压测中很重要的一环——容量测试和容量规划被列入了待办事项。
与之相对的，想正确的进行容量测试，对线上容量规划提供重要的参考依据，容量评估，就是我们在准备阶段需要做好的事情。如何做呢？？？
这篇博客，简述一下我在准备阶段，是如何开展容量评估工作以及遇到的一些问题，以及解决方案。。。
容量评估九步走——流程图
一、划分流量来源
在容量评估阶段，首先要做的是划分流量来源，这点需要根据具体的业务特点来划分。一般分为如下三种来源：
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台机器。
最后，别忘了在线上针对性的进行高可用验证！！！
