做「容量預(yù)估」可沒(méi)有true和false

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

每周五11：45 按時(shí)送達(dá)。當(dāng)然了，也會(huì)時(shí)不時(shí)加個(gè)餐～

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

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

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

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

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

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

而對(duì)小系統(tǒng)來(lái)說(shuō)，多花個(gè)百八十萬(wàn)，多冗余一些資源也沒(méi)問(wèn)題。

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

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

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

日積月累的程序員思維讓大家都習(xí)慣了事事都有0和1，true和false。然而真正復(fù)雜的問(wèn)題是那些沒(méi)有標(biāo)準(zhǔn)答案的問(wèn)題，在這些問(wèn)題中，沒(méi)有對(duì)和錯(cuò)，只有合適和不合適。

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

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

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

大家腦子里至少都會(huì)有這樣的一個(gè)公式：

流量?/?單機(jī)性能?=?X臺(tái)機(jī)器

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

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

因?yàn)閷?shí)際的情況，肯定不是像上面公式一樣簡(jiǎn)單的線性關(guān)系。而是類似下面這樣的對(duì)數(shù)曲線關(guān)系。

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

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

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

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

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

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

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

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

其次，我們要對(duì)會(huì)產(chǎn)生性能開(kāi)銷的地方要有認(rèn)識(shí)。這主要分為3個(gè)部分。

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

• 進(jìn)程運(yùn)行的開(kāi)銷。如代碼邏輯啊、鎖啊等等。

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

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

我一般是按以下5個(gè)步驟進(jìn)行。

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

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

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

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

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

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

做這事兒有一個(gè)簡(jiǎn)單的辦法。

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

然后借助一些壓測(cè)工具，比如loadrunner之類，對(duì)當(dāng)前的業(yè)務(wù)場(chǎng)景做一輪的全鏈路壓測(cè)。模擬的用戶數(shù)不用很大，因?yàn)槲覀冎皇菫榱说玫揭粋€(gè)比例。

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

第三步，借助過(guò)去的經(jīng)驗(yàn)對(duì)標(biāo)準(zhǔn)進(jìn)行校準(zhǔn)。

真實(shí)的生產(chǎn)環(huán)境是錯(cuò)綜復(fù)雜的，因?yàn)橐粋€(gè)api接口往往會(huì)被眾多地方調(diào)用。

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

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

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

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

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

再反向去找對(duì)應(yīng)這個(gè)時(shí)間節(jié)點(diǎn)的PV、UV。

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

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

當(dāng)然了，最壞的情況就是，過(guò)去對(duì)數(shù)據(jù)不夠重視，完全沒(méi)有數(shù)據(jù)可以參考。

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

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

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

最后，得到了一個(gè)這樣的每個(gè)接口的性能指標(biāo)。

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

正如前面所說(shuō)，得到這個(gè)結(jié)果不是簡(jiǎn)單的做除法，因?yàn)檫@不是一個(gè)線性關(guān)系。

所以，我們需要?jiǎng)邮诌M(jìn)行驗(yàn)證。

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

??

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

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

該“彈”多少合適呢？

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

?

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

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

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

因?yàn)榇蠖鄶?shù)情況下，參數(shù)都會(huì)設(shè)置的過(guò)大，甚至有不少小伙伴會(huì)一拍腦袋的設(shè)置成max值。

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

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

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

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

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

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

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

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

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

希望對(duì)你有所幫助。

推薦閱讀：

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

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

作者：Zachary

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

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

這樣可以給我一點(diǎn)反饋。: )

謝謝你的舉手之勞。

?

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

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

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

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