如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ 👉
每週五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步法來實現。
-
得到業務的流量指標
-
通過調用比例獲得相關接口的性能指標
-
根據歷史數據進行校準
-
根據衰減曲線得到預估的節點數量
-
預留一些彈性空間
希望對你有所幫助。
推薦閱讀：
作者：Zachary
出處：https://zacharyfan.com/archives/835.html
如果你喜歡這篇文章，可以點一下右下角的「推薦」。
這樣可以給我一點反饋。: )
謝謝你的舉手之勞。
既然看到這了，送我一個「贊同」吧，支持我的創作。
想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」或者在「右側掃描」。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。