浅谈容量规划
俗話說，”人無遠慮，必有近憂”，容量規劃就是”遠慮”。所謂容量規劃，是一個產品滿足用戶目標需求而決定生產能力的過程。當產品發展到一個較為穩定成熟的階段，產品的整體處理能力的把控自然是不可或缺，盡管我們在線下做性能測試能夠獲得一些數據，其參考價值終究有限。但是我們常常被問到以下一些問題而無以應對。
1.單臺節點到底最大處理能力是多少？ ?
2.目前線上有多少容量正在被使用？?
3.在一次大促前當前的機器數是否能夠支撐？?
4.什么時候需要增加機器？加多少？
這時候，容量規劃就顯得格外必要了。通過對容量規劃學習，談談自己對容量規劃的認識和理解。
什么樣的集群適合做容量規劃？只有線性可水平擴展的集群，我們才能通過獲取一個節點的處理能力，計算出集群的處理能力，否則將會費很大物力和人力。
怎么做容量規劃？一句話概括：線上壓測到單節點的某一指標達到臨界值，從而計算出集群的最大處理能力，再根據線上歷史監控獲得當前集群實際運行負荷，通過計算即可求出理論機器。
容量規劃能指導我們做什么？如果計算出集群當前的負荷快達到極限處理能力時，我們可以垂直擴展(加CPU/內存/磁盤)和水平擴展(加機器)兩種方式來增加集群容量。
容量規劃6步走
Step1：明確目標
容量規劃和計算，我們可以用運籌學中的優化命題來定義，優化命題的目標是集群實際負荷 <=集群理想負荷，求解這樣一個不等式優化命題，同時系統需要滿足一定的不等式約束條件。
(1) 目標：
備注：
(2) 約束條件：?
當然滿足目標的同時，集群的狀態是受到約束的，資源是不可能無限供應，終會有一項資源會達到臨界值。
Step2：了解集群特點
不同的集群在選取容量指標和約束條件時是完全不同的，容量指標在后面會介紹，主要用于衡量集群的處理能力，而約束條件是壓測停止的信號。舉例說明，對于CPU密集型的集群，我們常常會選擇TPS(每秒處理請求書)作為集群的容量指標來衡量集群的處理能力，而約束條件中則會重點關注CPU的使用率是否率先成為瓶頸；對于存儲型的集群，選擇流量(MB/S)作為容量指標，存儲型的集群TPS依賴于業務數據大小，所有流量更適合作為表征集群的處理能力，而約束條件最先成為瓶頸的是網絡流量或者IO。
而判斷集群式何種類型則可以通過線下的性能測試結果來判斷，線下的性能測試可以作為線上壓測的參考依據。
Step3：選取容量指標
容量指標主要用作衡量服務器的處理能力。容量指標的選取原則：1)線上數據可采集2)能夠客觀反映服務器處理能力。
作為容量指標，需要通過線上監控獲取統計數據，其歷史數據用于計算集群的實際負荷，而通過壓測獲得集群的最大處理能力。如上所說，CPU密集型集群常選TPS作為容量指標，而存儲型集群常選流量作為容量指標。
Step4：明確約束條件
約束條件的存在主要是作為線上壓測停止的信號，常常會包括業務指標和資源指標。其中只要有一項指標達到臨界值，則停止壓測將當前容量指標的值作為集群的最大處理能力，例如某項服務質量要求響應時間不超過100ms，那當響應時間達到臨界值時，盡管其它指標并沒有達到極限但是也把此時作為集群最大處理能力。因此服務指標的選取原則：1)業務需求 2)資源使用瓶頸。一則保證產品的服務質量，二來保證系統的安全。
Step5：線上壓測
線上壓測的主要目的主要用于獲取集群的最大處理能力，而對于線上壓測的手段主要介紹三種，針對不同的集群系統架構特點和業務類型選取不同的壓測手段。
模擬請求
模擬請求，即是模擬客戶端的調用方式向壓測服務器發起請求，簡單易操作。
測試數據：可以通過分析線上日志分析，根線上業務配比建立壓測模型，對于HTTP請求業務還有一種簡單的方式，通過提取線上日志數據URL直接用于壓測請求數據。
實施步驟
(1) 將線上一臺節點offline，測試客戶端直連被測服務器?
(2) 客戶端梯度增加并發(50),不斷增加并發直至超過設定的服務指標
優缺點
測試效果不受服務實際流量的限制，壓測時間靈活，適用于GET請求不會產生臟數據。業務指標可以通過測試客戶端直接獲取。
風險評估
風險低，首先機器offline不會影響到線上的正常請求；其次緩慢增加并發，不會造成服務崩潰的情況。
線上引流
?
線上引流，即將線上其它節點的請求復制到被測服務器上，推薦使用Tcpcopy工具。
測試數據：線上請求直接復制引流，無需準備數據
實施步驟
(1) 將線上一臺節點Off-line，按照Tcpcopy部署的方法部署client和server，為了便于指標的統計，通常將Tcpcopy部署在nginx所在服務器，被壓測服務器前需要增加一層nginx服務器。?
(2) 將集群的其它節點流量復制到off-line節點上，可以通過tcpcopy –r參數逐步增加復制系數，不斷增加-r參數直至超過設定的服務指標?
(3) 如果100%全部線上流量都不能壓測到off-line節點的瓶頸，再逐步放大引流系數
優缺點
請求真實，能夠放大流量，測試效果不受服務實際流量的限制，壓測時間靈活，但環境部署稍微麻煩，對于PUT請求需要做一些業務處理，避免產生臟數據。
風險評估
風險低，首先機器offline不會影響到線上的正常請求，緩慢增加流量復制，不會造成服務崩潰的情況。
修改負載權重
對于一個集群，前面往往會有負載均衡服務器，以Nginx為例，通過修改Upstream模塊的負載均衡weight可以不斷增加集群某一節點的請求數，增加其訪問壓力。
測試數據：無需準備
實施步驟
(1) 緩慢增加nginx的負載均衡系數，使被測節點壓力不斷增加?
(2) 直至超過設定的服務指標停止增加壓力
優缺點
完全真實的場景，壓測數據準確，但是依賴自身的流量，壓測時間不靈活，需在高峰期，對用戶體驗有一定影響，隨著一臺機器的負載增加響應時間會受到一定影響，會直接反饋給在線用戶。
風險評估
風險低，雖然在高峰期進行，但是只需要修改nginx配置再reload，對服務基本無影響，且每次都逐步增加weight，不會造成服務器崩潰的情況。
Step6：線上監控
線上監控不僅用于集群歷史數據的收集，計算集群的實際負荷的監控，還用于壓測過程中監控約束條件中的各種指標是否超限并停止壓測。根據集群的特點和之前性能測試經驗關注容量指標和約束條件的業務和資源指標。而這里的歷史數據，是需要長期的采集和整理。
小結
綜上所述，容量規劃主要圍繞著這么一個等式展開工作，紙上談來終覺淺，實踐出真知。希望能夠在接下來的實踐中成長和收獲。
原文地址：https://www.cnblogs.com/qwop/p/6637351.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
總結
- 上一篇： AddMvc 和 AddMvcCore
- 下一篇： 【译文】领域模型的五个特征