今天我們來討論一下在公司運營方面很重要的容量規劃。容量規劃，就是根據網際網路服務的需求和公司發展目標，而決定容量的**能力的過程。
光說概念你可能不太明白，不過你可以這麼理解，容量規劃是為了回答一系列和公司業務運營有關的重要問題而產生的：
今天我先講容量規劃的目標和基本過程，然後再乙個乙個地講容量規劃的六大挑戰。
我們前面也大概提到過，容量規劃的目的有兩方面。一方面是為了保證公司的正常運營和業務增長，及時地提供足夠的容量，來滿足未來所需。另一方面，也是希望空閒的容量越少越好，因為每一台空閒的伺服器，都消耗公司的運營成本。
現代的網際網路服務規模的擴充套件，主要是用「水平擴充套件」而不是「垂直擴充套件」（通過增加伺服器的數量和網路的頻寬來提供更多的容量，而不是通過公升級伺服器）。相對於垂直擴充套件，水平擴充套件的優點顯而易見，就是成本相對較低、調整容易、擴充套件性好。
整個容量規劃的過程分為幾部分：首先是容量測試來決定單位容量的負載能力；同時確定公司的業務增長需求，並且獲取公司的運營預算。然後整合其他的考慮因素（包括時間、地域、災難恢復等），做出合理的規劃和決策。最後根據決策結果，進行容量訂購。
為了方便把握，我把這幾個因素模組整合在一起，如下圖所示，我們乙個模組乙個模組地講。
容量測試可以決定單位容量的能力。容量規劃的基礎，就是確定單位容量，比如一台伺服器系統的處理能力。而進行容量測試，一般是讓伺服器處於最大負載狀態，或某項效能指標達到所能接受的最大閾值下，對請求的最大處理能力。
容量測試是效能測試裡的一種測試方法，它的目的就是測量系統的最大容量，為系統擴容、效能優化提供參考，從而達到節省成本投入，提高資源利用率的目的。
容量測試大致分為兩種：線上測試和線下測試。我們在第25講專門講了線上測試，這裡快速地複習一下。線上測試相對比較準確，因為是用真實的生產流量負載。線下測試，則比較容易進行。但是你要特別注意測試過程和結果的代表性，就是它能否真實客觀地反映生產環境中的資料。尤其是測試環境的配置和驅動資料，一定要和線上的生產環境盡量保持一致。
要做好容量規劃，除了單位容量的處理能力，另外乙個必須要知道的輸入，是服務和業務的需求。通俗點說，就是期望達到的使用者數和資料流量大小。比如乙個前端服務，要決定明年的容量需求，就需要確定明年的預期使用者數目。
對於未來的容量需求的**，主要是參考歷史的相關資料，然後建立合適的模型。比如我們在第26講提到的針對時間序列的arima模型，就是乙個不錯的模型。如果針對的業務已經有足夠長的歷史，那麼過去的資料就很值得參考。
反之，如果乙個業務還沒有上線，或者上線時間很短，那麼歷史資料就不是很可靠。如果你面對的是這種情況，有兩種解決方法：一是可以模擬其他相似的服務，不管是公司內部的還是業界的，都可以拿來參考。二是需要借助一些主觀的推測。當然這種主觀推測也不能憑空亂猜，而是要有理有據。
容量規劃時，公司的業務運營預算也要考慮進去。乙個正常執行的公司，運營成本總是有限的（每個業務都有預算定額）。如果對乙個業務預期的容量需求，超過已經設定的預算定額，那麼，你要麼是把容量需求降低到預算定額，要麼就得向公司申請增加預算。
另外還有一點要注意的是，未來容量的需求**總會和實際情況有差距，也就是說，總是有不確定的因素。
所以，我們一般會根據估計的信心指數，對**結果做幾種不同的**。比如90%的信心和50%的信心。這裡信心指數越大，容量數值也越大，就是說越有把握滿足需求。舉個例子，比如我們要估計明年乙個服務的容量需求，可能得出結論：
但是，無論我們多麼努力地去**，總有些因素沒有考慮到，從而導致實際情況和**不吻合。所以，我們一般都要對容量的需求**加上乙個冗餘buffer，我個人的經驗是10%的buffer。比如我們的模型預計需要1000臺伺服器，那就加上100臺的buffer，也就是需要1100臺伺服器。
也正因為容量的規劃和使用過程中，有很多的不確定因素，隨著時間的推移，這些不確定因素慢慢就會變成確定的因素。比如，在乙個服務還沒有上線的時候，做容量規劃非常困難，因為不能準確地**使用者數量。但是隨著服務的上線，開始積累使用者量，對未來使用者數量的**就會變得越來越容易。
所以，容量的**和規劃，也是乙個持續和不斷迭代的過程。開始的時候靠模型，靠歷史資料和一些直覺來做大體**。然後，定期地和實際的資料做對比，從而調整和糾正以前的**。
容量規劃和**時，除了前面講的步驟和因素外，還有其他幾個限制因素和挑戰值得考慮。我總結了六個這樣的挑戰，包括地域的限制、伺服器種類的區分、時間和季節性等等。
第乙個挑戰就是，容量規劃不僅僅是錢的問題。你可能聽說過：「能用錢解決的問題，都不是問題。」
但容量的**問題，很多時候還真不是砸錢就能解決。
為什麼有時候錢不能解決容量問題呢？如果公司的運營規模很大的話，需要的容量**也就很大。在很多情況下，市場上能夠找到的資料中心很有限，所以即使公司願意投入很多資金，也不一定就能在需要的地點和需要的時間租賃到足夠的容量。
有的公司自己建造資料中心，那就面臨更多新的的問題和挑戰，尤其是時間方面。建立資料中心的交貨時間至少是兩、三年。資料中心建造和擴建，需要尋找可用的建築商和建築工人，但是找到足夠的合格建築商和工人並非易事。因此，資料中心的建設並不像把錢扔在問題上那麼簡單，需要提前很久就規劃和考慮，要未雨綢繆。
第二個挑戰是地域因素。當公司的業務需要部署伺服器在多個資料中心時，每個資料中心都需要做相應的容量規劃。也就是說，僅僅只有**和規劃乙個總體的容量是不夠的，還需要具體到每個資料中心的內部。
下乙個挑戰是伺服器種類的挑戰。公司往往會有不同種類的伺服器，以便針對特定型別的工作負載進行量身定製。例如，有專門針對記憶體密集型工作負載的大記憶體伺服器。當有多種伺服器可選的時候，容量規劃就需要選擇最合適、最經濟的伺服器型別，這樣可以降低成本並改善服務質量。
對於一種具體的伺服器而言，它的效能也是隨著時間的推進不斷改善的。比如一種計算密集型的伺服器，雖然基本的機架設計不會改變，但是伺服器使用的cpu還是會一直更新換代的，一般每年都會有新的cpu型號。
所以，在做容量規劃時，也要把這個因素考慮在內。比如要支撐乙個服務，如果用現在的cpu型號**，明年需要一千臺伺服器。可是同時明年的cpu會公升級，效能提高了10%。那麼考慮到這點，可能只要900臺伺服器就夠了。
容量規劃也要充分考慮時間和季節的因素。在第26講裡，我們一起看過正常生產環境的負載變化。對大多數網際網路服務來講，在一天內，每天的上午上班時間的負載較大；在一周內，工作日的業務負載比較大。同時，當經歷節日時，比如春節、國慶等，也要注意流量的預期變化。
還有，為了保證業務的可靠性，災難恢復（dr，disaster recover）場景是必須考慮的。
災難恢復準備，意味著公司的容量可以容忍某個容量單位的損失。網際網路服務其實有很多種不同的dr場景，最常見的是資料中心的dr，也就是說，假如乙個資料中心因為天災人禍的原因完全不能訪問，其餘的容量如何支撐整個網際網路服務的正常運作。
災難怎樣影響服務效能呢？損失的容量單位，會導致其他容量單位的負載增加。負載的增加量，取決於丟失單位在整個容量系統中的比例。具體來說，假設丟失的容量單位，平時承擔的負載百分比為x％，那麼在丟失該容量單位之後，所有其他單位的流量將增加[1 /（1-x％）-1] * 100％。
為了幫助你理解，我先舉個簡單例子。假設乙個服務有兩個資料中心支援，這兩個資料中心大小是同樣的，都分別承擔50%的服務流量。那麼，如果乙個資料中心不能用了，另外的資料中心就需要承擔2倍的服務流量，也就是1/（1-50%）=2。
再舉個稍微複雜的例子。考慮以下情形，其中a、b、c的三個容量單位分別佔流量的40％、40％和20％。如果單位a丟失，那麼單位b和c的流量將增加1 /（1-0.4）-1 = 67％。如果c單位丟失，則a和b單位的流量將增加1 /（1-0.2）-1 = 25％。
最後，網際網路公司的業務，往往會分解成很多的服務。面對外部客戶的是前端服務；還有很多後端和內部的服務來支撐前端服務。所以，如果前端服務的負載有變化，後端服務也會受到影響。要**後端服務的容量需求，也必須充分考慮前端服務，以及其他上下游服務的影響。
一般來講，每層服務呼叫都會有一定的負載均衡機制，在規劃每層服務的容量需求，以及每層服務的不同容量單元的容量需求時，就要了解這些負載均衡機制，從而確定相關因子。比如，如果前端服務負載增加100％，則下游服務預計會增加多少負載？如果某個下游服務的負載增加也是100％，則相關因子為1。
每個服務的總體負載確定後，還要考慮具體到這個服務在不同資料中心的分配，也就是需要確定每個資料中心分別分配多少。
apache WEB應用的容量規劃
apache主要是乙個記憶體消耗型的服務應用，我個人總結的經驗公式 apache max process with good perfermance total hardware memory apache memory per process 2 apache max process apache...
Web容量規劃的藝術 要點
twitter上 fire9給我推薦了這本書，花了一些時間把這本書看了兩遍，總結性的點評語就是 書的質量非常的高，一方面這本書中的內容 於 flickr.com實際的經驗，另一方面是作者採用了很多生活中的例子來講解一些複雜的技術，讓人很快就明白了。下面就具體來看看這本書傳達的容量規劃該怎麼做。容量規...
如何對系統或服務（WAR）進行容量規劃
如何對系統或服務 war 進行容量規劃？容量規劃 根據業務量指標分解 包括 tps 期間的儲存資料量 結合系統壓測結果，來判斷系統的計算資源 包括 nginx,jboss 和 儲存資源 包括 redis 資料庫 是否足夠支撐？如果不能支撐，那麼需要擴容。擴容 集群橫向擴容，包括 nginx jbos...