大型網站架構演化發展歷程

　　前面已經描述了大型網站系統的特色，而對一個大型網站系統，其架構也是重要的一個環節。

　　大型網站技術主要的挑戰來自於龐大的用戶、高併發以及海量的數據這三個方面。大型網站的造成就像一顆大樹的成長，歷盡長時間的磨練，最後枝繁葉茂，服務他人。

初始網站架構結構

         起初的網站鑑於用戶量、訪問量較少，只須要一臺服務器足以，應用程序、數據庫、文件等其全部資源放在一太服務器上就已經足夠知足此時的需求，這時候網站的架構就幾個簡單組成部分以下圖

應用和數據服務分離

　　隨着網站業務需求的發展，愈來愈多的用戶進行訪問，此時一臺服務器漸漸不能知足需求，數據的存儲空間出現屏障。因而應用程序、數據庫、文件三者面臨分離，各自爲首分配一臺服務器，這三臺服務器對硬件的要求各取所需，應用服務器處理大量的業務邏輯，需求更快更大的CPU；數據庫服務器對數據庫的處理須要快速搜索以及緩存，需求對內存更大，對硬盤讀寫能力更迅速；文件服務器需求放入大量的用戶資源，對硬盤空間要求更大。此時的網站的架構組成部分展現以下圖

使用緩存

　　網站的架構進一步改進後能夠知足了業務的發展，可是隨着網站知名度提高，用戶量的進一步增長，訪問數據相比以前越發頻繁，數據庫壓力急劇上升致使網站訪問出現延遲，用戶的性能體驗出現下滑，面臨此時網站出現的性能問題，網站架構設計須要再一次的進化，鑑於網站訪問也遵循二八定律，例如：新浪微博，只有常常登陸的用戶纔會發微博，看微博，而這些用戶對於總用戶數只是冰山一角。既然出現這一現象，那麼緩存這部分的數據是否是能夠解決這現象呢？網站緩存能夠分爲本地緩存和分佈式緩存這兩種，兩者的區別是本地緩存速度快可是受服務器內存限制緩存的數量有限，而分佈式緩存採用的是集羣處理，理論上是能夠避免內存瓶頸。此時網站的架構組成部分以下圖

應用服務器集羣改善網站併發能力

　　使用緩存後，數據庫的壓力獲得緩解，可是在面臨網站高峯期時，應用服務器處理單一的請求鏈接出現瓶頸，萬事都有解決的辦法，只是看你願不肯去想，願不肯去嘗試作，採用集羣，集羣多臺應用程序服務器分佈原有的應用程序服務器，從而實現了系統的可伸縮性，網站架構此時演化成這樣以下圖

數據庫讀寫分離

　　使用緩存，雖然使用戶請求數據操做大部分不直接經過數據庫，可是仍有一部分數據（緩存過時、緩存數據沒有命中）讀寫操做須要訪問數據庫，面對這部分數據，可能出現數據訪問負載壓力，把數據庫讀寫操做分離性能效果理當會如何呢？效果無言而喻。

CDN和反向代理加速網站響應

　　網絡覆蓋範圍地區普遍，造就了網絡環境複雜，從而用戶訪問網站性能體現也各有差別，鑑於這問題，網站架構使用CDN和反向代理以技術加速網站響應，兩者原理都是緩存，CDN能夠從距離用戶最近網絡提供點獲取數據；反向代理則是首先從反向代理服務器中獲取數據。

分佈式文件、數據庫系統

　　任何單一的服務器最後都是知足不了業務需求發展。雖然前面數據庫讀寫分離可以改善數據庫負載壓力可是隨着業務不斷壯大最終仍是難以維持此時使用分佈式數據庫，該技術不到不得以建議不使用，而對於這個技術解決方案更經常使用的使用業務拆分，將不一樣的業務數據庫部署在不一樣的物理服務器上。

NoSQL和搜索引擎

　　該技術對於可伸縮的分佈式提供更好的支持，減輕應用程序管理諸多數據源的麻煩。

業務拆分

　　大型網站日益發展壯大，業務需求愈來愈複雜，使用分而治之手段分離整個網站的業務變成不一樣的產品線。具體到技術上，將一個網站拆分紅許多不一樣的應用，每一個應用獨立部署，而應用與應用之間經過超連接關聯，不過最多的仍是經過訪問同一個數據存儲來構成一個關聯的完整系統。

分佈式服務

　　一個應用系統須要執行相同業務操做，那麼能夠將共同的業務提取出來，獨立部署，由這些可複用的業務鏈接數據庫，提供共用業務服務，而應用系統只須要管理用戶界面，經過分佈式調用共用業務服務完成具體業務操做。

　　大型網站結構演化到這裏，基本上大多數的技術問題都得以解決了，可是事物發展到必定的階段就會擺脫初衷向更強的方向發展。目前許多的大型網站都創建本身的雲平臺，將計算做爲一種資源進行出售。

大型網站架構演化歷經了長時間磨練才發展如此，在過程當中也是出現一些易步入的誤區

　　一味的追隨大公司解決方案，大公司的經驗和成功當然重要，可是不能盲目的追從，要與實際的具體業務需求有所改動；

　　爲了技術而技術，網站技術是爲業務而存在的，可是一味的追求新技術，可能會致使結構技術之路越走越難；

　　企圖用技術解決全部問題，技術雖是解決業務問題的，但也不是萬能鑰匙，有些業務的問題也是能夠經過業務手段解決。

 

　　參考資料：《大型網站技術架構核心原理與案例分析》