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.17.4 初始化数据
- 初始化用户数据以及产品数据
将feign,hystrix,ribbon等对立配置配置到nacos
# 配置超时工夫feign: hystrix: enabled: true #开启熔断 httpclient: enabled: truehystrix: threadpool: default: coreSize: 50 maxQueueSize: 1500 queueSizeRejectionThreshold: 1000 command: default: execution: timeout: enabled: true isolation: thread: timeoutInMilliseconds: 60000ribbon: ConnectTimeout: 10000 ReadTimeout: 50000
8 全链路压测测试
8.1 jmeter配置
配置好压测数据，并且配置压测线程数1000 进行10轮压测
8.2 第一轮压测
8.2.1 链路剖析优化
咱们找到一个调用时长1S左右的链路，剖析发现在存储服务调用时，耗时较长，然而数据库调用耗时并不长，根本阐明是存储服务的连接池耗尽导致调用过长。
8.2.2 数据库连接池优化
调整存储服务的连接池，由原来的最大10 改为100
initialSize: 10minIdle: 20maxActive: 1008.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 性能分析
- 服务：须要剖析的服务
- 端点：链路监控中端点的名称，能够再链路追踪中查看端点名称
- 监控工夫：采集数据的开始工夫
- 监控持续时间：监控采集多长时间
- 起始监控工夫：多少秒后进行采集
- 监控距离：多少秒采集一次
- 最大采集数：最大采集多少样本
查看监控后果
本文参加了思否技术征文，欢送正在浏览的你也退出。
如果本文对您有帮忙，欢送
关注和点赞`，您的反对是我保持创作的能源。转载请注明出处！