嗯，第一份工作被家里逼到做碼農(nóng)。最要命的是，單位是國企，之前都是做政務(wù)管理系統(tǒng)的。如今計劃為集團(tuán)內(nèi)某公司做一個電商平臺，而且還要負(fù)責(zé)把整個方案的 策劃都拿出來。這還不說，對面連具體的需求都沒有給。不過老板的命令就是圣旨了，就算沒有任何信息，都得忽悠出一套讓老板大大放心的方案。
很不幸，我新人一個，沒有任何搞架構(gòu)的經(jīng)驗，編程菜鳥，參加過一個稀爛的Java項目，被安排負(fù)責(zé)估計服務(wù)器和網(wǎng)絡(luò)帶寬需求的任務(wù)。不過由于團(tuán)隊之前沒有做過任何的互聯(lián)網(wǎng)相關(guān)項目，所以這個任務(wù)的完成也是相當(dāng)重要的，我感到壓力很大。
說正題，從我在網(wǎng)上搜集到的一些資料來看，網(wǎng)站的負(fù)載能力主要還是依據(jù)每日PV的量。對于并發(fā)來講，每一個頁面請求可能有很多個HTTP請求，分別用來下載html，js，css和圖片等部分。同時，連接持續(xù)的時間也是一個重要的參數(shù)。一般來說，就這兩個參數(shù)，再加上PV的時間分布，即一天的多少小時內(nèi)產(chǎn)生這些PV，就可以估計網(wǎng)站的并發(fā)數(shù)了。計算公式如下：
PC=PV/T*C*t
其中，PC是并發(fā)數(shù)，T是觀測時間，即產(chǎn)生PV的時間長度，比如一天中的14個小時產(chǎn)生了20萬并發(fā)，則公式中T=14*60*60秒，PV=20萬。C是單個頁面請求的HTTP連接數(shù)，t是連接的持續(xù)時間，一般取一個估計用戶等待連接的時長，比如用戶在平均等待5秒發(fā)現(xiàn)網(wǎng)頁還沒打開就不耐煩了，那么這個t可以取5秒。不過由于網(wǎng)站的訪問往往有很大的不確定性，雖然我們知道平均PV，但是偶爾可能碰到訪問量井噴的時候，淘寶在搞促銷的時候就經(jīng)常有這個問題，京東也一樣，我在豆瓣上沒少見到友鄰鄙視京東的服務(wù)器承壓能力......嘛，我們在計算的時候就必須考慮這種極端情況帶來的影響，通常要在以上公式中加入一個因數(shù)，代表極端情況。那么以上公式修改為：
PC=PV/T*C*t*f
其中f表示極端情況下PV相對于平均PV的倍數(shù)。
需要注意的是，我們的計算僅考慮了服務(wù)器只有一臺的情況，或者說以上計算實際上估計的是總的并發(fā)需求，并未考慮硬件上可能存在多個服務(wù)器的情況。有些帖子里會簡單的在上面的公式右邊再除以服務(wù)器的個數(shù)。但本人并不贊同這種做法。因為不同服務(wù)器往往要運(yùn)行不同的應(yīng)用和服務(wù)，那么不同的服務(wù)器被訪問的量也就不同，用這種簡單平均的估算方法并不準(zhǔn)確，尤其是在項目較大，涉及的應(yīng)用較多的時候，這種計算非常不合理。更好的做法是根據(jù)具體的需求和系統(tǒng)的架構(gòu)來對各個服務(wù)器進(jìn)行估計。而這就涉及到技術(shù)架構(gòu)的很多方面了，比如請求中有多少是靜態(tài)頁面的，多少動態(tài)頁面的，多少對數(shù)據(jù)庫進(jìn)行讀寫操作的，是讀還是寫，緩存怎么安排，如果訪問量太大，單個數(shù)據(jù)庫的壓力太大，做成數(shù)據(jù)庫集群后又如何。訪問量再擴(kuò)大，現(xiàn)有的數(shù)據(jù)架構(gòu)能否跟上，服務(wù)器硬盤的I/O性能能否跟上等，都會成為估計的問題。目前我負(fù)責(zé)的項目還處于策劃階段，所以沒有辦法做到如此細(xì)致。但到了項目真正實施部署并測試的時候，這些應(yīng)該都會成為考慮的方向。
而帶寬的估計又跟并發(fā)有關(guān)，不僅如此，帶寬要求還跟網(wǎng)頁的平均大小，圖片的大小有很大的關(guān)系。技術(shù)方面，緩存的方案也會大大影響帶寬的使用。在不考慮任何優(yōu)化的情況下，帶寬的估算可以依據(jù)以下公式：
BW=PS*PC*8bit/byte*r/t
其中BW為帶寬大小，PS為頁面平均大小，PC為并發(fā)數(shù)，8bit/byte是單位轉(zhuǎn)換，1byte=8bit，r是因數(shù)，代表極端情況，作用跟并發(fā)估計中的f因數(shù)差不多。t指用戶能忍受的平均最大等待時間，比如20秒之內(nèi)網(wǎng)頁沒有完全打開，用戶就會離開，則t取20秒。同樣，這個公式估計的也是單個服務(wù)器的帶寬需求，或者是網(wǎng)站的總帶寬需求。對于具體的情況，我們往往也要根據(jù)系統(tǒng)架構(gòu)來對單個服務(wù)器進(jìn)行估計。這里面需要考慮的因素包括網(wǎng)絡(luò)請求中的數(shù)據(jù)平均大小，是網(wǎng)頁則是網(wǎng)頁的大小，是圖片則是圖片的大小，是Web服務(wù)接口則是通信的消息大??；瀏覽器端的緩存使用，js，css，圖片是否放在CDN上等等。因為信息太少，我依然無法準(zhǔn)確估計。
在干這個活的過程中，最令我享受的一點是能夠從整體上去考慮架構(gòu)的各個部分對于整個系統(tǒng)的負(fù)載能力的影響。由于以前沒有任何的架構(gòu)方面的知識，在不斷學(xué)習(xí)的過程中，感覺有些能夠看明白為什么一個用戶量從很小做到很大的系統(tǒng)的架構(gòu)演變是怎么來的了。爭取在實際參與項目后，能夠結(jié)合編程框架方面的技術(shù)再好好深入學(xué)習(xí)架構(gòu)。
另外，以上計算的公式，我都是在網(wǎng)上看來的，沒有過多的去深究機(jī)理，有什么不對的，還請高手們拍磚。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
