之前也有看過一些介紹大型HTTP://www.aliyun.com/zixun/aggregation/11116.html">網站架構演變的文章,例如LiveJournal的、ebay的,都是非常值得參考的, 不過感覺他們講的更多的是每次演變的結果,而沒有很詳細的講為什麼需要做這樣的演變,再加上近來感覺有不少同學都很難明白為什麼一個網站需要那麼複雜的技術,於是有了寫這篇文章的想法, 在這篇文章中將闡述一個普通的網站發展成大型網站過程中的一種較為典型的架構演變歷程和所需掌握的知識體系,希望能給想從事互聯網行業的同學一點初步的概念,文中的不對之處也請各位多給點建議,讓本文真正起到抛磚引玉的效果。
架構演變第一步:物理分離webserver和資料庫
最開始,由於某些想法,於是在互聯網上搭建了一個網站,這個時候甚至有可能主機都是租借的,但由於這篇文章我們只關注架構的演變歷程,因此就假設這個時候已經是託管了一台主機,並且有一定的頻寬了,這個時候由於網站具備了一定的特色, 吸引了部分人訪問,逐漸你發現系統的壓力越來越高,回應速度越來越慢,而這個時候比較明顯的是資料庫和應用互相影響,應用出問題了,資料庫也很容易出現問題,而資料庫出問題的時候,應用也容易出問題, 於是進入了第一步演變階段:將應用和資料庫從物理上分離,變成了兩台機器,這個時候技術上沒有什麼新的要求,但你發現確實起到效果了,系統又恢復到以前的回應速度了,並且支撐住了更高的流量,並且不會因為資料庫和應用形成互相的影響。
看看這一步完成後系統的圖示:
這一步涉及到了這些知識體系:
這一步架構演變對技術上的知識體系基本沒有要求。
架構演變第二步:增加頁面緩存
好景不長,隨著訪問的人越來越多,你發現回應速度又開始變慢了,查找原因,發現是訪問資料庫的操作太多,導致資料連線競爭激烈,所以回應變慢,但資料庫連接又不能開太多,否則資料庫機器壓力會很高, 因此考慮採用緩存機制來減少資料庫連接資源的競爭和對資料庫讀的壓力,這個時候首先也許會選擇採用squid等類似的機制來將系統中相對靜態的頁面(例如一兩天才會有更新的頁面)進行緩存(當然,也可以採用將頁面靜態化的方案), 這樣程式上可以不做修改,就能夠很好的減少對webserver的壓力以及減少資料庫連接資源的競爭,OK,於是開始採用squid來做相對靜態的頁面的緩存。
看看這一步完成後系統的圖示:
這一步涉及到了這些知識體系:
前端頁面緩存技術,例如squid,如想用好的話還得深入掌握下squid的實現方式以及緩存的失效演算法等。