大型網站架構之演變過程

　

      咱們知道一個網站都是隨着業務的發展，逐漸演變成幾萬服務器，幾億用戶數的大型網站，經歷了若干年，甚至上十年的

發展成爲大型網站，然而真正親身經歷這個發展過程的人已經很少了，這種人也是拿着公司股票，趕都趕不走的人，因此正因

爲不少人沒有親身經歷過，因此對架構的演變沒有深入的瞭解，包括我本身在內，不過沒吃過豬肉，也看過豬跑。。。

 

一：第一代架構

　　這年頭創業大多都是從窮屌絲開始的，奔着 「快好省」的原則創建網站，將「應用程序」，「文件」，「數據庫」統統放在一臺服務

器上，匆匆的就走上了網站架構之路。

        

        咱們知道業務的發展對技術會有更高的要求，業務的創新會觸動技術的創新，當業務逐漸發展起來的時候，最容易出現的問題就是

」存儲空間「和通用的」性能低下「，這個時候就須要作到」應用程序「和」數據「的分離。

 

二：第二代架構

　  隨着業務規模的擴大，須要將」應用程序「，」文件「，」數據庫「進行分離，用更強大的cpu處理服務器來承載應用程序，記得在上一

家用的cpu就是16核，」文件「的話則須要更大的磁盤空間的服務器，」數據庫「的話須要更大的磁盤和超大內存的服務器，咱們知道

sqlserver仍是很吃內存的，記得用過最大的是120g的內存。

            

      隨着業務規模不斷擴大，訪問人數逐漸增多，咱們也開心了，起碼掙到錢了，而後咱們會發現數據庫開始出現瓶頸了，大量的讀寫操做讓

數據庫出現訪問延遲以及死鎖現象的發生，繼而影響用戶體驗。

 

三：第三代架構

     既然大量的讀寫操做讓數據庫出現瓶頸了，這個時候就要從兩個方面優化讀寫操做

1. 讀操做

　 咱們知道任何東西都是遵照二八原則，也就是網站上常常訪問的東西也就那麼多，對於這種命中率很是高的東西就須要用緩存來處理，

　 減小讀的次數，在攜程裏面的memcache就作了「數據熱度」的操做，對於熱度低的數據會自動從緩存中踢掉。

 

2. 寫操做

    這個有分及時寫和非及時寫，對於非及時寫的數據，咱們能夠採用 「消息隊列」來對寫操做節流，從而緩解數據庫寫入時的瞬時壓力。

      這時候數據庫的讀寫操做獲得了很大的緩解，隨着業務規模的繼續擴大，用戶人數的再次暴增，咱們會發現」應用程序服務器「的CPU

常常高燒不退，被玩爆的次數愈來愈多。

 

四：第四代架構

      既然被爆表了，這時候必須再拉一個應用程序服務器來分攤前端訪問帶來的壓力，作了集羣以後，須要再配一臺」負載均衡調度器「，

不過屌絲公司用的比較多的仍是nginx，高大上的公司都是動輒幾十萬的硬件負載均衡，好比攜程用的就是A10，還有市場上幾十萬F5

等等產品。

      

 

     

　    好了，繼續說說架構的演變，從第四代架構中能夠看到，咱們經過作應用程序層的負載均衡能夠比較完美的解決了在整個架構中讓應

用程序層再也不成爲瓶頸，經過A10，咱們可讓用戶的訪問請求分發到集羣中的任何一臺服務器上，當訪問量繼續膨脹的時候，咱們就可

以繼續在集羣中增長服務器來解決負載的壓力，達到系統的可伸縮性，如今咱們的業務規模像滾雪球同樣愈來愈大，用戶數暴增。。。這

時候咱們緩存中的數據也愈來愈多，雖然咱們用了緩存，可是大量的「緩存過時從新讀取」和「緩存不命中",致使數據庫壓力很是大，這時候

數據庫的壓力成爲了咱們架構中的瓶頸。

 

五： 第五代架構

　　 既然數據庫成爲了咱們第四代架構的瓶頸，這時候必須解決數據庫的壓力問題，最多見的作法也就是「讀寫分離」，將寫和讀的庫進行拆

分來緩解數據庫的壓力。

　　

        如今咱們作了多個庫，寫的時候進主庫，而後數據庫分發到從庫中，而後應用程序在從庫中讀取，這裏爲了讓數據庫對應用程序更加

透明，咱們一般加一個「數據訪問層」，在攜程裏面就是在企業庫上進行了一層封裝以及安全性採用了all in one 模式，能夠看到第五代

架構對數據庫的壓力有了很大的緩解。

        通過幾個月業務噴井式的發展以後，咱們會發現數據庫檢索愈來愈慢，單表數據量已經差很少爆炸了。。。已經嚴重影響到系統性能，

用戶抱怨不斷，這時候「數據檢索」成爲了咱們系統的嚴重瓶頸。

 

六：第六代架構

   既然檢索成了瓶頸，咱們必須對數據庫進行拆分，儘量的減小檢索中的數據量規模以及儘量的優化算法。

  1：業務分庫

      咱們將不一樣的業務分攤到不一樣的業務服務器上，而不是將其耦合在一個數據庫裏面，從而創建起數據庫集羣，分流應用層對數

　　據庫的壓力。

  2：分表

　　能夠採用時間劃分，將三個月以後的數據放入到歷史表裏面，當前表只保存三個月以內的數據，而從極大提供單表的檢索能力。

  3：採用nosql

 　  nosql就是爲了web而生，分詞，系統日誌等等，同樣都讓很多nosql，並且nosql有其天生的負載均衡。

  4：優化算法

　    棧，隊列，二叉樹，哈希 等等變換和非變換的數據結構在這種大數據的場景下能夠獲得靈活運用，這也是區分高級程序員和低等

　　 碼農的一條參考標準。

      當你的架構到這個程度的時候，差不到公司的人數也過千了，這時候咱們的業務會分紅不少產品線的，好比：機票事業部，酒店

事業部，旅遊度假事業部，攻略社區事業部，每一個事業部只會負責本身的產品架構，從而將咱們的架構再次細分，從技術角度看，這些

事業部又能夠提煉出公共的部門，好比登陸模塊，訂單處理等等這些可複用的模塊，能夠相應的成立公共平臺事業部和框架架構部，當

這個架構繼續往下發展的話，就有了如今的各類雲，也就成了各類變錢的工具了，就好比如今的博客園託管在阿里雲之上。。。

 

     OK，網站構架先寫到這裏。