生活随笔
收集整理的這篇文章主要介紹了
做「容量预估」可没有true和false
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
這里是Z哥的個人公眾號
每周五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個部分。
然后就可以開始做「容量規劃」了。
我一般是按以下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步法來實現。
得到業務的流量指標
通過調用比例獲得相關接口的性能指標
根據歷史數據進行校準
根據衰減曲線得到預估的節點數量
預留一些彈性空間
希望對你有所幫助。
推薦閱讀：
分布式系統關注點——360°的全方位監控
分布式系統關注點——深入淺出「異步」
原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）
如果有希望我寫一下什么主題的話，歡迎在后臺給我留言哦～
可以試試點擊「閱讀原文」
總結
以上是生活随笔為你收集整理的做「容量预估」可没有true和false的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
