一. 微服務架構下的性能測試挑戰
微服務與DevOps
微服務是實現DevOps的重要架構
1.微服務3S原則
2.DevOps核心點
微服務架構下的業務特點
- 億級用戶的平臺
- 單服務業務隨時擴容
- 服務之間存在相互調用關係
- 版本更新快，上線週期短
微服務架構下的性能測試挑戰
單服務流量激增時擴容
調用鏈條變長，調用關係更加複雜
微服務拆分導致故障點增多
▼ ▼ ▼
單服務變更性能影響如何評估？
性能瓶頸在各微服務間漂移，如何做好性能測試？
應對突發流量需求，擴容能否解決問題，如何擴容？
服務實例數量衆多，如何收集信息，快速定位性能問題？
二. 微服務性能保障解決方案設計
性能測試平臺服務化
性能測試服務架構
- 關鍵設計1：模塊化管理，事務靈活組合與複用
- 關鍵設計2：應用與資源一體化編排
雲性能測試服務：https://www.huaweicloud.com/product/cpts.html
三. 性能測試實施策略
分層開展微服務性能測試
- 單服務接口測試（契約）
驗證單服務的各個接口能力基線以及組合接口的能力基線，服務間遵循契約化原則，大部分問題屏蔽在集成之前 - 全鏈路測試（SLA）
驗證整個系統之上全鏈路場景以及多鏈路組合場景的性能，優化鏈路中性能不足的服務 - 伸縮能力驗證（面向現網運維）
驗證單服務的水平擴容能力，驗證既定模型下的多鏈路組合場景的資源模型
系統從開發到上線需要做哪些測試
在微服務架構下，自動化仍然是提升效率，看護質量的重要手段，每個微服務獨立快速迭代上線，更加要求微服務的性能不劣化
循序漸進的性能測試執行
常見微服務性能問題測試結果分析
-
存在部分響應超時：
a) 服務器繁忙,如某個服務節點CPU利用率高
b) 網絡IO超過VM/EIP帶寬
c) 等待後端微服務、數據庫的超時時間設置過長 -
TPS未隨着併發數增長而上升：
a) 系統性能到達瓶頸，持續併發加壓過程中響應時延增加（可觀察響應區間統計）
b) 可通過進一步加壓是否會出現非正常響應驗證 -
運行一段時間後全部響應超時或者檢查點校驗不通過：
a) 大壓力導致系統中某個微服務奔潰
b) 後端數據庫無響應 - TP90響應時延較短，TP99時延高：
a) 系統性能接近瓶頸
b) 可通過進一步加壓是否會出現非正常響應驗證
常見的微服務性能優化手段
- 擴容：鏈路中的某一應用可能出現cpu使用率較高或者連接池資源不夠用(rpc、jdbc、redis連接池等)但本身對於拿到連接的請求處理又很快，這一類需要橫向擴展資源。
- 應用邏輯優化：比如存在慢sql、 邏輯的不合理如調用db或者redis次數過多、沒有做讀寫分離造成寫庫壓力過大。
- 超時時間的合理設置：對於應用之間的rpc調用或者應用與其他基礎組件之間的調用，均需要設置合理的超時時間，否則過長的等待將造成整個鏈路的故障。
- 緩存的應用：請求儘可能從前端返回，而不是每一個都要讓後端應用處理後再返回，減輕後端應用及數據庫壓力，提高系統吞吐能力。
- 限流：對於超出承載能力的QPS或併發，可以進行攔截並直接返回提示頁面。
- 降級：對於非核心鏈路上的應用，允許故障關閉而不影響核心鏈路。