【手把手】光说不练假把式，这篇全链路压测实践探索 ...

Hello，大家好呀，前两篇文章，我们说了下关于全链路压测的意义、整体架构，以及5种压测的方案。
前面两篇基本都属于比较理论的内容，今天这篇咱们来点实践的东西，手把手带你搞出一个压测来
如果不清楚之前两篇的文章的小伙伴，可以先看下，在这里
7 环境准备

7.1 环境服务列表

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

服务ip端口备注mysql172.18.0.103306数据库服务rabbitMQ172.18.0.205672,5672RabbitMQ消息服务redis172.18.0.306379Redis缓存服务nacos172.18.0.408848微服务注册中心skywalking172.18.0.501234,11800,12800链路追踪APM服务端skywalking-ui172.18.0.608080链路追踪APM服务UI端7.2 应用服务列表

应用服务可以单独部署或者在idea中启动

服务ip端口备注order-service127.0.0.18001订单服务account-service127.0.0.18002账户服务storage-service127.0.0.18003数据存储服务notice-service127.0.0.18004通知服务7.3 docker-compose 编排环境

我们的docker-compose只对环境进行了搭建，具体微服务在本地运行或者在容器运行都可以。

1. version: '2'
2. services:
3.     mysql:
4.         image: mysql:5.7
5.         hostname: mysql
6.         container_name: mysql
7.         networks:
8.             docker-network:
9.                 ipv4_address: 172.18.0.10
10.         ports:
11.             - "3306:3306"
12.         environment:
13.             MYSQL_ROOT_PASSWORD: root
14.         volumes:
15.             - "/tmp/etc/mysql:/etc/mysql/conf.d"
16.             - "/tmp/data/mysql:/var/lib/mysql"
17.     rabbitMQ:
18.         image: rabbitmq:management
19.         hostname: rabbitMQ
20.         container_name: rabbitMQ
21.         networks:
22.             docker-network:
23.                 ipv4_address: 172.18.0.20
24.         ports:
25.             - "5672:5672"
26.             - "15672:15672"
27.     redis:
28.         image: redis
29.         hostname: redis
30.         container_name: redis
31.         networks:
32.             docker-network:
33.                 ipv4_address: 172.18.0.30
34.         ports:
35.             - "6379:6379"
36.         volumes:
37.             - "/tmp/etc/redis/redis.conf:/etc/redis/redis.conf"
38.             - "/tmp/data/redis:/data"
39.         command:
40.            redis-server /etc/redis/redis.conf
41.     nacos:
42.         image: nacos/nacos-server
43.         hostname: nacos
44.         container_name: nacos
45.         depends_on:
46.             - mysql
47.         networks:
48.             docker-network:
49.                 ipv4_address: 172.18.0.40
50.         ports:
51.            - "8848:8848"
52.         environment:
53.             MODE: standalone
54.         volumes:
55.             - "/tmp/etc/nacos/application.properties:/home/nacos/conf/application.properties"
56.     skywalking:
57.         image: apache/skywalking-oap-server
58.         hostname: skywalking
59.         container_name: skywalking
60.         networks:
61.             docker-network:
62.                 ipv4_address: 172.18.0.50
63.         ports:
64.            - "1234:1234"
65.            - "11800:11800"
66.            - "12800:12800"
67.     skywalkingui:
68.         image: apache/skywalking-ui
69.         hostname: skywalkingui
70.         container_name: skywalkingui
71.         depends_on:
72.             - skywalking
73.         networks:
74.             docker-network:
75.                 ipv4_address: 172.18.0.60
76.         environment:
77.             SW_OAP_ADDRESS: 172.18.0.50:12800
78.         ports:
79.            - "8080:8080"
80. networks:
81.     docker-network:
82.         ipam:
83.             config:
84.                 - subnet: 172.18.0.0/16
85.                   gateway: 172.18.0.1

复制代码

7.4 初始化数据

• 初始化用户数据以及产品数据
  
• 将feign,hystrix,ribbon等统一配置配置到nacos
  1. # 配置超时时间
  2. feign:
  3.   hystrix:
  4.     enabled: true  #开启熔断
  5.   httpclient:
  6.     enabled: true
  7. hystrix:
  8.   threadpool:
  9.     default:
  10.       coreSize: 50
  11.       maxQueueSize: 1500
  12.       queueSizeRejectionThreshold: 1000
  13.   command:
  14.     default:
  15.       execution:
  16.         timeout:
  17.           enabled: true
  18.         isolation:
  19.           thread:
  20.             timeoutInMilliseconds: 60000
  21. ribbon:
  22.   ConnectTimeout: 10000
  23.   ReadTimeout: 50000

  复制代码

8 全链路压测测试

8.1 jmeter配置

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

8.2 第一轮压测

8.2.1 链路分析优化

我们找到一个调用时长1S左右的链路，分析发现在存储服务调用时，耗时较长，但是数据库调用耗时并不长，基本说明是存储服务的连接池耗尽导致调用过长。

8.2.2 数据库连接池优化

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

1. initialSize: 10
2. minIdle: 20
3. maxActive: 100

复制代码

8.3 第二轮压测

结果已经由原来的服务内部的耗时 变为了fegin的耗时，这种情况下可以考虑使用fegin的连接池优化或者新增节点

8.3.1 观察消费节点

发现消费速度很慢，产生了大量消息堆积

检查storage-service的actualPlaceOrder端点信息

发现平均响应时间在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 性能剖析

• 服务：需要分析的服务
  
• 端点：链路监控中端点的名称，可以再链路追踪中查看端点名称
  
• 监控时间：采集数据的开始时间
  
• 监控持续时间：监控采集多长时间
  
• 起始监控时间：多少秒后进行采集
  
• 监控间隔：多少秒采集一次
  
• 最大采集数：最大采集多少样本
  

查看监控结果

本文由传智教育博学谷教研团队发布。
如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。
转载请注明出处！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！