性能测试相关理解---业务比例（业务模型）获取（三）

一、重要性

1、迭代项目

线上环境每个业务请求次数是不一样的。可以通过线上日志获取它的业务比例。通过业务比例模拟线上的真实业务场景。模拟生产线上的流量模型。

此处的模型指的是历史模型。

应用场景：生产环境出了性能bug，要在压测环境上复现此bug，肯定是需要模拟历史模型。还有一种情况是模拟未来的模型，如，未来的业务有发展（重点业务有变化），那么此时的业务比例就不能按照现在从现在生产统计上出来的历史比例作为参考。此时就需要业务部门或者项目团队来给出未来的业务比例

2、新项目

针对新项目：就由项目组进行定。或者通过线上试运行数据获取业务比例。新项目都会有试运行的过程。试运行过程可以作为新项目的业务获取比例来源。

3、应用

这个业务比例的主要应用：主要在两个场景里，一个是混合场景、一个是稳定性场景，还有一个异常场景，大部分其实是混合场景、稳定性场景。这种单场景不需要，单接口不涉及和其他接口的业务比例关系。

性能测试理论的业务模型，jmeter中也有业务模型（通过吞吐量控制器实现业务比例，业务模型转成压测模型，获取压测比例）

获取业务模型的的作用？
获取业务模型从生产日志统计，真实表现出来生产的真实情况。
模拟历史业务模型做压测，需统计日志做分析，获取业务比例模型。

模拟未来的业务模型，项目组定。

二、获取方式

获取方式主要两种：命令、日志平台

1、命令

用linux命令对日志文件进行统计分析
常见的三剑客命令：grep、awk、sed、cat等相关命令

用命令这种方式局限性比较大，因为实际工作中运维对日志有分割策略.
比如：按天分割、或按日志文件大小。业务量比较大时，业务日志文件会比较多，这样统计会比较麻烦。当前互联网日志文件一般时间都会保留的比较短，如一周。把日志文件内容同步到es后就会进行删掉，后续查询日志都是通过es查询日志。主流方式是通过日志平台进行获取业务比例。

2、日志平台

先了解日志平台架构

三、日志平台架构

1、ELK架构

es就是elasticsearch

1.1、产生的背景

互联网发展迅速、业务量越来越多，服务器也越来越多、产生的日志也越来越多。，开发去排查一个问题，如果没有统一个日志文件平台比较困难，业务需要做一些数据统计，也会比较麻烦，在这种情况下产生了日志平台。

ELK是最基础的日志平台，也是目前最流行的日志平台构建方案。

1.2、ELK组成

elasticsearch（搜索、分析、存储日志）

logstash（日志采集、日志分析）
kibana（kql、从es读取数据，进行可视化展示）

1.3、es、logstash、kibana开源软件的作用

es（elasticsearch）是一个分布式存储引擎，主要用来搜素分析存储日志，es可以是分布式的，可以横向扩展。如：索引自动分片。

logstash：主要用来做日志采集（主要把日志解析为JSOn格式再交给es，因为es要存日志）、日志分析，对数据做过滤分析。

kibana：是一个展示工具，从es读取数据，进行可视化展示。在日志平台其实就是通过kibana查看日志，还可以做汇总、分析、统计之类。

ELK最基础架构也会有一些不足，如数据采集，用logstash采集数据的话（采集应用服务器数据、每台应用服务器都要去进行安装java、logstash，logstash对服务器资源消耗较大，，所以在后面都是用其他软件进行数据采集）

logstash有多个，就表示对多个服务器进行采集日志数据，采集过后将数据放到es中，es是可以横向扩展的，即es一般都是集群，通过kibana从es集群里查看日志数据，这是最基础的。

2、EFK架构

因为logstash采集数据时消耗资源,就将l改成f
f就是Filebeat是一个轻量级日志采集器（对服务器资源消耗就比较小）,这个efk优点架构比较简单，缺点就是没办法做数据分析。

3、ELK + Filebeat架构

ELK引入Filebeat做日志采集，logstash继续做日志分析
采集数据用Filebeat，采集过后发给logstash对数据进行分析处理、过滤，处理完后发给es集群，最后通过kibana查看数据。

此架构的不足:logstash此处只有一个，扩展不是很方便。继续优化，即下一个架构

4、ELK + Filebeat + kafka架构

一般来说公司搭的是这种日志架构平台、此处的kafka也是集群，不是一个，此处的kafaka做了一个缓冲，解决了数量大的问题。

通过数据先发给kafka集群，logstash进行消费就行，此处有多个logstash，这样就解决了logstash不好扩展的问题，后面也是发到es集群，最后通过kibana查看日志数据。

四、业务比例获取

1、ELK部署架构

由于资源有限，此处搭建的是最基础的架构elk

此处有两台服务器184,185
192.168.117.184（安装es、logstash、kibana、nginx）
192.168.117.185（安装es）
184和185的es组成es集群

2、启动服务

2.1、nginx

cd /usr/local/nginx/sbin
./nginx

2.2、es、logstash、kibana3个服务设置了开机自启动，直接查看

systemctl status查看对应服务的状态

es（端口9200）：systemctl status elasticsearch
logstash（端口9600）：systemctl status logstash
kibana（端口5601）：systemctl status kibana

如果只统计，nginx和logstash的服务可以停了
systemctl stop logstash

2.3、访问kibana

http://192.168.117.184:5601/

3、统计

实际工作中线上项目有很多接口，不同用户有不同功能。不是每个接口都需要进行压测，不是每个功能都有并发请求，此时统计也是只统计压测范围内的接口。

3.1、首先选一个时间范围–Discovery

此处需要进行一个筛选，筛选之前怎么进行统计,首先选一个时间范围

选择时间范围一定要覆盖峰值范围

3.2、峰值业务覆盖维度

覆盖峰值业务：月（看哪个月业务量最大）、日、时、分

压测多少分钟、多少个小时，此次是按日进行统计

1）此次是按日进行统计，统计22号到28号，刚好7天

按天统计，就先获取业务量最多的一天。

2）选择该天业务量最大的某个小时

最大的是27号那天，获取到这一天后，再获取业务量最大一天每个小时的业务量（小时维度），选择业务量最大的某个小时

3）筛选压测请求业务数据（接口）

只统计压测的业务接口,此处就要去进行请求路径的筛选,此处的每一条记录就相当于请求

①根据requestkeywords请求关键字来做筛选

：是相等
：*是存在
and是多个
or

此处用相等，统计哪些请求

此处是706199,此处就相当于只有这四个接口的请求

中间一段数据量差不多，此时就可以获取它的业务比例、

②获取业务比例前看一下各个接口业务的趋势图

如此处只要login/in

③若几个接口的趋势是差不多的，此处就只做一个业务比例就行,统计业务比例—Visualize Library

Create yourfirst Visualization–lens–根据keywords

通过饼状图就可以看到业务比例

此处都是25%。25%，25%，25%,即就是1:1:1:1比例

如果只做前面三个接口压测

此处所有接口都是要进行做压测

④如果在看每一个接口趋势不一样时，需要将不一样的那一段单独截取出来

如21:30分-到21:40分各个接口的趋势不一样，那么就需要将这段时间选取出来单独做个统计。虽然这里面都是高峰，高峰的请求，业务量是不一样的，趋势不一样，就涉及到需要提取多个业务比例。

⑤还有一种是获取每一天最大，但是可能存在某一天它的业务量不是最大，某一个小时业务量最大，甚至超过了21：到22点，也需要将这段的业务比例统计出来。最后的混合场景的业务比例至少是一个，也可能是多个，最后整理出来，项目进行评估，这就是提取业务比例的过程。