標(biāo)題：新手筆記-網(wǎng)站加速：不是太少，而是太多
關(guān)鍵詞：網(wǎng)站開發(fā)、網(wǎng)站加速方案、合理選型
8月30號： 回憶進(jìn)行網(wǎng)站加速步驟，真是百感交集！
很長時間沒有寫筆記了，網(wǎng)站的工作的確是非常瑣碎。不過真的要做好實(shí)在是很難，下面這個筆記斷斷續(xù)續(xù)寫了兩個月，很多想法又都發(fā)生了變化，所以寫的很亂，請大家對付看吧：）
網(wǎng)站的技術(shù)工作其實(shí)涉及的面非常廣。從網(wǎng)站信息發(fā)布的運(yùn)行平臺的選擇到采編入庫的設(shè)計與開發(fā)，都需要進(jìn)行很多的調(diào)研與方案定制。綜合的進(jìn)行不是簡單的幾篇筆記就可以完成的。這次先對加速的方案進(jìn)行簡單的說明。目前所處的網(wǎng)站采用零零總總的加速方式有很多，下面是對這些加速方式的簡單說明。
解決網(wǎng)站的壓力問題，是所有商業(yè)化的網(wǎng)站都要考慮的事情，從對訪問量的預(yù)期，以及不同時段壓力的不同，都要進(jìn)行綜合的考慮。硬件是最重要考慮的方面。軟件同樣也非常重要。定義的框架是否合適，物理上的數(shù)據(jù)庫是否將讀寫進(jìn)行分離，這些都是在網(wǎng)站的設(shè)計階段要考慮的部分。但遺憾的是，最初網(wǎng)站的設(shè)計者并沒有將這樣都考慮進(jìn)行，而是將問題留到的上線之后再進(jìn)行調(diào)整，這就導(dǎo)致了上線之后的很大壓力。在我們的新版網(wǎng)站剛上線的時候，訪問高峰期數(shù)據(jù)庫服務(wù)器的CPU負(fù)載一直在80%以上，網(wǎng)站服務(wù)器的CPU負(fù)載也保持在平均70%。加速、加速、再加速就成為領(lǐng)導(dǎo)嘴中的問號與感嘆號。
有很多成功的經(jīng)驗(yàn)可以從網(wǎng)上找到，當(dāng)然也不能放過改版之前網(wǎng)站的成功經(jīng)驗(yàn)。于是我們找到了下面幾種加速方法（雖然這個時候再出想有什么加速方法已經(jīng)非常晚了，但也還是要進(jìn)行下去。）
下面是幾種用上的加速方法
1. ASP.net本身的頁面緩存技術(shù)與數(shù)據(jù)緩存技術(shù)
各種的網(wǎng)站開發(fā)語言都會有自己緩存技術(shù)，可以在開發(fā)過程中進(jìn)行運(yùn)用。頁面緩存是將頁面通過在ASPX的頁面上用<%outputcache….%>寫上緩存的時間，緩存的方案。數(shù)據(jù)緩存則可以將幾乎所有ASP.net支持的變量按照你所想要的方式緩存起來，以提供給程序調(diào)用時使用。
2. 針對復(fù)雜的查詢建立索引
除去一開始進(jìn)行的設(shè)計時已經(jīng)建立好的索引，你可能還需要在網(wǎng)站對數(shù)據(jù)庫訪問很大時，用SQL的事務(wù)跟蹤器去找出查詢語句的瓶頸，并為之想出相應(yīng)的方法，比如用存儲過程，為還沒有建立索引的表建好索引，多建幾張臨時表，等等。由于我數(shù)據(jù)庫方面不是很熟，這里就不多說了。
3. 將DB的讀寫進(jìn)行分離
這是前輩們傳下來的寶貴經(jīng)驗(yàn)，同時對SQL數(shù)據(jù)庫進(jìn)行讀寫操作是非常慢的一種數(shù)據(jù)庫訪問方式，比較好的方式是根據(jù)讀寫的壓力不用，分別建立兩類結(jié)構(gòu)完全相同的數(shù)據(jù)庫服務(wù)器，將負(fù)責(zé)寫的那類服務(wù)器的數(shù)據(jù)定時復(fù)制給負(fù)責(zé)讀的服務(wù)器。
4. 將DB與Web服務(wù)器分離
DB與Web服務(wù)器在一臺機(jī)器上會使訪問速度變慢。所以要使得網(wǎng)站加速，這方面也需要進(jìn)行考慮。
5. 將常用的數(shù)據(jù)，以及更新比較少的數(shù)據(jù)形成靜態(tài)文件
網(wǎng)站的開發(fā)，有一些數(shù)據(jù)變化量是非常小的，比如詳細(xì)文章頁面，采編人員將其輸入進(jìn)我們的系統(tǒng)之后，幾乎不進(jìn)變化。這種情況下，可以采用將常用的數(shù)據(jù)定期的生成靜態(tài)的數(shù)據(jù)文件的方法。來對網(wǎng)站進(jìn)行提速。程序可以通過訪問靜態(tài)文件的方式，來達(dá)到提高網(wǎng)站整體速度的目的。
這里要對這個方式進(jìn)行簡單的說明，數(shù)據(jù)庫情況好的時候，對數(shù)據(jù)庫的讀寫是比對文件的讀寫要快的，但是如果大量的對數(shù)據(jù)庫進(jìn)行讀寫，或是每一次都會有比較復(fù)雜的邏輯對數(shù)據(jù)庫進(jìn)行讀操作時，并且在實(shí)時性要求不太高的情況下，不如將這些復(fù)雜的操作每次的生成靜態(tài)的數(shù)據(jù)文件，這樣可以使得程序每次只需要對靜態(tài)文件進(jìn)行讀操作，可以達(dá)到減輕數(shù)據(jù)庫壓力的效果。
還有一個好處是，萬一數(shù)據(jù)庫發(fā)生無法讀取的數(shù)據(jù)故障，那么網(wǎng)站的實(shí)際上是可以運(yùn)營在這些靜態(tài)的數(shù)據(jù)文件之上的，在系統(tǒng)運(yùn)行并不穩(wěn)定的運(yùn)營初期，這樣的數(shù)據(jù)文件是非常有意義。這種加速方式可以對應(yīng)到上面的Asp.net的數(shù)據(jù)緩存。由于所有的數(shù)據(jù)都被存儲成標(biāo)準(zhǔn)的XML格式數(shù)據(jù)文件，所以這種數(shù)據(jù)緩存方式不僅僅可以在Asp.net的應(yīng)用程序使用，也在可以提供給其它的一些應(yīng)用使用，
6. 將被訪問的動態(tài)頁面通過加速程序定時生成靜態(tài)頁面，以提供給用戶一個靜態(tài)的頁面快照。
終級加速方案？可以將動態(tài)頁面定時讀出，另存為靜態(tài)頁面。與Asp.net的頁面緩存相似，唯一區(qū)別是頁面加速可控度高，而且如果Asp.net無法執(zhí)行，靜態(tài)頁面也可以很方便的在其它的HTTP server上使用。
以上所說的是在Asp.net+SQL的環(huán)境下可以采用的網(wǎng)站加速的方式。可以老實(shí)的告訴大家，第5種與第6種方式都是在系統(tǒng)運(yùn)行不穩(wěn)定的情況下，或是對IIS6沒有信心的情況下的產(chǎn)物。我個人并不推薦大家采用。
說完了目前網(wǎng)站所采用的方式之后，想與大家分享一下運(yùn)用這些加速方式之后的體會，以及得到的一些經(jīng)驗(yàn)與教訓(xùn)。希望大家在以后的網(wǎng)站開發(fā)過程中不要重復(fù)同樣的錯誤。
l 加速---不是太少，而是太多
可以從上面所說的得出一個結(jié)論，如果一個網(wǎng)站在設(shè)計與運(yùn)行的過程中，即有數(shù)據(jù)庫級的加速，又有業(yè)務(wù)邏輯層的加速，還有最終頁面級的加速，那么存在問題就會是，是不是所有的加速形式都必須要存在？是不是有你已經(jīng)做了一些沒有意義的費(fèi)工作？實(shí)際上，當(dāng)我重新回頭去看堆積在網(wǎng)站中的所有加速方法時，不禁產(chǎn)生一堆疑問：為什么在我已經(jīng)定義好了頁面緩存之后還要有一堆循環(huán)生成的數(shù)據(jù)文件？為什么數(shù)據(jù)庫的索引都建好之后還要有數(shù)據(jù)級的緩存？什么情況下有了頁面緩存還需要有頁面加速？……，當(dāng)一大堆的為什么出現(xiàn)在你面前時，你才能夠了解，去給一個網(wǎng)站加速的方式不是太少，而是太多，你所要做的是選擇出那些最少，最合適的方案來處理你所要面對的問題，而不是慌慌張張的將你要知道的所有的加速方案都堆砌在網(wǎng)站上，這樣得到的結(jié)果可能就會是網(wǎng)站的更新效率低下，維護(hù)費(fèi)用增加，不確定性也在增加，等等。所以，記住，加速的方法，不是太少，而是太多，要合理進(jìn)行選擇。
l 不要因?yàn)橐淮五e誤而進(jìn)行否決某種方案
如果你試了一下數(shù)據(jù)加速的方法，發(fā)現(xiàn)你的網(wǎng)站的訪問速度沒有得到很好的提高，那么你會怎么樣？放棄后找一條新的路子，還是對仔細(xì)研究你的這次試驗(yàn)的結(jié)果究竟說明了什么？看看我上面的說的，當(dāng)你有太多的選擇時，你可能會對每一項都并不看重，那么你錯了，我的項目組在選擇加速方式的時候走過一些回頭路，這些回頭路都是由于我們提出一個好的方案A，試一下，沒有太好的效果之后馬上放棄，轉(zhuǎn)到另一次的實(shí)驗(yàn)，通過一段時間的運(yùn)行，突然又發(fā)現(xiàn)方案A不好使的原因是由于其它的原因，而不是方案A本身的原因，再回頭使用方案A，又花費(fèi)很多的時間與精力。所以在可以選擇方案很多的情況下，也一定要慎重的考慮，而不要因?yàn)橐淮五e誤而進(jìn)行否決某種方案。
總而言之，網(wǎng)站加速一定是要在開始的設(shè)計階段計劃好，而設(shè)計之后的調(diào)整就是屬于很痛苦的，這個就與面向方面編程（AOP）所說的問題有一些共同的地方。AOP的問題回頭再與大家討論吧。
加速的部分就是這些想法了，歡迎大家與我進(jìn)行溝通，我的MAIL地址是viktoryu@hotmail.com