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

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

每週五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接口採集到的數據，就能獲得每一個接口與業務流量之間的關係。順帶也能看到在低壓力下的錯誤率、平均響應時間、tp9五、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步法來實現。

1. 獲得業務的流量指標
2. 經過調用比例得到相關接口的性能指標
3. 根據歷史數據進行校準
4. 根據衰減曲線獲得預估的節點數量
5. 預留一些彈性空間

但願對你有所幫助。

推薦閱讀：

• 分佈式系統關注點——360°的全方位監控
• 分佈式系統關注點——深刻淺出「異步」

做者：Zachary

出處：https://zacharyfan.com/archives/835.html

若是你喜歡這篇文章，能夠點一下文末的「贊」。

這樣能夠給我一點反饋。: )

謝謝你的舉手之勞。

▶關於做者：張帆（Zachary， 我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎 掃描下方的二維碼~。

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。

按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些深度思考。