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

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