穩定性是持久戰
2021 年 12 月的一天，AWS 的北弗吉尼亞（us-east-1）區域發生了一次令人震驚的服務中斷事故。隨著數以億計的使用者在社交媒體、購物平臺和影片流服務中陷入 “服務無法訪問” 的漩渦，世界彷彿按下了暫停鍵。後續報告顯示，這起事故的導火索是內部網路裝置的過載，而這正是效能瓶頸和未知故障交織作用的典型表現。對於使用者來說，這可能只是一兩個小時的等待，但對於背後的工程團隊而言，這是一場觸目驚心的 “看不見的戰爭”。
今天，隨著系統複雜性的飛速增長，微服務架構、異構部署和動態擴充套件讓 “穩定性” 變得愈加脆弱。效能瓶頸、服務依賴、鏈路超時等問題像幽靈般潛伏其中，稍有不慎，就會引發連鎖反應。正如 AWS 當機事故背後的反思所揭示的那樣，穩定性從來不是 “萬事大吉”，而是一場持續進行的攻防戰。
本篇文章我們將從故障注入和效能測試融合的角度，探討如何透過有效的服務依賴治理和混沌工程，構建經得起考驗的系統穩定性保障方案。在這場服務質量保衛戰中，唯有未雨綢繆、穩紮穩打，才能贏得最終勝利。
效能與故障的雙重挑戰
在分散式系統中，穩定性往往像走鋼絲一般驚心動魄。網路抖動、節點當機、服務級聯故障等問題，隨時可能打破系統的平衡。效能最佳化讓系統跑得更快，而故障注入則是檢測其在風浪中是否穩固。這兩者看似不同，卻如硬幣的兩面，缺一不可。
分散式系統的穩定性就像駕駛一輛高速賽車。效能是引擎的動力，推動賽車全速前進；而故障則是賽道上的突發障礙，可能是砂石、尖刺，甚至意外的撞擊。如果你只專注於動力，忽視對障礙的處理，車速越快，失控的後果越嚴重。同樣，如果賽車對障礙的反應過於保守，而忽略了速度的重要性，它也無法完成比賽目標。
分散式系統正處於這樣的 “高速賽道” 上：
- 網路抖動是突然出現在彎道的沙礫，可能導致短暫的滑行或延遲；
- 服務級聯故障是意外的連環撞車，任何一個節點的失敗都可能觸發整條鏈路的癱瘓；
- 負載激增則像突然湧入賽道的車輛，壓力過大可能直接導致系統崩潰。
在這樣的背景下，僅關注效能最佳化或故障注入，都會留下隱患。唯有將兩者融合，才能確保系統在高效執行的同時，能夠從容應對未知的威脅。
透過效能測試識別瓶頸，我們能提升 “賽車引擎” 的動力，而故障測試則是模擬各種極端場景，確保 “賽車底盤” 和 “剎車系統” 足夠可靠。融合這些手段，可以讓分散式系統在面對高速發展和不可預測的故障時，既快又穩，從而避免 “速度和穩定性” 的兩難困境。
效能測試與故障測試的獨特價值
效能測試和故障測試是系統穩定性保障中的兩種關鍵手段，各自有著明確的目標和應用場景。一個關注“跑得多快”，另一個關注“還能跑多久”，它們從不同的角度切入，共同守護系統的平穩執行。
效能測試：速度有多快
效能測試的重點在於系統在正常執行中的高效性和承載能力。它像是一次 “速度賽”：測量引擎的馬力、油耗和速度極限，確保在業務增長時，系統的響應時間和吞吐量能夠滿足需求。
關注點：
- 吞吐量：每秒能處理多少請求？
- 響應時間：使用者發起請求後多久能收到響應？
- 資源利用率：CPU、記憶體、網路等是否高效工作？
- 容量規劃：系統的擴充套件性如何，什麼時候需要加速 “引擎” 或升級 “跑道”？
測試場景：
- 模擬流量激增，驗證系統在高併發時是否會崩潰。
- 執行復雜查詢，測量資料庫在大資料量處理下的響應速度。
- 對比多種配置，評估最佳化方案是否提升了效能。
故障測試：突然剎車還能跑多遠
故障測試則是對系統承受異常能力的檢驗，像在高速行駛時模擬 “急剎車”。它關注的是系統在發生問題時能否從容應對，恢復執行，避免全面崩潰。
關注點：
- 單點故障：關鍵元件或節點失效會產生多大影響？
- 服務降級：系統能否在壓力下優雅地削減非核心功能？
- 恢復能力：在斷電、當機等極端情況下，多久能夠恢復？
- 級聯效應：一個小問題是否會迅速蔓延至整個系統？
測試場景：
- 人為關閉一個微服務例項，觀察流量切換是否平穩。
- 模擬網路延遲或分割槽，驗證系統在惡劣網路環境下的表現。
- 在高負載下突然引入錯誤，測試系統是否能優雅降級。
互為補充：快與穩的完美平衡
效能測試確保系統 “跑得快”，是系統的動力基礎；故障測試驗證系統 “剎得住”，是穩定性的最後屏障。只有將兩者結合，才能讓分散式系統在面對真實世界的挑戰時，既能 “極速前進”，又能 “穩如泰山”。
效能測試與故障測試的交集
效能測試和故障測試雖然各自關注不同的場景和指標，但它們在某些核心領域上卻有交集。透過下圖我們可以清晰地展示兩者的共同關注點。
| 效能測試 | 故障測試 | 交集 |
|---|---|---|
| 延遲 | 測試系統在高負載下的響應時間 | 測試系統在異常狀態下的恢復時間 |
| 吞吐量 | 測試系統能夠處理多少請求 | 測試系統在負載異常時的流量分配 |
| 錯誤率 | 測試系統在正常情況下的錯誤率 | 測試系統在故障狀態下的錯誤率 |
| 資源利用率 | 測試系統對資源的利用效率 | 測試系統在故障時的資源分配 |
延遲
效能測試關注系統在正常執行下的響應時間和延遲，旨在確保系統能夠在高負載環境中保持快速的處理速度，避免使用者體驗的延遲過高。故障測試則關注系統在異常或故障狀態下的恢復時間，確保系統能夠在故障後儘快恢復正常執行，避免長時間的延遲影響使用者體驗。因此，延遲是系統穩定性中的關鍵指標，效能測試和故障測試都需關注它，以確保系統在正常和異常情況下的響應速度都保持在可接受的範圍內。
吞吐量
效能測試主要關注系統在正常執行下的處理能力，即系統能夠處理多少請求、使用者能獲取多少資源等。而故障測試則關注系統在故障狀態下的流量分配和資源使用，確保系統能夠在負載異常時合理分配資源，避免因資源瓶頸導致的效能問題。因此，吞吐量是效能測試和故障測試都關注的指標，二者共同確保系統在正常和異常情況下的資源利用效率。
錯誤率
效能測試通常評估系統在正常負載下的錯誤率，以確保系統在高效執行時儘可能減少錯誤。而故障測試則側重於系統在異常或故障狀態下的錯誤率，尤其關注故障恢復過程中是否產生更多錯誤。效能測試和故障測試在這個指標上都有交集，因為降低系統的錯誤率，尤其是在故障情況下的容錯能力，是系統穩定性和可用性的基礎。
資源利用率
效能測試關注系統在高負載環境下對資源的利用效率，如 CPU、記憶體、網路等資源使用情況，以避免資源瓶頸影響效能。而故障測試則關注系統在故障狀態下資源的分配和利用，確保系統能夠在異常情況下合理使用資源，避免資源浪費或過度使用引發的故障。因此，資源利用率是效能測試和故障測試共同關注的關鍵指標，二者協同推動系統在正常和故障狀態下的資源高效利用。
融合實踐
在微服務框架如 Kubernetes 環境下，效能測試和故障測試的融合可以透過具體的測試用例來實現，確保系統在高效執行和異常情況中的穩定性。以下是一些典型的融合測試用例：
高峰效能測試與節點故障模擬
在系統的高負載環境中進行效能測試時，模擬節點故障，觀察系統的服務恢復能力和資料複製延遲。
-
測試場景：
- 執行高併發流量測試，模擬大量使用者訪問。
- 隨機關閉一個 Kubernetes 節點，模擬節點故障。
- 檢測故障節點上服務的遷移和資料複製情況。
-
觀察指標：
- 資料複製延遲：檢查資料複製是否順暢，是否存在延遲或丟失。
- 服務穩定性：檢測系統在節點故障下的流量切換、服務降級和恢復時間。
故障恢復能力與吞吐量測試結合
在故障測試中，引入高負載流量，觀察系統在高負載與故障同時發生時的穩定性。
-
測試場景：
- 啟動故障注入，導致部分微服務不可用。
- 在高併發流量的壓力下，觀測系統的服務降級策略和恢復時間。
-
觀察指標：
- 吞吐量：在故障情況下，系統是否能維持較高的吞吐量，避免資源瓶頸。
- 服務恢復時間：故障後系統的恢復時間，確保儘快恢復穩定執行。
異常負載和資源利用測試
透過效能測試高負載和故障場景，驗證系統資源利用的合理性。
-
測試場景：
- 增大流量負載，模擬突發的資源使用壓力。
- 啟動節點故障，觀察系統資源在異常狀態下的利用情況。
-
觀察指標：
- 資源利用率：故障情況下，系統資源的分配是否均衡，避免過度消耗。
- 錯誤率：監測故障恢復過程中系統錯誤率，確保系統穩定性。
挑戰與應對
在實際工作中，可能會遇到以下挑戰和問題，這些問題影響了效能測試和故障測試的順利進行。以下是幾個常見問題及其實際應用場景和解決方案：
測試環境配置複雜，難以重現問題
實際場景：微服務架構中的環境配置繁雜，跨多個服務、節點和元件，導致測試場景難以完全重現，影響測試準確性。
解決方案：
- 容器化測試環境：使用 Docker 或 Kubernetes 進行環境隔離，確保每次測試都能在統一的環境下執行。
- 環境模板化：建立環境模板，保證每個測試環境都能快速啟動和配置，從而提高可複用性和穩定性。
實際應用：如微服務中的依賴版本不一致、網路配置複雜等問題，透過容器化環境可以有效隔離這些變數，確保測試環境的一致性和可復現性。
資源限制導致測試無法進行
實際場景：在高併發或大規模測試中，系統資源如 CPU、記憶體或網路頻寬可能不足，導致測試無法正常執行。
解決方案：
- 資源排程和擴縮容：使用 Kubernetes 自動擴縮容功能，根據測試負載動態調整節點數量，保障資源供應。
- 輕量化測試環境：只執行必要的服務和元件，減少測試時對資源的消耗。 實際應用：在微服務架構下，由於多個服務需要共用資源，可能導致瓶頸，透過容器化和資源排程機制來最佳化測試環境，確保測試時能高效使用有限資源。
測試用例複雜，執行成本高
實際場景：複雜的測試用例涉及大量節點、服務和依賴，執行成本高，難以快速迭代。
解決方案：
- 自動化測試工具：使用工具如 Jenkins、ArgoCD 等自動化部署和執行測試，用於批次化處理複雜用例。
- 微服務拆分和整合測試：將大規模測試用例拆分為小粒度的微測試，減少重複操作和提高複用性。 實際應用：如微服務架構中的整合測試和功能驗證，複雜場景下可以透過自動化部署和持續整合工具，提高測試效率，降低執行成本。
故障注入測試環境配置難度大
實際場景：在混沌工程中，故障注入測試涉及網路分割槽、節點故障等複雜環境配置，環境搭建和復現困難。
解決方案：
- 混沌工程工具：使用 Chaos Engineering 工具，如 LitmusChaos、Kubernetes 故障注入工具等，簡化故障注入配置。
- 服務網格支援：使用 Istio 等服務網格框架，簡化跨服務和跨節點的故障注入配置。 實際應用：如系統架構中引入故障測試，服務網格工具可以統一管理故障注入策略，提高測試的可操作性和復現性。
透過這些解決方案，可以有效應對資源限制、環境複雜和測試用例複雜等問題，提升效能測試和故障測試的效率和可行性。
FunTester 原創精華
【連載】從 Java 開始效能測試
- 混沌工程、故障測試、Web 前端
- 服務端功能測試
- 效能測試專題
- Java、Groovy、Go
- 白盒、工具、爬蟲、UI 自動化
- 理論、感悟、影片