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. 降級：對於非核心鏈路上的應用，允許故障關閉而不影響核心鏈路。