DevOps架構下如何進行微服務性能測試？

一. 微服務架構下的性能測試挑戰

微服務與DevOps

微服務是實現DevOps的重要架構

1. 微服務3S原則
   

2. DevOps核心點
   

 

微服務架構下的業務特色

• 億級用戶的平臺
• 單服務業務隨時擴容
• 服務之間存在相互調用關係
• 版本更新快，上線週期短

微服務架構下的性能測試挑戰

單服務流量激增時擴容
調用鏈條變長，調用關係更加複雜
微服務拆分致使故障點增多
▼ ▼ ▼
單服務變動性能影響如何評估？
性能瓶頸在各微服務間漂移，如何作好性能測試？
應對突發流量需求，擴容可否解決問題，如何擴容？
服務實例數量衆多，如何收集信息，快速定位性能問題？

 

二. 微服務性能保障解決方案設計

 

性能測試平臺服務化

 

性能測試服務架構

• 關鍵設計1：模塊化管理，事務靈活組合與複用
  

• 關鍵設計2：應用與資源一體化編排
  雲性能測試服務：https://www.huaweicloud.com/product/cpts.html
  

三. 性能測試實施策略

 

分層開展微服務性能測試

1. 單服務接口測試（契約）
   驗證單服務的各個接口能力基線以及組合接口的能力基線，服務間遵循契約化原則，大部分問題屏蔽在集成以前
2. 全鏈路測試（SLA）
   驗證整個系統之上全鏈路場景以及多鏈路組合場景的性能，優化鏈路中性能不足的服務
3. 伸縮能力驗證（面向現網運維）
   驗證單服務的水平擴容能力，驗證既定模型下的多鏈路組合場景的資源模型

系統從開發到上線須要作哪些測試

在微服務架構下，自動化仍然是提高效率，看護質量的重要手段，每一個微服務獨立快速迭代上線，更加要求微服務的性能不劣化

按部就班的性能測試執行

常見微服務性能問題測試結果分析

• 存在部分響應超時：
  a) 服務器繁忙,如某個服務節點CPU利用率高
  b) 網絡IO超過VM/EIP帶寬
  c) 等待後端微服務、數據庫的超時時間設置過長
• TPS未隨着併發數增加而上升：
  a) 系統性能到達瓶頸，持續併發加壓過程當中響應時延增長（可觀察響應區間統計）
  b) 可經過進一步加壓是否會出現非正常響應驗證
• 運行一段時間後所有響應超時或者檢查點校驗不經過：
  a) 大壓力致使系統中某個微服務奔潰
  b) 後端數據庫無響應
• TP90響應時延較短，TP99時延高：
  a) 系統性能接近瓶頸
  b) 可經過進一步加壓是否會出現非正常響應驗證

常見的微服務性能優化手段

1. 擴容：鏈路中的某一應用可能出現cpu使用率較高或者鏈接池資源不夠用(rpc、jdbc、redis鏈接池等)但自己對於拿到鏈接的請求處理又很快，這一類須要橫向擴展資源。
2. 應用邏輯優化：好比存在慢sql、 邏輯的不合理如調用db或者redis次數過多、沒有作讀寫分離形成寫庫壓力過大。
3. 超時時間的合理設置：對於應用之間的rpc調用或者應用與其餘基礎組件之間的調用，均須要設置合理的超時時間，不然過長的等待將形成整個鏈路的故障。
4. 緩存的應用：請求儘量從前端返回，而不是每個都要讓後端應用處理後再返回，減輕後端應用及數據庫壓力，提升系統吞吐能力。
5. 限流：對於超出承載能力的QPS或併發，能夠進行攔截並直接返回提示頁面。
6. 降級：對於非核心鏈路上的應用，容許故障關閉而不影響核心鏈路。