性能测试从零开始实施指南——容量评估篇

大概去年这时候，写过一篇博客：浅谈容量测试与容量规划，里面聊了一些我我的对于容量测试和容量规划的一些了解以及想法。

因为今年我司要搞双十一大促，所以全链路压测中很重要的一环——容量测试和容量规划被列入了待办事项。

与之相对的，想正确的进行容量测试，对线上容量规划提供重要的参考依据，容量评估，就是咱们在准备阶段须要作好的事情。如何作呢？？？

这篇博客，简述一下我在准备阶段，是如何开展容量评估工做以及遇到的一些问题，以及解决方案。。。

 

容量评估九步走——流程图

 

1、划分流量来源

在容量评估阶段，首先要作的是划分流量来源，这点须要根据具体的业务特色来划分。通常分为以下三种来源：

一、PC端：以电商平台为例（淘宝、京东、拼多多......），指的是从PC端发起的用户请求流量；

二、移动端：这里的移动端包括手机、平板等各种移动设备（目前移动端的流量也是占比最大的一个流量来源渠道）；

三、小程序：近几年随着小程序的兴起，来源于小程序以及H5的流量也是不可忽视的一部分流量渠道；

敲黑板：若是为了更精确细化的进行流量划分，还能够根据流量来源的区域（国内/国外、包邮区/偏远地区）来划分，这样作的目的是能够根据地区来进行机房分配以及DNS网络配置！

问题：如何监控不一样区域的流量？专业解决方案提供商（监控宝）、根据请求地址相关数据进行日志解析，生成监控热点图（grafana监控大盘）；

 

2、确认统计类型

这里的统计类型是从系统架构的角度来划分的，根据不一样的系统架构、技术组件来确认流量落地的比例，主要分为以下四种类型：

一、DB容量：具体来讲，好比MySQL集群中，不一样业务库最近一小时的峰值QPS（须要结合数据采集的场景以及是否进行了分库分表、主从分离的配置）；

二、服务容量：若是是一体式服务，则无须考虑业务划分；若是是微服务类型或SOA类型，则须要根据业务拆分的不一样服务，进行容量统计（需考虑到服务依赖的状况）；

敲黑板：服务容量的评估（指标仍是QPS），还须要统计单机服务实例的配置、目前生产环境的机器数量！

三、消息容量：消息主要指的是消息队列，好比MQ、kafka（一样须要根据业务属性来划分）。

敲黑板：消息容量的统计，主要统计这几类数值：集群类型、Topic、ConsumeGroup、消息总量、与平常倍数、是否堆积、峰值QPS！

四、缓存容量：这里的缓存指的是Redis（CDN我目前还未接触到，这里不作概述），一样，须要按照不一样的业务进行垂直划分。

敲黑板：容量评估时，需考虑到Redis的实例配置、模式（哨兵/集群）、峰值QPS、存储容量、机器数量、可用区（容灾）！

问题：涉及到热Key、大Key问题，建议提早进行大Key治理，热Key散列分布（记得检查会话保持策略）！

 

3、接入监控组件

一、Cat

①、简介：CAT是基于Java开发的实时监控平台，主要包括移动端监控，应用侧监控，核心网络层监控，系统层监控等。提供实时监控报警，应用性能分析诊断的工具。

②、功能特性：可参考这里：大众点评CAT开源监控系统剖析

二、Jeager

①、简介：open source, end-to-end distributed tracing.

②、架构图

三、Sentinel

①、简介：阿里中间件团队开源，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。

②、架构图

③、侧重点

多样化流量控制；

熔断降级；

系统保护(LOAD，RT，线程数，入口QPS，CPU使用率)；

实时监控和控制台配置；

四、Prometheus

①、简介：开源的系统监控和报警框架，灵感源自 Google 的 Borgmon 监控系统。2012 年，SoundCloud 的 Google 前员工创造了 Prometheus，并做为社区开源项目进行开发。

2015 年，该项目正式发布。2016 年，Prometheus 加入云原生计算基金会（Cloud Native Computing Foundation），成为受欢迎度仅次于 Kubernetes 的项目。

②、特性

多维的数据模型（基于时间序列的 Key/Value 键值对）；

灵活的查询和聚合语言 PromQL；

提供本地存储和分布式存储；

经过基于 HTTP 的 Pull 模型采集时间序列数据；

可利用 Pushgateway（Prometheus 的可选中间件）实现 Push 模式；

可经过动态服务发现或静态配置发现目标机器；

支持多种图表和数据大盘；

 

4、选取采集场景

数据采集场景的选取，与核心链路梳理有强依赖关系，建议按照以下三种方式进行。

一、平常峰值

选取生产环境平常的峰值流量进行统计，这里的峰值指的是区间峰值，区间通常能够选择30min；

二、核心链路

关于核心链路梳理，能够参考上一篇博客：性能测试从零开始实施指南——场景模型篇。示意图以下：

三、全量推送

对于电商业务而言，常常会有一些消息或者活动推送的玩法，建议选择在活动推送期间的峰值流量来做为数据采集场景的流量参考；

敲黑板：全量推送后会有一小段的高峰流量涌入，会对整个系统服务产生必定的影响！

 

5、汇总流量数据

流量统计表格Mode以下，仅供参考：

一、服务容量

二、消息容量

三、缓存容量

四、DB容量

 

6、获取投放引流

运营投放引流的渠道、力度以及转化率是很重要的一个参考指标，可让咱们对大促时期的预期流量有更准确的预估。主要从以下三点来考虑：

一、时段

通常来讲，电商这种大促，都是从月初持续到活动当天，不断蓄水炒氛围，活动当天流量达到峰值，而后有2-3天的返场，整体来讲时间大概为半个月左右。

获取到整个活动期间每一个时间段有哪些活动，目的是肯定峰值流量冲击的时间段，重点关注监控；

二、类型

主要是上述的时间段内，有哪些运营活动，好比：秒杀（超卖场景）、抢购（热点key的问题）、签到、抽奖、分享等；

三、量级

量级主要分为全量推送、特定用户推送、推送触达率、返场转化率等指标，这样方便咱们更好的评估实时的流量峰值；

问题：为何要获取运营投放和引流的数据呢？——为了更精准的评估峰值流量，针对性的部署演练专项预案！

 

7、肯定验收水位

验收水位的做用，主要从如下两方面考虑：

一、监控告警阈值

肯定运维保障的线上监控告警阈值，针对流量冲击，进行针对性的自动扩容；

二、资源可用缓冲

服务的处理能力是有限的，并且为了保障服务的稳定可用性，不能让服务器持续处于高负载的状态，所以要提早预留必定的资源可用比率，做为缓冲区。

达到或超过运维的告警监控阈值，则自动扩容或者触发限流策略。所以最终的性能验收水位，要结合上述两点来综合考虑。

若是能对流量作到精准控制，运维的自动化程度比较高的话，能够以单机的50%资源使用率做为扩容依据（淘宝貌似就是这个值）。

若是没有太精细化的控制，运维自动化程度不过高，建议以40%来做为验收水位。

 

8、执行容量测试

执行容量测试，应该是执行阶段要作的事情，因为容量测试测定的单机水位对容量评估和容量规划是承上启下的链接点，所以这里顺带说起一下。

容量测试的目的，就是获取单机容量（什么状态什么阈值下的容量，和上述第七点结合）！

 

9、线上容量规划

前面作了这么多准备工做，最终的目的是对线上容量规划有准确的参考和实施依据。容量规划常规的计算公式以下：

A服务单机容量在50%水位时，TPS=200，设定为T；线上流量转化预估TPS为3000，设定为S；为保障服务高可用，预留30%机器资源作扩容buffer，设定为B；

那么A服务最终线上须要部署的机器数量的计算公式为：Count（A）= (1+30%)*(S/T）= 19.5台机器；取整，那么服务A线上容量规划时，须要部署20台机器。

 

最后，别忘了在线上针对性的进行高可用验证！！！