如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個人的公眾號（跨界架構(gòu)師）喲~?

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比遵義網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式遵義網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋遵義地區(qū)。費用合理售后完善，十余年實體公司更值得信賴。

每周五11：45 按時送達。當然了，也會時不時加個餐～

我的第「85」篇原創(chuàng)敬上

隨著20年來互聯(lián)網(wǎng)的蓬勃發(fā)展，一個軟件系統(tǒng)所要面對的訪問壓力上限被逐漸提高。

雖然如此，但是那些體量達到億級或者是千萬級的產(chǎn)品也只是少數(shù)公司的專屬。對于整個行業(yè)里百萬+的程序員群體來說，估計也就只有10%人有機會接觸到這些“大系統(tǒng)”。

所以，一提到容量預(yù)估，大家可能第一時間想到的是，這是大公司的事，我們這種小系統(tǒng)不用考慮這個問題。

這說法其實不太對?，F(xiàn)在這個時代，營銷活動滿天飛，初創(chuàng)企業(yè)更是在絞盡腦汁想著“一炮而紅”，所以哪怕不是那些千萬級以上的系統(tǒng)也需要考慮容量預(yù)估的問題。

對大型系統(tǒng)來說，容量預(yù)估是剛需，關(guān)乎到系統(tǒng)能不能扛住，或者投入的資源會不會過度浪費，畢竟1%都是好多錢吶。

而對小系統(tǒng)來說，多花個百八十萬，多冗余一些資源也沒問題。

雖然如此，但是Z哥覺得，能不能做好「容量預(yù)估」，背后體現(xiàn)的是一個人解決沒有標準答案的問題的能力。

這是很多程序員都缺乏的一個能力。

所以，不管你當前是在大公司還是小公司，只要你希望提高你的架構(gòu)能力，或者未來想有機會把握住在大公司的工作機會，那么這是一個必須要掌握的基本技能。

日積月累的程序員思維讓大家都習(xí)慣了事事都有0和1，true和false。然而真正復(fù)雜的問題是那些沒有標準答案的問題，在這些問題中，沒有對和錯，只有合適和不合適。

而且，如今大家的生活越來越“在線化”。如果一個系統(tǒng)的負載能力，我們一直不去關(guān)注它。那么，當好不容易熬到的“風(fēng)口”真的吹來的時候，能把握住嗎？還是眼睜睜的錯過它們。

我想，大多數(shù)人對容量預(yù)估還是有一些概念的。通過數(shù)據(jù)推算出對系統(tǒng)承載能力的要求，并且實施滿足要求的程序部署。

比如，下個月要做一輪大促。系統(tǒng)要達到一個什么狀態(tài)才能順利支撐大促的開展？

大家腦子里至少都會有這樣的一個公式：

流量?/?單機性能?=?X臺機器

但我認為這個理解還可以再深入一些。Z哥的理解是：容量預(yù)估的本質(zhì)是為了獲得技術(shù)投入與業(yè)務(wù)發(fā)展之間的合理值，追求的是無限接近于“剛剛好”的狀態(tài)。

要達到“剛剛好”的狀態(tài)，必然意味著不能憑借拍腦袋辦事，而要考慮到盡可能多的維度，采集更多維度的數(shù)據(jù)作為參考。

因為實際的情況，肯定不是像上面公式一樣簡單的線性關(guān)系。而是類似下面這樣的對數(shù)曲線關(guān)系。

那么具體該怎么做容量規(guī)劃呢？

在這之前我們先得搞清楚幾個概念。

首先是指標。我們主要關(guān)注以下幾個指標。

• UV（Unique Vistor）：一段時間內(nèi)的訪客數(shù)，同一訪客在該時段內(nèi)的多次訪問只計一次。

• PV（page view）：一段時間內(nèi)的頁面瀏覽次數(shù)，同一用戶多次打開同一頁面也繼續(xù)累計。

• 響應(yīng)時間/系統(tǒng)延遲(Latency)：系統(tǒng)處理一個請求/任務(wù)的延遲（請求處理時間+數(shù)據(jù)傳輸時間）

• 吞吐量(Throughput)：一個單位時間內(nèi)可以處理的請求數(shù)。也就是該單位時間內(nèi)發(fā)起的請求總數(shù)/平均響應(yīng)時間，請求數(shù)可以是一次pv、也可以是一次rpc調(diào)用等等。

• TPS（Transaction Per Second）：可以理解為，單位時間是“秒”的「吞吐量」。

其次，我們要對會產(chǎn)生性能開銷的地方要有認識。這主要分為3個部分。

• 硬件/操作系統(tǒng)層面的開銷。如磁盤I/O、網(wǎng)絡(luò)I/O，CPU的多線程切換等等。

• 進程運行的開銷。如代碼邏輯啊、鎖啊等等。

• 多個進程之間的通信開銷。rpc框架、數(shù)據(jù)庫訪問框架、redis/memcached訪問SDK、MQ訪問SDK等等。

然后就可以開始做「容量規(guī)劃」了。

我一般是按以下5個步驟進行。

第一步，搞清楚業(yè)務(wù)的狀況，先得到業(yè)務(wù)上的指標。

技術(shù)工作最怕隔著“部門墻”，蒙著頭做，沉浸在自己的“小世界”里。

所以，不管通過什么途徑，得先對一些業(yè)務(wù)指標有客觀的認識，PV、UV的數(shù)據(jù)是必須的?？梢哉覙I(yè)務(wù)方聊，也可以借助百度指數(shù)、微信指數(shù)等更宏觀數(shù)據(jù)來進行參考和修正。

第二步，圍繞這個業(yè)務(wù)指標，對所涉及的相關(guān)技術(shù)接口制定性能指標。

其實就是要得到一個業(yè)務(wù)流量與技術(shù)的性能指標之間的一個比例關(guān)系。

比如，訪問一次A頁面，涉及到調(diào)用a接口2次，b接口1次，c接口3次這樣。

做這事兒有一個簡單的辦法。

先在系統(tǒng)中的每個api接口做好數(shù)據(jù)采集，目的是為了后續(xù)能獲得兩個數(shù)據(jù)，響應(yīng)時間和次數(shù)等等。

然后借助一些壓測工具，比如loadrunner之類，對當前的業(yè)務(wù)場景做一輪的全鏈路壓測。模擬的用戶數(shù)不用很大，因為我們只是為了得到一個比例。

這樣，在壓測結(jié)束后，你就可以將loadrunner中所記錄的發(fā)起請求的數(shù)量，對比api接口采集到的數(shù)據(jù)，就能得到每個接口與業(yè)務(wù)流量之間的關(guān)系。順帶也能看到在低壓力下的錯誤率、平均響應(yīng)時間、tp95、tp99等等的情況。

第三步，借助過去的經(jīng)驗對標準進行校準。

真實的生產(chǎn)環(huán)境是錯綜復(fù)雜的，因為一個api接口往往會被眾多地方調(diào)用。

那么做校準就是為了讓我們的預(yù)估更接近真實的生產(chǎn)環(huán)境一些。

如果有過去成功支撐的案例數(shù)據(jù)就最好了。用當時的UV、PV數(shù)據(jù)、接口與業(yè)務(wù)量比例對比當前的業(yè)務(wù)預(yù)估的UV、PV、接口與業(yè)務(wù)量比例進行同比例的調(diào)整。

可以得出下面這樣的公式：

應(yīng)滿足的TPS =?成功時的TPS *?(當前預(yù)估業(yè)務(wù)流量?/?成功時業(yè)務(wù)流量)?*?(當前業(yè)務(wù)接口比例/成功時業(yè)務(wù)接口比例)。

沒有成功案例的話，可以通過分析數(shù)據(jù)庫中任何帶有“時間”字段的數(shù)據(jù)，找到其中已知可承受的高并發(fā)值，以及對應(yīng)的時間點。（簡單粗暴的方式可以groupby“時間字段”）

再反向去找對應(yīng)這個時間節(jié)點的PV、UV。

然后再與這次的業(yè)務(wù)指標預(yù)估進行對比，看下差異比例。

應(yīng)滿足的TPS =?歷史高TPS(不管抗沒扛住)?*?(當前預(yù)估業(yè)務(wù)流量?/??歷史高TPS時業(yè)務(wù)流量)?*?(當前業(yè)務(wù)接口比例 /?歷史高TPS(不管抗沒扛住)?時業(yè)務(wù)接口比例)。

當然了，最壞的情況就是，過去對數(shù)據(jù)不夠重視，完全沒有數(shù)據(jù)可以參考。

那就馬上做數(shù)據(jù)埋點，分析當前系統(tǒng)的運行時數(shù)據(jù)，得到當前某個時段的業(yè)務(wù)流量以及對應(yīng)的TPS。這應(yīng)該不是難事。

這樣也可以推算出一個「應(yīng)滿足的TPS」。

應(yīng)滿足的TPS = 該TPS?*?（當前預(yù)估業(yè)務(wù)流量?/ 某時段業(yè)務(wù)流量）?*?當前業(yè)務(wù)接口比例

最后，得到了一個這樣的每個接口的性能指標。

接下來要做的第四步，就是確定到底要部署多少服務(wù)器，多少程序才能滿足這些標準。

正如前面所說，得到這個結(jié)果不是簡單的做除法，因為這不是一個線性關(guān)系。

所以，我們需要動手進行驗證。

你可以通過分別壓測1臺、2臺、3臺、……，不同數(shù)量的服務(wù)器，得到下面這樣的一個曲線。（當然，性能優(yōu)化工作也是在這個期間進行）

?

如此一來，你就可以根據(jù)這個衰減的趨勢，得到一個理論上能支撐業(yè)務(wù)所需的程序數(shù)量和服務(wù)器數(shù)量。

當然了，理論畢竟是理論，為了保險起見，還是要預(yù)留一定的彈性空間，這就是第五步。免得算的太“扣”，沒給自己留后路。

該“彈”多少合適呢？

Z哥的建議是，同比分析一下過去一段時間內(nèi)的業(yè)務(wù)量情況，觀察每個波峰的同比增長大小，將同比增長的大值作為彈性部分的比例。

彈性部分可以不用100%提前啟用，但要隨著備著。

到這里你就完成了整個容量預(yù)估工作的5個步驟。

其實最終得到的數(shù)據(jù)還有一些其他作用。比如，設(shè)置程序的線程數(shù)量、配置web容器（nginx、tomcat、iis）等等。

因為大多數(shù)情況下，參數(shù)都會設(shè)置的過大，甚至有不少小伙伴會一拍腦袋的設(shè)置成max值。

其實這樣的風(fēng)險是非常大的，不但會有資源耗盡的風(fēng)險，在分布式系統(tǒng)中還會產(chǎn)生級聯(lián)反應(yīng)，影響上游系統(tǒng)。

好了，我們來總結(jié)一下。

這次呢，Z哥先和你聊了一下容量預(yù)估的意義。

然后，分享了我自己做容量預(yù)估的思路，通過5步法來實現(xiàn)。

1. 得到業(yè)務(wù)的流量指標

2. 通過調(diào)用比例獲得相關(guān)接口的性能指標

3. 根據(jù)歷史數(shù)據(jù)進行校準

4. 根據(jù)衰減曲線得到預(yù)估的節(jié)點數(shù)量

5. 預(yù)留一些彈性空間

希望對你有所幫助。

推薦閱讀：

• 分布式系統(tǒng)關(guān)注點——360°的全方位監(jiān)控

• 分布式系統(tǒng)關(guān)注點——深入淺出「異步」

作者：Zachary

出處：https://www.cnblogs.com/Zachary-Fan/p/capacityestimate.html

如果你喜歡這篇文章，可以點一下左下角的「推薦」。

這樣可以給我一點反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。

如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長期收集和整理的思維導(dǎo)圖。

如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「運營」，送你一份我長期收集和整理的思維導(dǎo)圖。

定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計丨分布式系統(tǒng)丨產(chǎn)品丨運營丨一些深度思考。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。