SpringCloud 應用在 Kubernetes 上的最佳實踐 — 高可用（容量評估）

前言

本文是《SpringCloud 應用在 Kubernetes 上的最佳實踐》的第11期，從前面兩期開始我們進入到了高可用專題，分別介紹了流量防護和故障演練相關內容。本文將從另一個視角介紹如何保障業務高可用性：即業務準備階段，提前進行線上的瓶頸定位和容量評估，以便更低成本、更高效/真實的發現系統瓶頸點，做到最精確的容量評估。

高可用體系介紹

首先來介紹下高可用體系，應用生命週期的高可用都有哪些策略、分別可以實現什麼能力呢？

從上圖示意中可以看出，應用生命週期的整個過程中，都有響應的高可用策略，如前面2期介紹的流量防護即為線上運行時的線上管控相關策略，混沌工程即為系統演練的相關策略。而全鏈路壓測即為規劃階段的重要策略，其包括線上壓測（即環境選擇）、容量規劃（即壓測實施）、彈性伸縮（即生態內聯動）。
以下將重點介紹容量評估的重要性，以及如何實施壓測來實現容量評估。

為何要進行容量評估

關於容量評估的重要性及必要性已經是個老生常談的問題了，分別從技術角度和業務戰略角度總結如下：

容量評估的目的自然是解決容量問題，如新業務上線前的準備，大型營銷活動的準備等等。大型活動中洪峰流量引起的系統表現不確定性，是最經典的適用場景。一個理想的營銷活動週期應該是有如下閉環流程：

性能測試是容量評估的核心手段，性能測試之後通過客戶端-應用系統-基礎負載一系列的監控分析，最終可得出瓶頸點位於何處、應如何有針對性的優化。上圖可以看出，性能測試通過真實、高效的壓測方式進行容量評估/瓶頸定位&解決，最終來保障活動穩定進行。

如何進行性能測試

阿里巴巴全鏈路壓測從2013年到現在也已經是第7個年頭了，在這7年中間我們不斷的積累、總結、優化進步，進行這樣一種大規模的項目活動，離不開有效的流程把控及分工管理。關於全鏈路壓測的前期準備，這邊將不做贅述，有興趣的同學可以參考文章《獨家揭祕 | 阿里巴巴是如何做全鏈路壓測的？》。以下將重點介紹壓測執行階段操作。
進行全鏈路壓測之前，單應用會進行內部壓測，以便能提升全鏈路壓測的效率，即解決內部問題之後再解決聯動問題。故以下將分別介紹Spring Cloud應用的壓測以及全鏈路壓測分別如何執行。

單應用壓測Spring Cloud應用

單應用的壓測不少開發者會選擇開源JMeter進行壓測，甚至還會進行自建平臺以便實現高併發能力。這兩者都不推薦，他們都有較為明顯的劣勢。阿里雲性能測試服務（PTS Performance Testing Service）提供了雲端壓測服務，其完美兼容了JMeter，只需把腳本上傳上來即可發起壓測。

同時，目前PTS上已經支持直接進行微服務壓測，不需要自己設置進行插件管理和升級，只需直接在PTS中選擇對應的集群等信息，即可快速發起壓測。

全鏈路壓測

如前面介紹性能壓測流程中所屬，整個全鏈路壓測包括的前期事宜較多，如環境選擇與改造、數據準備、安全策略等，這部分內容在此不做贅述，有興趣的可以查閱《Performance Test Together》主題相關介紹。本處主要介紹全鏈路壓測的實施：即配置與線上業務模型一樣的業務場景，從公網發起真實流量進行多維度和場景的壓測，驗證容量能力和瓶頸問題的定位。
一般正式壓測會按照壓測計劃，執行多種壓測策略。淘寶的雙11大促壓測，一般包含這樣幾步：

峰值脈衝
即完全模擬0點大促目標峰值流量，進行大促態壓測，觀察系統表現。
系統摸高
取消限流降級保護功能，抬高當前壓測值（前提是當前的目標壓測值已經達到，則可以進行摸高測試），觀察系統的極限值是多少。可進行多輪提升壓力值壓測，直到系統出現異常為止。簡化摸高測試的提升信息
限流降級驗證
顧名思義，即驗證限流降級保護功能是否正常。修改限流降級的作用與驗證方法，更簡化。（AHAS引入）商業化產品AHAS(應用高可用服務，Application High Availability Service）提供了全面的限流降級能力，可進行全鏈路的降級保護。
破壞性測試
這個主要是為了驗證預案的有效性，類似於容災演練時的預案執行演練。即為持續保持大促態壓測，並驗證預案的有效性，觀察執行預案之後對系統的影響。修改破壞性測試的內容。

在PTS上壓測

上述壓測場景的實施，均可以在PTS上操作實現，且配置不同的壓測量級數據，來進行多輪壓測，並觀察其系統表現。壓測不應該是一次性的操作，而應該是反覆的、多輪驗證的操作。以下以峰值脈衝為例，介紹如何在PTS上實施壓測。
首先是場景的構建。PTS提供了豐富的創建場景方式，包括JSON、JMX、YAML腳本的導入，純交互0編碼UI創建、雲端錄製器錄製結果導入、完美兼容JMeter腳本等。下圖作為示例：