性能测试第四课-项目环境的准备

陆陆陆小司

已于 2023-12-21 21:48:07 修改

阅读量460

点赞数

分类专栏：性能测试文章标签：运维压力测试

于 2022-12-06 09:22:55 首次发布

本文链接：https://blog.csdn.net/qq_32941719/article/details/128193106

版权

性能测试专栏收录该内容

13 篇文章 2 订阅

订阅专栏

性能测试需要知道的知识

两条线
- 服务器虚拟化（物理机---虚拟机---容器（小型虚拟机linux））
  - 关键记住 VMware 虚拟化技术（kvm）
  - 08-10年服务器都是物理机
  - 10-15年服务器是刀片机 +VMware虚拟化技术
    - 在一个刀片机中，使用VMware虚拟化技术，可以生成N多个虚拟操作系统，-------要是电信运营商
  - 15年左右阿里开始做云产品
    - 虚拟化技术发展而来，云服务器，其实就是虚拟操作系统+硬件（虚拟硬件）
  - 操作系统
    - linux
      - centos Ubuntu
      - 无图形界面的linux
    - 服务器组成：
      - 操作系统 +硬件 + 应用服务
      - 操作系统：重点学linxu、操作系统原理
      - 硬件： CPU 、内存、磁盘
- 服务的拆分
  - 单一 -----------集群
  - 把大项目---------拆成小项目-------拆成更小的服务-------微服务
  - tomcat： java项目部署服务的最典型的中间
    - 项目包 war jar 丢到webapps，秋冬tomcat
    - server.xml
    - catalina.sh
  - 集群：把提供相同能力输出的服务，集成在一起，提供更强能力输出的方式
    - 负载均衡（不是平均分配）：负载均衡策略
    - Nginx：把分布式部署的机器，集成到一起，通过相同能力输出的一个典型软件
  - 数据库服务
    - 关系数据库：Mysql，postgresql
      - 数据库也有集群
    - 非关系型数据库：redis，MongoDB
    - 时序数据库：influxdb，prometheus -----性能监控平台
  - 缩小中间件:
    - springboot\springcloud 自带了tomcat
    - 操作系统缩小，容器 docker容器
      - docker容器，其实就是一个严格的linux系统
  - 服务之间通信：协议
    - 协议：服务双方，共同遵循的某一个明确的规则，来传递信息
      - http/https ---API接口
    - 微服务中常用的通信协议：dubbo ---RPC
  - 性能测试：是通过接口来测试服务器的性能
    - 用工具，调用接口，接口被调用，从而让服务来处理接口请求
    - 接口请求频率越高，短时间内需要处理请求数量就越多，从而测出服务器的性能
    - 我们调用接口，就需要遵循接口的协议

压测准备

压测场景

压测是有目的的压测，也就是说不是随便找些接口发一通压力，而压测全部的接口也是做不到的或者说无意义的，得有压测的优先级，所以梳理压测场景是很重要的。高优场景主要有下面几个：

高频业务场景（都要下拉刷新）
关键业务场景，使用频率低，一旦出问题就很严重（微信账号登录）
性能高消耗场景（淘宝下单）
曾经出现过问题的场景

压测有分单接口压测和场景化压测，前者会简单一些，后者一般是多个接口混合操作以组成一个业务场景，两者在方法上是相通的。

梳理场景时QA需要与RD对齐，确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标；在确定每个接口的压测目标时，要考虑到压测对象是单实例单机房还是集群；在细节上也要确认是单接口压测还是场景化压测，每个接口的流量占比以及优先级，需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。

压测环境

在梳理完压测场景后，就要确认压测链路是否完整或符合预期。从一个服务到另一个服务，是不是链路上每一个服务都要压到？下游服务如审计安全等是不是已经考虑到？压测过程中产生的脏数据是否会影响线上数据？可能还要细化到具体下游某个服务不参与压测，如何处理呢？以上种种问题，可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量，改造完后还要自测验证才能正式开始压测，下面讲一些重点问题，部分内容引用自[文末的参考资料][全链路压测的大概思路]。

脏数据问题

如果是在独立的一套环境中操作，不存在该问题
影子表：如果是在线上操作，一般将数据写入影子表（与原数据表在schema上一致的不同名表）而非原数据表，实现压测数据与线上数据隔离
白名单：指定测试id或者测试账号，在入库后通过统一id区分压测数据，统一处理
各类存储层的压测改造，包括缓存层、消息队列、离线数据库等隔离问题。常规方法在压测链路中透传压测标记（也叫流量染色，挺形象的），比如json数据中加is_stress标记，存储层根据标记区分压测流量，对压测数据添加指定前后缀再入库等特殊处理

不参与压测的服务如何处理

mock server：通过录制request和response的方式，对业务的代码实现无侵入
服务stub：针对压测流量做处理，类似单测stub，代码stub模拟服务返回response，需要修改代码
可以独立部署一套线下环境进行压测。在不影响线上环境的前提下，确保机房，网络，存储，上下游服务与线上保持一致，部署一套独立的环境进行测试，机器与线上隔离，机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行，因为很难把整个链路所有系统都独立再部署一套，所以应用范围有限。

备注：上游、下游如何定义？

下游的输入来自于上游的输出，假设有服务A、B，A调用了B（或者说A依赖B），那B就是A的上游，A就是B的下游，因为A的输入来自于B的输出（A调用了B，获取B的输出）。

更简单地理解，越接近用户的东西，越是下游。

更常见的方法是直接使用线上环境压测，在机器负载低的时间段（如深夜）人工发起或定时发起压测。

压测数据

压测数据其实没什么神秘的，网上说什么按照业务模型产出数据，表达上做了过度抽象反而不好理解，其实意思就是按照业务核心场景将所需要的数据构造出来。关键是要如何科学地模拟线上数据分布，阿里双十一大促中有如下的业务流量漏斗模型，需要给不同场景科学地分配流量比例，这个比例是分析出来的而不是拍脑袋的。可以想象，阿里大促的流量不可能全部最后都走到付款流程，必然很多流量会在前面的流程就结束了，也就意味着，你把全部压测数据都构造成【走到付款场景】的话，你的压测结果是不准确的。