本篇文章为你整理了【手把手】光说不练假把式，这篇全链路压测实践探索（全链路压测四个关键点）的详细内容，包含有全链路压测技术 架构 全链路压测四个关键点 全链路压测是什么意思 takin全链路压测 【手把手】光说不练假把式，这篇全链路压测实践探索，希望能帮助你了解 【手把手】光说不练假把式，这篇全链路压测实践探索。

　　Hello，大家好呀，前两篇文章，我们说了下关于全链路压测的意义、整体架构，以及5种压测的方案。

　　前面两篇基本都属于比较理论的内容，今天这篇咱们来点实践的东西，手把手带你搞出一个压测来

　　如果不清楚之前两篇的文章的小伙伴，可以先看下，在这里

　　7 环境准备

　　7.1 环境服务列表

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

　　
我们的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 初始化数据

　　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-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 性能剖析

　　服务：需要分析的服务

　　端点：链路监控中端点的名称，可以再链路追踪中查看端点名称

　　监控时间：采集数据的开始时间

　　监控持续时间：监控采集多长时间

　　起始监控时间：多少秒后进行采集

　　监控间隔：多少秒采集一次

　　最大采集数：最大采集多少样本

　　本文由传智教育博学谷教研团队发布。

　　如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。

　　转载请注明出处！

　　以上就是【手把手】光说不练假把式，这篇全链路压测实践探索（全链路压测四个关键点）的详细内容，想要了解更多 【手把手】光说不练假把式，这篇全链路压测实践探索的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。