【手把手】光説不練假把式，這篇全鏈路壓測實踐探索

語言: CN / TW / HK

時間 2022-09-15 13:28:23 SegmentFault博客

主題: 全鏈路追蹤 MySQL

Hello，大家好呀，前兩篇文章，我們説了下關於全鏈路壓測的意義、整體架構，以及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 初始化數據

初始化用户數據以及產品數據

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

服務：需要分析的服務
端點：鏈路監控中端點的名稱，可以再鏈路追蹤中查看端點名稱
監控時間：採集數據的開始時間
監控持續時間：監控採集多長時間
起始監控時間：多少秒後進行採集
監控間隔：多少秒採集一次
最大采集數：最大采集多少樣本

查看監控結果

如果本文對您有幫助，歡迎 關注 和 點贊 `，您的支持是我堅持創作的動力。

轉載請註明出處！

「其他文章」