1 背景
某年某月的某一天，有這樣的一段對話：
老板: 咱們線上容量是多少?
小強: 額，不太清楚
老板: N天后，我們的流量將增大M倍，系統能抗住嗎?
小強: 可能扛不住吧，不過我們可以擴容
老板: 擴多少?
小強: （拍腦袋）double一下吧
“double一下”是否可以解決問題？存在多大的浪費？如何有效評估系統容量來解決這個窘境?
在這里引出一個系統容量的概念。系統容量，指系統在有冗余的情況下的極限服務能力，可以理解為是水池的水位。當水位超過警戒線的時候，需要對系統進行橫向/縱向的調整。
系統容量需要預留冗余，是因為我們要保證在部署、網段故障、機房故障時，線上服務依舊是可用的。
綜上，可以得出公式：系統容量 = 單實例極限容量 * 當前實例數 * 冗余度
2 流行的方案
- jmeter
- 擴大單個實例的流量
- tcpcopy
2.1 jmeter
構造測試數據，進行接口級測試，觀察服務表現
優點：靈活，可對特定接口進行針對性壓測
缺點：很難模擬真實的流量場景（線上的接口太多，各接口的流量比例不同）
2.2 擴大流量
通過調整權重或縮減集群規模，將線上流量壓到單個服務實例上，觀察服務表現
優點：真實
缺點：在壓力過大時可能造成服務質量下降，影響用戶使用。
2.3 tcpcopy（推薦）
拷貝線上流量，對旁路環境進行壓測
優點：真實，不會影響用戶
缺點：需要準備完整的旁路環境
3 性能指標
不管采用什么樣的壓測方案，我們需要知道壓到什么程度就是“極限”了。
對于在線類服務，最關注的是服務的響應時間，可以是所有接口的平均響應時間，也可以是某些接口的平均響應時間。
由于壓測環境不是線上真實的服務器，需要單獨搭建一整套供壓測的環境。
建議按線上的部署比例進行等比例縮放壓測環境的實例數。
