乐趣区

关于java:手把手光说不练假把式这篇全链路压测实践探索

Hello,大家好呀,前两篇文章,咱们说了下对于全链路压测的意义、整体架构,以及 5 种压测的计划。

后面两篇根本都属于比拟实践的内容,明天这篇咱们来点实际的货色,手把手带你搞出一个压测来

如果不分明之前两篇的文章的小伙伴,能够先看下,在这里

  • 大厂钟爱的全链路压测有什么意义?四种压测计划具体比照剖析
  • 【代码级】全链路压测的整体架构设计,以及 5 种实现计划

7 环境筹备

7.1 环境服务列表

须要在虚拟机或者 linux 服务器启动运行环境

服务 ip 端口 备注
mysql 172.18.0.10 3306 数据库服务
rabbitMQ 172.18.0.20 5672,5672 RabbitMQ 音讯服务
redis 172.18.0.30 6379 Redis 缓存服务
nacos 172.18.0.40 8848 微服务注册核心
skywalking 172.18.0.50 1234,11800,12800 链路追踪 APM 服务端
skywalking-ui 172.18.0.60 8080 链路追踪 APM 服务 UI 端

7.2 应用服务列表

应用服务能够独自部署或者在 idea 中启动

服务 ip 端口 备注
order-service 127.0.0.1 8001 订单服务
account-service 127.0.0.1 8002 账户服务
storage-service 127.0.0.1 8003 数据存储服务
notice-service 127.0.0.1 8004 告诉服务

7.3 docker-compose 编排环境

咱们的 docker-compose 只对环境进行了搭建,具体微服务在本地运行或者在容器运行都能够。

version: '2'
services:
    mysql:
        image: mysql:5.7
        hostname: mysql
        container_name: mysql
        networks:
            docker-network:
                ipv4_address: 172.18.0.10
        ports:
            - "3306:3306"
        environment:
            MYSQL_ROOT_PASSWORD: root
        volumes:
            - "/tmp/etc/mysql:/etc/mysql/conf.d"
            - "/tmp/data/mysql:/var/lib/mysql"
    rabbitMQ:
        image: rabbitmq:management
        hostname: rabbitMQ
        container_name: rabbitMQ
        networks:
            docker-network:
                ipv4_address: 172.18.0.20
        ports:
            - "5672:5672"
            - "15672:15672"
    redis:
        image: redis
        hostname: redis
        container_name: redis
        networks:
            docker-network:
                ipv4_address: 172.18.0.30
        ports:
            - "6379:6379"
        volumes:
            - "/tmp/etc/redis/redis.conf:/etc/redis/redis.conf"
            - "/tmp/data/redis:/data"
        command:
           redis-server /etc/redis/redis.conf
    nacos:
        image: nacos/nacos-server
        hostname: nacos
        container_name: nacos
        depends_on:
            - mysql
        networks:
            docker-network:
                ipv4_address: 172.18.0.40
        ports:
           - "8848:8848"
        environment:
            MODE: standalone
        volumes:
            - "/tmp/etc/nacos/application.properties:/home/nacos/conf/application.properties"
    skywalking:
        image: apache/skywalking-oap-server
        hostname: skywalking
        container_name: skywalking
        networks:
            docker-network:
                ipv4_address: 172.18.0.50
        ports:
           - "1234:1234"
           - "11800:11800"
           - "12800:12800"
    skywalkingui:
        image: apache/skywalking-ui
        hostname: skywalkingui
        container_name: skywalkingui
        depends_on:
            - skywalking
        networks:
            docker-network:
                ipv4_address: 172.18.0.60
        environment:
            SW_OAP_ADDRESS: 172.18.0.50:12800
        ports:
           - "8080:8080"
networks:
    docker-network:
        ipam:
            config:
                - subnet: 172.18.0.0/16
                  gateway: 172.18.0.1

7.4 初始化数据

  1. 初始化用户数据以及产品数据
  2. 将 feign,hystrix,ribbon 等对立配置配置到 nacos

    # 配置超时工夫
    feign:
      hystrix:
        enabled: true  #开启熔断
      httpclient:
        enabled: true
    hystrix:
      threadpool:
        default:
          coreSize: 50
          maxQueueSize: 1500
          queueSizeRejectionThreshold: 1000
      command:
        default:
          execution:
            timeout:
              enabled: true
            isolation:
              thread:
                timeoutInMilliseconds: 60000
    ribbon:
      ConnectTimeout: 10000
      ReadTimeout: 50000

8 全链路压测测试

8.1 jmeter 配置

配置好压测数据,并且配置压测线程数 1000 进行 10 轮压测

8.2 第一轮压测

8.2.1 链路剖析优化

咱们找到一个调用时长 1S 左右的链路,剖析发现在存储服务调用时,耗时较长,然而数据库调用耗时并不长,根本阐明是存储服务的连接池耗尽导致调用过长。

8.2.2 数据库连接池优化

调整存储服务的连接池,由原来的最大 10 改为 100

initialSize: 10
minIdle: 20
maxActive: 100

8.3 第二轮压测

后果曾经由原来的服务外部的耗时 变为了 fegin 的耗时,这种状况下能够思考应用 fegin 的连接池优化或者新增节点

8.3.1 察看生产节点

发现生产速度很慢,产生了大量音讯沉积

查看 storage-serviceactualPlaceOrder端点信息

发现均匀响应工夫在 200ms 左右

查看断点链路/storage/order/actualPlaceOrder

发现是事务提交慢造成的,这个时候就须要优化 mysql 服务器了

9 Skywalking 应用

9.1 Skywalking 模块栏目

Skywalking web UI 次要包含如下几个大的功能模块:

  • 仪表盘:查看被监控服务的运行状态
  • 拓扑图:以拓扑图的形式展示服务间接的关系,并以此为入口查看相干信息
  • 追踪:以接口列表的形式展示,追踪接口外部调用过程
  • 性能分析:独自端点进行采样剖析,并可查看堆栈信息
  • 告警:触发告警的告警列表,包含实例,申请超时等。
  • 主动刷新:刷新以后数据内容。

9.2 仪表盘

  • 第一栏:不同内容主题的监控面板,利用 / 数据库 / 容器等
  • 第二栏:操作,包含编辑 / 导出以后数据 / 倒入展现数据 / 不同服务端点筛选展现
  • 第三栏:不同纬度展现,服务 / 实例 / 端点

9.3 展现栏

9.3.1 Global 全局维度
  • 第一栏:Global、Server、Instance、Endpoint 不同展现面板,能够调整外部内容
  • Services load:服务每分钟申请数
  • Slow Services:慢响应服务,单位 ms
  • Un-Health services(Apdex):Apdex 性能指标,1 为满分。
  • Global Response Latency:百分比响应延时,不同百分比的延时工夫,单位 ms
  • Global Heatmap:服务响应工夫热力分布图,依据时间段内不同响应工夫的数量显示色彩深度
  • 底部栏:展现数据的工夫区间,点击能够调整。
9.3.2 Service 服务维度
  • Service Apdex(数字): 以后服务的评分
  • Service Apdex(折线图):不同工夫的 Apdex 评分
  • Successful Rate(数字):申请成功率
  • Successful Rate(折线图):不同工夫的申请成功率
  • Servce Load(数字):每分钟申请数
  • Servce Load(折线图):不同工夫的每分钟申请数
  • Service Avg Response Times:均匀响应延时,单位 ms
  • Global Response Time Percentile:百分比响应延时
  • Servce Instances Load:每个服务实例的每分钟申请数
  • Show Service Instance:每个服务实例的最大延时
  • Service Instance Successful Rate:每个服务实例的申请成功率
9.3.3 Instance 实例维度
  • Service Instance Load:以后实例的每分钟申请数
  • Service Instance Successful Rate:以后实例的申请成功率
  • Service Instance Latency:以后实例的响应延时
  • JVM CPU:jvm 占用 CPU 的百分比
  • JVM Memory:JVM 内存占用大小,单位 m
  • JVM GC Time:JVM 垃圾回收工夫,蕴含 YGC 和 OGC
  • JVM GC Count:JVM 垃圾回收次数,蕴含 YGC 和 OGC
  • CLR XX:相似 JVM 虚拟机,这里用不上就不做解释了
9.3.4 Endpoint 端点(API)维度
  • Endpoint Load in Current Service:每个端点的每分钟申请数
  • Slow Endpoints in Current Service:每个端点的最慢申请工夫,单位 ms
  • Successful Rate in Current Service:每个端点的申请成功率
  • Endpoint Load:以后端点每个时间段的申请数据
  • Endpoint Avg Response Time:以后端点每个时间段的申请行响应工夫
  • Endpoint Response Time Percentile:以后端点每个时间段的响应工夫占比
  • Endpoint Successful Rate:以后端点每个时间段的申请成功率

9.4 拓扑图

  • 1:抉择不同的服务关联拓扑
  • 2:查看单个服务相干内容
  • 3:服务间连接状况
  • 4:分组展现服务拓扑

9.5 追踪

  • 左侧:api 接口列表,红色 - 异样申请,蓝色 - 失常申请
  • 右侧:api 追踪列表,api 申请连贯各端点的先后顺序和工夫

9.6 性能分析

  • 服务:须要剖析的服务
  • 端点:链路监控中端点的名称,能够再链路追踪中查看端点名称
  • 监控工夫:采集数据的开始工夫
  • 监控持续时间:监控采集多长时间
  • 起始监控工夫:多少秒后进行采集
  • 监控距离:多少秒采集一次
  • 最大采集数:最大采集多少样本

查看监控后果

本文参加了思否技术征文,欢送正在浏览的你也退出。

如果本文对您有帮忙,欢送 关注 点赞`,您的反对是我保持创作的能源。

转载请注明出处!

退出移动版