技術交流羣看到這樣一個問題：服務部署方式改成了容器化，要根據業務場景和不同的參數配置進行性能摸底，找到最佳配置，性能測試該如何執行？看似很簡單的性能需求，其實難度並不低。
首先，容器化部署和常規的虛擬機/雲服務部署存在一定區別；其次，涉及到業務場景就需要考慮真實的業務模型和流量模型；
再次，在容器化部署的不同配置下性能表現的差異很大；最後，是滿足業務需求的最佳配置。其中還未考慮外部依賴的影響，以及如何應對線上突增流量的場景。
這篇文章，以這個需求爲案例，談談我的理解和實踐方法。
一分鐘快速瞭解容器化
容器化部署，簡單來說就是一種輕量的虛擬方法，將應用程序及其依賴項(包括操作系統)打包，使其可以便捷的跨平臺和系統運行。
目前大家熟知的Docker和Kubernetes，已經是十年前出現的技術了，而容器化相關的概念和小範圍實踐，可以追溯到1979年Linux系統的chroot調用方法。
容器化在服務部署和跨平臺應用方面，有很多方面的優勢，主要如下：
- 可擴展，可以有效地分配資源(共享操作系統內核，降低性能損失)。
- 可移植，構建一次在任何地方運行(基於宿主內核運行，在任何支持容器的操作系統上運行)。
- 速度快，共享主機操作系統內核，無需啓動完整操作系統，降低額外開銷，可以做到毫秒級啓動。
- 管理方便，可以快速的部署和管理應用程序，資源控制粒度更細，通過命名空間和控制組，靈活分配資源。
以本文開頭的問題爲例，我個人認爲針對該需求的性能測試可以按照如下方式開展。
第一步：確定業務和流量模型
既然是性能摸底，一般都會選擇一個典型的業務應用來做驗證。畢竟是性能測試，脫離實際的業務場景直接開展性能測試就顯得撿芝麻丟西瓜。
假設選擇了一個訂單應用，那這個應用的核心業務場景有創建訂單、訂單支付、訂單列表、訂單詳情等，根據要驗證的具體的業務場景，通過線上監控和歷史數據分析，得到一個相對準確的流量模型是很有必要的。
否則流量模型不對，那得到的性能數據也沒有太多的說服力，且壓測所需用到的測試數據也可能會不夠精準，最終導致測試結果南轅北轍。
關於業務模型、流量模型和數據模型，詳情請看：《構建三大模型》。
第二步：確定最佳性能預期指標
做性能測試很忌諱的一點就是先測試再定指標，這樣很容易導致重複的返工和拉扯。畢竟測試是個驗證的工作，沒有預期的指標就開展，就像拿着錘子去砸，砸到誰誰就是釘子一樣。
即使最開始沒有明確的性能指標，也要通過分析需求和溝通，確定幾個指標，這樣後續的測試活動開展才有方向。以本文開頭的問題爲例，可以從如下幾點來考慮制訂預期指標。
- 單pod的CPU使用率要限制在多少？
- 99%響應時間和平均響應時間在多少範圍內？
- pod的CPU核數是固定還是範圍內彈性？彈性範圍是多少？
- 單pod向集羣模式擴展，集羣的性能衰減係數要控制在多少？
通過以上幾點確定明確的指標，後續的測試活動開展才能有的放矢。
第三步：制訂詳細的性能測試任務
明確了業務和流量模型，有了明確的性能指標之後，接下來就是制訂詳細的性能測試任務。下面列舉幾個任務，便於大家更直觀的理解。
1、驗證單pod的極限性能
假設單pod固定配置爲2C4G，通過壓測得到該pod在CPU/memery使用率打滿情況下的性能表現。
2、驗證單pod的最優性能
假設單pod固定配置爲2C4G，CPU%必須<60%，通過壓測監控得到在CPU%<60%時對應的TPS/99RT(當然，也可以限制99RT的最大值，觀察pod的資源使用率)。
最優性能的定義一般需要具有這兩個特性：業務可接受+系統穩定性可接受。我們常提到的性能拐點，就是這個目的下的典型案例。
3、驗證固定配置下的集羣擴展能力
假設單pod固定配置爲2C4G，當CPU%>60%/ART>80ms時自動開始增加pod數量，通過壓測監控觀察擴容時是否存在異常，以及擴容後的性能表現是否和集羣數量的增加成正比例。
4、驗證彈性配置下的集羣擴展能力
假設單pod固定配置爲2C4G，當CPU%>60%/ART>80ms時自動開始提升pod配置(比如從2C4G升級到4G8G)，通過壓測監控觀察pod升配置時的性能變化是否正常，以及升配置後的性能變化是否符合預期。
5、驗證異常場景下的集羣擴展能力
在不斷增加併發的情況下，讓彈性擴容的一部分pod掛掉，觀察pod掛掉之後是否有新的pod繼續擴容，還是擴容動作到此停止。
當然異常場景有很多，比如將擴容的pod從集羣中T出去，比如是否觸發限流和熔斷，比如大量的請求異常情況。
除了上述動作之外，還需要考慮其他因素，比如外部依賴調用如何處理(常見的方式就是mock)，比如應用集羣依賴的一些中間件參數配置要調整，保持一定冗餘，否則容易出現pod集羣擴容了，其他組件性能沒跟上導致的尷尬場面。
當然，上述五個壓測任務可以互相組合，驗證更多場景下的性能表現，如何組合取決於性能測試的目的和預期的目標。