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

語言: 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 效能剖析

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

檢視監控結果

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

轉載請註明出處！

「其他文章」