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

Hello，大家好呀，前兩篇文章，我們說了下關于全鏈路壓測的意義、整體架構，以及5種壓測的方案，

前面兩篇基本都屬于比較理論的內容，今天這篇咱們來點實踐的東西，手把手帶你搞出一個壓測來

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

7 環境準備

7.1 環境服務串列

需要在虛擬機或者linux服務器啟動運行環境

7.2 應用服務串列

應用服務可以單獨部署或者在idea中啟動

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 初始化資料

1. 初始化用戶資料以及產品資料

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

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

查看監控結果

本文由傳智教育博學谷教研團隊發布，

如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力，

轉載請注明出處！

標籤：其他

上一篇：變數與資料型別

下一篇：關于多工序、多資源排程場景下的新成果