朱燚
歡迎 jijo2005！退出我的博客配置寫文章文章管理博客首頁全站當(dāng)前博客空間博客好友相冊留言 談?wù)劸W(wǎng)站靜態(tài)化收藏
寫在前頭
靜態(tài)化是解決減輕網(wǎng)站壓力,提高網(wǎng)站訪問速度的常用方案,但在強(qiáng)調(diào)交互的We2.0 時(shí)代,對靜態(tài)化提出了更高的要求,靜態(tài)不僅要能靜,還要能動,下面我通過一個(gè)項(xiàng)目,談?wù)劸W(wǎng)站靜態(tài)化后的架構(gòu)設(shè)計(jì)方案,同時(shí)和大家探討一下,在開源產(chǎn)品大行其道,言架構(gòu)必稱MemberCache, Nginx,的時(shí)代,微軟技術(shù)在網(wǎng)站架構(gòu)設(shè)計(jì)中的運(yùn)用.
靜態(tài)化的設(shè)計(jì)原則和步驟
靜態(tài)化是解決減輕網(wǎng)站壓力,但是靜態(tài)化也會帶來一系列的問題,包括開發(fā)上復(fù)雜度的增加,維護(hù)難度的增加,運(yùn)用不的當(dāng),更可能適得其反,而許多替代方案,比如頁面緩存,如果運(yùn)用得當(dāng),也能起到很好的效果,所以在開始之前,必須進(jìn)行詳細(xì)的考察,確定是否適合靜態(tài)化,并制定適合的靜態(tài)化方式,下面先介紹一下
l 考查讀寫比:
讀寫比,準(zhǔn)確的說是讀寫負(fù)荷比,是否值得靜態(tài)化的最終考慮,由于一般寫入的壓力明顯大于讀出的壓力,如果寫入太頻繁,或者每次寫入消耗的資源太多,都不能達(dá)到效果,我覺得讀寫比例10:1應(yīng)該是個(gè)上限.具體情況需要根據(jù)自己的業(yè)務(wù)邏輯判斷
l 確定頁面呈現(xiàn)的內(nèi)容是否適合靜態(tài)化:
在設(shè)計(jì)方案時(shí),必須詳細(xì)考慮每個(gè)原型頁面,找到頁面上展示的信息,和他的更新方式,更新時(shí)機(jī),更新頻率,一定要注意那些不起眼的信息,他們可能左右你的設(shè)計(jì),
比如:我們以CSDN的論壇的任意一篇帖子為例,進(jìn)行分析
上面的帖子中呈現(xiàn)的內(nèi)容主要是這樣幾塊,帖子內(nèi)容,回復(fù)內(nèi)容,發(fā)帖人回復(fù)人的用戶信息
n 帖子內(nèi)容和回復(fù)內(nèi)容在發(fā)帖時(shí)更新,發(fā)帖后用戶可以修改其內(nèi)容,更新頻率高
n 用戶信息,用戶修改個(gè)人信息時(shí)可能會發(fā)生更改,用戶等級增加時(shí)也可能發(fā)生更改,比如加星,更新頻率低
n 回復(fù)數(shù)將每次回復(fù)后都要更改,更新頻率高
n 設(shè)計(jì)時(shí)要注意細(xì)節(jié),如上圖中圈出來的部分,這些部分是怎么修改的,頻率有多大,一個(gè)都不能放過.
l 確定生成方式:
在上面帖子一例中.每次更改都重新生成頁面是不可取的,一篇比回復(fù)數(shù)多的帖子,需要的數(shù)據(jù)量是巨大的(每層樓的用戶信息,回復(fù)內(nèi)容),任何修改,都需要重新取出數(shù)據(jù)進(jìn)行生成是不能允許的.一般除非你的頁面基本不用更新,或者更新開銷極小,(比如一段嵌入的廣告代碼)才能采用整體更新的方式,不然就需要我們找到合適的更新頁面局部區(qū)域的方法:
一般有下面兩個(gè)方法:
1) 正則修改法:
比如,如果帖子中的回復(fù)數(shù),html代碼是這樣 <label>回復(fù)數(shù)<var id="replyCount">34</var></label> 我們可以通過用下面正則來查找并替換計(jì)數(shù) (?<=id="replyCount">)\d{1,}2) 頁面區(qū)域分塊:
把頁面分成很多小塊,在顯示時(shí)組裝起來,比如DotText就采用這個(gè)方法
這是一篇典型的Dottext blog頁面,其中紅色標(biāo)定部分是一個(gè)獨(dú)立的文件,而黃色框內(nèi)的是腳本動態(tài)加載,這些部分在最終顯示的時(shí)候組合起來,最終構(gòu)成了一篇Blog,具體的組合方法也有多種,可以使用Include,也可以自己來實(shí)現(xiàn).DotText就自己實(shí)現(xiàn)了一套加載機(jī)制
上面的兩種方法并不孤立,并可以根據(jù)需要,配合使用
l 確定需要?jiǎng)討B(tài)加載的信息:
頁面上總有一些內(nèi)容看起來不太適合靜態(tài)化,最典型的是一些統(tǒng)計(jì)結(jié)果,比如如果你在做一個(gè)圖書介紹頁面,可能就會需要展示圖書的當(dāng)天綜合評分,或者書籍排名,這些內(nèi)容需要用腳本進(jìn)行動態(tài)加載
既然做了靜態(tài)化,就是希望減少服務(wù)器負(fù)載,動態(tài)加載的數(shù)據(jù)總是不得已而為之,有的時(shí)候在需求允許的情況下,我們在數(shù)據(jù)在實(shí)時(shí)性和性能方面做一些妥協(xié),比如上面帖子中的用戶星級和昵稱,從數(shù)據(jù)實(shí)時(shí)性上說,當(dāng)用戶的星級增長,他發(fā)言的所有帖子都應(yīng)該發(fā)生變化,所以應(yīng)該用動態(tài)加載.然而其實(shí)上這些信息如果不發(fā)生變化,也無傷大雅,用戶反而能夠看到自己在多年前發(fā)帖時(shí)的級別和昵稱.
現(xiàn)實(shí)中的項(xiàng)目
X網(wǎng)站是大型的電影資訊,電影社區(qū),向外提供電影相關(guān)信息服務(wù),以及用戶社區(qū),其中信息服務(wù)部分, 其中大部分頁面屬于信息呈現(xiàn)頁,讀取量比較大,百萬級別pv,信息主要由編輯在后臺發(fā)布,更新較少,但其頁面上有大量的交互性的內(nèi)容,比如評論,收藏列表,同時(shí)許多內(nèi)容允許用戶創(chuàng)造,比如上傳圖片,添加注釋.交互內(nèi)容的數(shù)量和交互的頻繁程度,都超過了普通的咨詢頁面,這次調(diào)整,準(zhǔn)備將其中訪問量最大的幾塊:電影資料頁,影人資料頁,進(jìn)行靜態(tài)化,如果成功,還將運(yùn)用到更多的頻道,基本實(shí)現(xiàn)全站靜態(tài)化
通過對頁面設(shè)計(jì)和前一版本的分析,下面是具有挑戰(zhàn)性的地方.這些特點(diǎn)基本使用于大多數(shù)web2.0的站點(diǎn),很具有典型意義
l 頁面生成的觸發(fā)條件復(fù)雜
一般論壇中的帖子或者blog,更新方式比較單一:主要是由回復(fù)進(jìn)行觸發(fā)還有少數(shù)的修改動作,然而該網(wǎng)站一個(gè)頁面上需要根據(jù)不同觸發(fā)條件就有20多個(gè), 比如光二級菜單:用戶發(fā)布圖片,刪除圖片,發(fā)布或者刪除影片信息,發(fā)布或者修改視頻,后臺修改電影信息,都有可能觸發(fā)
l 一個(gè)動作觸發(fā)生成的頁面可能很多而且相互交疊
每一個(gè)動作都會觸發(fā)一系列的生成,并且不同動作可能都會涉及同一個(gè)頁面或者區(qū)域的生成.
比如:用戶給一步電影評分,需要生成評分更多頁,評分統(tǒng)計(jì)更多頁,首頁右側(cè)誰還關(guān)注此影片小區(qū)域,等等.用戶收藏一個(gè)影片,也需要更新首頁右側(cè)誰還關(guān)注此影片小區(qū)域
l 觸發(fā)頻繁:
雖然不及某些更大規(guī)模的網(wǎng)站,但是由于涉及眾多用戶參與的內(nèi)容,評論,收藏等等,觸發(fā)點(diǎn)多,發(fā)生頻度相當(dāng)頻繁
l 頁面多,結(jié)構(gòu)復(fù)雜,空間占用大:
通常,需要生成的頁面規(guī)模是這樣粗略估算的,Rn*P,Rn為資源數(shù),P為每個(gè)資源的頁面數(shù),所謂資源,可以看做一個(gè)生成單位,其頁面數(shù)可以簡單看做發(fā)布一個(gè)資源,就需要生成其所有相關(guān)頁面數(shù)量,比如:發(fā)布一個(gè)blog,就需要生成一個(gè)Blog頁,同時(shí)還需要生成或者更新個(gè)人主頁的blog列表,算上個(gè)人主頁右側(cè)的分類文章數(shù)的小塊,也就是最多10來個(gè)頁面或者區(qū)域,但是發(fā)布一個(gè)電影,其相關(guān)的頁面至少有50個(gè)以上,而且有的頁面還帶有分頁,一個(gè)信息比較豐富的電影,其頁面竟可以達(dá)到千個(gè)以上,空間10~20M,而且資源總數(shù)也不少,電影80000左右,電影人雖然P值較少,但是總量確有幾十萬之巨,估計(jì)靜態(tài)頁面磁盤占用量幾百個(gè)G
l 向下兼容
這是一個(gè)已有系統(tǒng),舊系統(tǒng)的框框需要突破,但又沒有時(shí)間,或者不能完全突破,比如Url,已經(jīng)被收錄到搜索引擎,就不能隨便調(diào)整,還有一些地方,原本沒有為靜態(tài)生成考慮,另一些地方又需要兼容舊的設(shè)計(jì).
l 多臺前端Web
這種結(jié)構(gòu)要求生成的文件可能需要分布到多個(gè)服務(wù)器(另一個(gè)方案是放在幾臺專用的機(jī)器上,等前端來取)
l 任務(wù)緊迫
架構(gòu)討論結(jié)束儀式六月初,離奧運(yùn)開幕上線只有兩月,也就是說所有底層框架實(shí)現(xiàn),頁面模板開發(fā),調(diào)試測試,動作的整理,必須在7月底全部完成,按我原來估計(jì),光實(shí)現(xiàn)這幾塊的上百個(gè)頁面模板和填充方法,也需要那么長的時(shí)間
綜合考慮上述因素,架構(gòu)必須要有以下幾個(gè)方面的特點(diǎn)
l 動作可以靈活擴(kuò)展配置,某個(gè)動作對應(yīng)哪些生成,應(yīng)該可以配置,并且可以分組
l 文件必須有分發(fā)機(jī)制
l 分發(fā)和生成必須獨(dú)立出來,并且支持分布式
l 各種的動作,必須轉(zhuǎn)化為消息,發(fā)送到生成和分發(fā)服務(wù)器進(jìn)行處理
l 針對同意資源頻繁動作,在變量相同的情況下能夠具有合并的能力
l 動作必須有記錄
l 盡量考慮使用已有成熟技術(shù),節(jié)省開發(fā)時(shí)間
下面是設(shè)計(jì)的第一個(gè)架構(gòu)
用戶的動作經(jīng)過MSMQ[1]傳入到生成分發(fā)中心(途中綠色箭頭)進(jìn)行處理,,處理中心接受到消息后,負(fù)責(zé)生成對應(yīng)的頁面或者頁面區(qū)域,并將頁面分發(fā)到各個(gè)服務(wù)器,負(fù)載均衡沿用以前的架構(gòu),采用微軟的NLB[2]
之所以用MSMQ,就是看上了他提供的完整的消息存儲恢復(fù)機(jī)制,這樣我們能確保即使服務(wù)器down掉重啟后,消息依然能正常處理,碰巧我們cms組的同事MSMQ非常熟悉,并且真準(zhǔn)備在另外一個(gè)項(xiàng)目中使用類似的架構(gòu)—于是一拍即合
頁面采用分塊存儲,這樣能保證生成時(shí)目標(biāo)小,開銷小,也能重用性,然后再藉由SSI[3](shtml include)進(jìn)行整合,之所以采取這樣的方案,而不采用Dottext的整合方式,是因?yàn)槿绻捎肈ottext的方式,就必須走IIS和.Net的管道[4],而據(jù)測試,經(jīng)過管道和直接返回html性能有非常大的差異,而使用ssi,在性能上是一個(gè)折中,并且可以Light HTTPd等高性能web服務(wù)器
模板生成方式,采用了XSLT和另外一種自定義的模板(我的同事開發(fā)的機(jī)制,很有趣, 理論上能把傳統(tǒng)模板替換的性能開銷全部消除),生成的最終產(chǎn)物是shtml,之所以生成shtml是為了使用其ssi(Server Side Include)的特性,保證一定的靈活性,并實(shí)現(xiàn)熱點(diǎn)數(shù)據(jù)的分離:某些頁面上的部分可能會頻繁更新和生成,而其它地方不變,或者某個(gè)部分是所有頁面通用的(比如頁頭和頁腳),較之php下常常使用smarty,生成php文件,雖然靈活性不如php,但是性能上不相上下,還略高.
但是這個(gè)設(shè)計(jì)的問題是動態(tài)內(nèi)容和靜態(tài)內(nèi)容沒有分開,生成的html頁面,和動態(tài)頁面都放在前端服務(wù)器上,通過負(fù)載均衡訪問,也造成了分發(fā)服務(wù)器需要分發(fā)到多臺服務(wù)器,網(wǎng)絡(luò)IO效率較低,而且靜態(tài)內(nèi)容需要的磁盤空間很大,且小文件非常多,和動態(tài)頁面混在一起不便于優(yōu)化,所以第二個(gè)方案對生成的靜態(tài)內(nèi)容與動態(tài)內(nèi)容使用不同的服務(wù)器
方案二:
我們把生成的靜態(tài)文件單獨(dú)放置,可以看到,前端增加Nginx,作為跳轉(zhuǎn),把電影,影人資料庫的頁面轉(zhuǎn)向靜態(tài)服務(wù)器,其他的調(diào)用轉(zhuǎn)向動態(tài)服務(wù)器,這樣我們就可以單獨(dú)為靜態(tài)服務(wù)器進(jìn)行優(yōu)化,比如采用更高效的服務(wù)器等等.
同時(shí)減少了文件分發(fā)的次數(shù)(甚至可以只分發(fā)到本機(jī)),提高生成分發(fā)的處理能力
更進(jìn)一步,可以把圖片服務(wù)分到另外一組機(jī)器上,使用獨(dú)立的域名,比如img.xxx.com,這樣可以有效的減少帶寬
最終完整架構(gòu):
文件生成分發(fā)中心
下圖是文件生成分發(fā)中心的工作流程圖
生成服務(wù)對外只有一個(gè)輸入,就是消息,一個(gè)輸出:靜態(tài)文件,內(nèi)部根據(jù)消息,從配置文件中找到對應(yīng)的生成方法,取出相應(yīng)的模板,進(jìn)行數(shù)據(jù)填充
分發(fā)服務(wù)主要吧生成服務(wù)產(chǎn)生的文件進(jìn)行分發(fā),分發(fā)到前端的N臺服務(wù)器上,開始考慮得比較復(fù)雜,希望分發(fā)服務(wù)可以跨越協(xié)議(本地文件系統(tǒng),局域網(wǎng),http協(xié)議),跨越多種存儲介質(zhì)(文件系統(tǒng),數(shù)據(jù)庫),實(shí)際最后定下來基本是本地文件系統(tǒng)或者局域網(wǎng)傳輸
注:上圖中文件分發(fā)的部分也可以通過定制MogileFS,來實(shí)現(xiàn)分布式文件系統(tǒng)
馬后炮:
總結(jié)起來,靜態(tài)化除了對架構(gòu)方面的影響,對開發(fā)和測試流程也有影響
對測試提出更高的要求:
因?yàn)橐坏┥暇€后,某個(gè)頁面發(fā)現(xiàn)問題,即使是文字的修改,也需要重新生成許多頁面,所以測試人員必須非常仔細(xì),測試周期也需要延長
開發(fā)人員需要掌握模板語言
需要掌握一種模板預(yù)言,無論是Xslt還是自己開發(fā)的模板語言,都需要花一定的時(shí)間掌握
需要給第一次生成騰出足夠時(shí)間:
如果不是新系統(tǒng),那么數(shù)據(jù)遷移和生成的過程就比較痛苦,由于頁面眾多,第一次生成的過程可能需要以天來計(jì)算,在制定上線方案是就需要考慮到這個(gè)方面
Nginx作為前端的跳轉(zhuǎn),根據(jù)其他網(wǎng)站的經(jīng)驗(yàn),應(yīng)該可以達(dá)到2-3萬并發(fā)連接,但是使用之后,常常有卡殼的情況發(fā)生,具體癥狀為在瀏覽器中訪問頁面時(shí),連接超時(shí),或者一直不響應(yīng),此時(shí)Nginx連接數(shù)并不高,好在還有第一套方案可以備用,讓我們有時(shí)間去解決這個(gè)問題,如果大家對這個(gè)問題有什么心得,歡迎交流
我的聯(lián)系方式
MSN:yizhu2000@hotmail.com
Gtalk:yizhu2005@gmail.com
篇后:
在大型web開發(fā)上,我感到微軟產(chǎn)品結(jié)構(gòu)(包括微軟開源社區(qū)的成果)在某些方面還存在一些不足:
高性能服務(wù)器選擇太少
Linux下可以采用Light HTTPd,Nginx等諸多服務(wù)器,這些服務(wù)器在很多方面的表現(xiàn)會讓W(xué)indows下唯一的選擇--IIS相形見絀
分布式文件系統(tǒng)
微軟及其社區(qū)沒有比較著名的產(chǎn)品出現(xiàn),Linux下有MogileFS
微軟架構(gòu)下,文件系統(tǒng)選擇太少:
在Linux下我們可以選擇諸如Ext3,ReiserFS,而Windows環(huán)境下,NTFS是唯一的選擇,不過值得稱道的是.NTFS的效率和穩(wěn)定性都相當(dāng)不錯(cuò).
開源技術(shù)對windows版本的支持態(tài)度不積極
諸多在Linux下名聲卓著的開源產(chǎn)品,又懶于為Windows提供相應(yīng)的版本,或者提供的windows版本效果差強(qiáng)人意.使得采用微軟服務(wù)器的廠商少了很多選擇
現(xiàn)在的Web開發(fā)已經(jīng)進(jìn)入了各種技術(shù)大混合,大整合的時(shí)代,任何一個(gè)廠商都不可能涵蓋所有方面,在后端架構(gòu)和邏輯方面.Net和Java嚴(yán)謹(jǐn),良好的編程風(fēng)格,清晰的設(shè)計(jì)思路,較高的運(yùn)行效率,以及穩(wěn)定的配套服務(wù)支持,是其最大的優(yōu)勢,對主要擅長微軟技術(shù)的Web工程師和架構(gòu)師而言,應(yīng)該增進(jìn)對Linux及開源社區(qū)的了解,才能根據(jù)需求設(shè)計(jì)出合理的架構(gòu)
--------------------------------------------------------------------------------
[1] Message Queuing: A Scalable, Highly Available Load-Balancing Solution
[2] 網(wǎng)絡(luò)負(fù)載平衡(NLB)詳解,注意文章后給出的參考鏈接
[3] 怎樣使用ssi,及其語法:
Nginx下的ssimodule
html.asp.aspx運(yùn)行效率比較
發(fā)表于 @ 2008年09月01日 21:09:00|評論(16)|收藏
新一篇: 匯編語言發(fā)展樹 | 舊一篇: 【轉(zhuǎn)】函數(shù)式編程另類指南youlxsbobo 發(fā)表于2008年9月2日 14:10:21 IP:舉報(bào)
太酷了，有機(jī)會和樓主交流一下，不過樓主這個(gè)網(wǎng)站百萬級PV就說微軟的產(chǎn)品頂不住了，但是想起點(diǎn)中文這樣的網(wǎng)站1億的pv（最高），一般也有千萬，后臺就是微軟的技術(shù)，怎么能頂?shù)米∧?？不知道他們用的什么樣的技術(shù)？pdodge 發(fā)表于2008年9月2日 16:01:59 IP:舉報(bào)
樓主講得很深入，但在web部署不太喜歡用MS的產(chǎn)品pdodge 發(fā)表于2008年9月2日 16:05:12 IP:舉報(bào)
樓主講得很深入，跟我的想法有很多相似點(diǎn)，但在web部署上不太喜歡用MS的產(chǎn)品。a121984376 發(fā)表于2008年9月2日 17:34:07 IP:舉報(bào)
LS的 你發(fā)現(xiàn)沒 起點(diǎn)的網(wǎng)站 網(wǎng)頁基本都是aspxa121984376 發(fā)表于2008年9月2日 17:34:13 IP:舉報(bào)
LS的 你發(fā)現(xiàn)沒 起點(diǎn)的網(wǎng)站 網(wǎng)頁基本都是aspxa121984376 發(fā)表于2008年9月2日 17:34:14 IP:舉報(bào)
LS的 你發(fā)現(xiàn)沒 起點(diǎn)的網(wǎng)站 網(wǎng)頁基本都是aspxa121984376 發(fā)表于2008年9月2日 17:34:14 IP:舉報(bào)
LS的 你發(fā)現(xiàn)沒 起點(diǎn)的網(wǎng)站 網(wǎng)頁基本都是aspxa121984376 發(fā)表于2008年9月2日 17:34:15 IP:舉報(bào)
LS的 你發(fā)現(xiàn)沒 起點(diǎn)的網(wǎng)站 網(wǎng)頁基本都是aspxwangwei155 發(fā)表于2008年9月5日 11:33:18 IP:舉報(bào)
不錯(cuò)的文章，收藏了suan_lai 發(fā)表于2008年9月5日 13:27:35 IP:舉報(bào)
mark!dingzhiming 發(fā)表于2008年9月5日 15:23:33 IP:舉報(bào)
圖文并貌，贊！aiyaoo 發(fā)表于2008年9月6日 15:54:09 IP:舉報(bào)
xuexizhoufoxcn 發(fā)表于2008年9月6日 23:25:47 IP:舉報(bào)
不錯(cuò)，圖文并茂，值得那些想減輕服務(wù)器壓力的開發(fā)人員一讀。我只做過J2EE方面和asp.net方面的，并且都是基于Windows平臺的，樓主的文章不錯(cuò)，繼續(xù)努力。EmilMatthew 發(fā)表于2008年9月7日 19:48:42 IP:舉報(bào)
牛B!
博主的技術(shù)寫作水平是我努力學(xué)習(xí)的方向。chenjing24 發(fā)表于2008年9月8日 23:15:50 IP:舉報(bào)
看看吧！chestnuts 發(fā)表于2009年2月5日 14:45:27 IP:舉報(bào)
精辟,正好用到!太謝謝博主啦!!!
姓 名：
校驗(yàn)碼：重新獲得驗(yàn)證碼
用戶操作
[即時(shí)聊天] [發(fā)私信] [加為好友]
朱燚
訂閱我的博客
朱燚的公告
最近在讀...
文章分類
.net
C++與Win32
Linux代碼研究
python
web前臺
動態(tài)語言
匯編基礎(chǔ)
設(shè)計(jì)模式
數(shù)據(jù)庫
心情雜記
收藏
朋友的blog
ocan的博客
蟈蟈的博客
pc01的專欄
reddream的博客
石頭:p
我的blog
我在博客園的blog
存檔
2009年05月(5)
2009年03月(8)
2008年12月(2)
2008年09月(1)
2008年08月(4)
2008年05月(3)
2008年04月(5)
2008年03月(2)
2008年01月(2)
2007年12月(6)
2007年11月(4)
2007年10月(3)
2007年09月(5)
2007年08月(10)
2007年07月(6)
2007年06月(18)
2007年03月(1)
2007年01月(5)
2006年09月(2)
軟件項(xiàng)目交易
Csdn Blog version 3.1a
Copyright © 朱燚
