【手把手】光說不練假把式,這篇全鏈路壓測實踐探索
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 效能剖析
- 服務:需要分析的服務
- 端點:鏈路監控中端點的名稱,可以再鏈路追蹤中檢視端點名稱
- 監控時間:採集資料的開始時間
- 監控持續時間:監控採集多長時間
- 起始監控時間:多少秒後進行採集
- 監控間隔:多少秒採集一次
- 最大采集數:最大采集多少樣本
檢視監控結果
如果本文對您有幫助,歡迎 關注
和 點贊
`,您的支援是我堅持創作的動力。
轉載請註明出處!
「其他文章」
- 天翼雲全場景業務無縫替換至國產原生作業系統CTyunOS!
- 以羊了個羊為例,淺談小程式抓包與響應報文修改
- 這幾種常見的 JVM 調優場景,你知道嗎?
- 如此狂妄,自稱高效能佇列的Disruptor有啥來頭?
- 為什麼要學習GoF設計模式?
- 827. 最大人工島 : 簡單「並查集 列舉」運用題
- 手把手教你如何使用 Timestream 實現物聯網時序資料儲存和分析
- 850. 矩形面積 II : 掃描線模板題
- Java 併發程式設計解析 | 基於JDK原始碼解析Java領域中的併發鎖,我們可以從中學習到什麼內容?
- 【手把手】光說不練假把式,這篇全鏈路壓測實踐探索
- 大廠鍾愛的全鏈路壓測有什麼意義?四種壓測方案詳細對比分析
- 寫個續集,填坑來了!關於“Thread.sleep(0)這一行‘看似無用’的程式碼”裡面留下的坑。
- 857. 僱傭 K 名工人的最低成本 : 列舉 優先佇列(堆)運用題
- Vue3 實現一個自定義toast(小彈窗)
- 669. 修剪二叉搜尋樹 : 常規樹的遍歷與二叉樹性質
- 讀完 RocketMQ 原始碼,我學會了如何優雅的建立執行緒
- 效能調優——小小的log大大的坑
- 1582. 二進位制矩陣中的特殊位置 : 簡單模擬題
- elementui原始碼學習之仿寫一個el-switch
- 646. 最長數對鏈 : 常規貪心 DP 運用題