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

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

我的第「85」篇原創敬上

隨著20年來網際網路的蓬勃發展，一個軟體系統所要面對的訪問壓力上限被逐漸提高。

雖然如此，但是那些體量達到億級或者是千萬級的產品也只是少數公司的專屬。對於整個行業裡百萬+的程式設計師群體來說，估計也就只有10%人有機會接觸到這些“大系統”。

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

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

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

而對小系統來說，多花個百八十萬，多冗餘一些資源也沒問題。

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

這是很多程式設計師都缺乏的一個能力。

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

日積月累的程式設計師思維讓大家都習慣了事事都有0和1，true和false。然而真正複雜的問題是那些沒有標準答案的問題，在這些問題中，沒有對和錯，只有合適和不合適。

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

我想，大多數人對容量預估還是有一些概念的。透過資料推算出對系統承載能力的要求，並且實施滿足要求的程式部署。

比如，下個月要做一輪大促。系統要達到一個什麼狀態才能順利支撐大促的開展？

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

流量 / 單機效能 = X臺機器

但我認為這個理解還可以再深入一些。Z哥的理解是： 容量預估的本質是為了獲得技術投入與業務發展之間的合理值，追求的是無限接近於“剛剛好”的狀態。

要達到“剛剛好”的狀態，必然意味著不能憑藉拍腦袋辦事，而要考慮到儘可能多的維度，採集更多維度的資料作為參考。

因為實際的情況，肯定不是像上面公式一樣簡單的線性關係。而是類似下面這樣的對數曲線關係。

那麼具體該怎麼做容量規劃呢？

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

首先是指標。我們主要關注以下幾個指標。

UV（Unique Vistor）：一段時間內的訪客數，同一訪客在該時段內的多次訪問只計一次。
PV（page view）：一段時間內的頁面瀏覽次數，同一使用者多次開啟同一頁面也繼續累計。
響應時間/系統延遲(Latency)：系統處理一個請求/任務的延遲（請求處理時間+資料傳輸時間）
吞吐量(Throughput)：一個單位時間內可以處理的請求數。也就是該單位時間內發起的請求總數/平均響應時間，請求數可以是一次pv、也可以是一次rpc呼叫等等。
TPS（Transaction Per Second）：可以理解為，單位時間是“秒”的「吞吐量」。

其次，我們要對會產生效能開銷的地方要有認識。這主要分為3個部分。

硬體/作業系統層面的開銷。如磁碟I/O、網路I/O，CPU的多執行緒切換等等。
程式執行的開銷。如程式碼邏輯啊、鎖啊等等。
多個程式之間的通訊開銷。rpc框架、資料庫訪問框架、redis/memcached訪問SDK、MQ訪問SDK等等。

然後就可以開始做「容量規劃」了。

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

第一步，搞清楚業務的狀況，先得到業務上的指標。

技術工作最怕隔著“部門牆”，蒙著頭做，沉浸在自己的“小世界”裡。

所以，不管透過什麼途徑，得先對一些業務指標有客觀的認識，PV、UV的資料是必須的。可以找業務方聊，也可以藉助百度指數、微信指數等更宏觀資料來進行參考和修正。

第二步，圍繞這個業務指標，對所涉及的相關技術介面制定效能指標。

其實就是要得到一個業務流量與技術的效能指標之間的一個比例關係。

比如，訪問一次A頁面，涉及到呼叫a介面2次，b介面1次，c介面3次這樣。

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

先在系統中的每個api介面做好資料採集，目的是為了後續能獲得兩個資料，響應時間和次數等等。

然後藉助一些壓測工具，比如loadrunner之類，對當前的業務場景做一輪的全鏈路壓測。模擬的使用者數不用很大，因為我們只是為了得到一個比例。

這樣，在壓測結束後，你就可以將loadrunner中所記錄的發起請求的數量，對比api介面採集到的資料，就能得到每個介面與業務流量之間的關係。順帶也能看到在低壓力下的錯誤率、平均響應時間、tp95、tp99等等的情況。

第三步，藉助過去的經驗對標準進行校準。

真實的生產環境是錯綜複雜的，因為一個api介面往往會被眾多地方呼叫。

那麼做校準就是為了讓我們的預估更接近真實的生產環境一些。

如果有過去成功支撐的案例資料就最好了。用當時的UV、PV資料、介面與業務量比例對比當前的業務預估的UV、PV、介面與業務量比例進行同比例的調整。

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

應滿足的TPS = 成功時的TPS * (當前預估業務流量 / 成功時業務流量) * (當前業務介面比例/成功時業務介面比例)。

沒有成功案例的話，可以透過分析資料庫中任何帶有“時間”欄位的資料，找到其中已知可承受的最高併發值，以及對應的時間點。（簡單粗暴的方式可以groupby“時間欄位”）

再反向去找對應這個時間節點的PV、UV。

然後再與這次的業務指標預估進行對比，看下差異比例。

應滿足的TPS = 歷史最高TPS(不管抗沒扛住) * (當前預估業務流量 / 歷史最高TPS時業務流量) * (當前業務介面比例 / 歷史最高TPS(不管抗沒扛住) 時業務介面比例)。

當然了，最壞的情況就是，過去對資料不夠重視，完全沒有資料可以參考。

那就馬上做資料埋點，分析當前系統的執行時資料，得到當前某個時段的業務流量以及對應的TPS。這應該不是難事。

這樣也可以推算出一個「應滿足的TPS」。

應滿足的TPS = 該TPS * （當前預估業務流量 / 某時段業務流量） * 當前業務介面比例

最後，得到了一個這樣的每個介面的效能指標。

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

正如前面所說，得到這個結果不是簡單的做除法，因為這不是一個線性關係。

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

你可以透過分別壓測1臺、2臺、3臺、……，不同數量的伺服器，得到下面這樣的一個曲線。（當然，效能最佳化工作也是在這個期間進行）

如此一來，你就可以根據這個衰減的趨勢，得到一個理論上能支撐業務所需的程式數量和伺服器數量。

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

該“彈”多少合適呢？

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

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

到這裡你就完成了整個容量預估工作的5個步驟。

其實最終得到的資料還有一些其他作用。比如，設定程式的執行緒數量、配置web容器（nginx、tomcat、iis）等等。

因為大多數情況下，引數都會設定的過大，甚至有不少小夥伴會一拍腦袋的設定成max值。

其實這樣的風險是非常大的，不但會有資源耗盡的風險，在分散式系統中還會產生級聯反應，影響上游系統。

好了，我們來總結一下。

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

然後，分享了我自己做容量預估的思路，透過5步法來實現。

得到業務的流量指標
透過呼叫比例獲得相關介面的效能指標
根據歷史資料進行校準
根據衰減曲線得到預估的節點數量
預留一些彈性空間

希望對你有所幫助。

做「容量預估」可沒有true和false

相關文章