大型網站的演變過程

前言

隨着互聯網的不斷髮展，以及網站負載的不斷增高，一個成熟網站的架構須要知足下面的幾點，才能爲用戶提供穩定可用的服務

• 高併發、大流量：PV 量巨大；
• 高可用：7*24 小時不間斷服務；
• 海量數據：文件數目分分鐘 xxTB；
• 用戶分佈普遍，網絡狀況複雜：網絡運營商；
• 安全環境惡劣：黑客的攻擊；
• 需求快速變動，發佈頻繁：快速適應市場，知足用戶需求；
• 漸進式發展：慢慢地運營出大型網站；

目標

解決了上述問題以後，咱們須要達到一個什麼樣的目標和目的呢？

每一個目標背後面臨着技術、設計、維護等諸多方面的挑戰； 而目標自己的指望值也會根據實際狀況進行調整，這也意味着網站架構建設是個不斷調整的過程。

有了問題，也定了偉大的目標，那麼網站在不一樣階段面對不一樣的問題，是如何解決的？又是如何一步步成長爲大型網站架構，實現這些偉大的目標呢？

架構體系演進

1. 單機時代

草根時期，快速開發網站並上線。固然，一般只是先試水，用戶規模也沒有造成，經濟能力和投入也很是有限。應用程序、數據庫、文件等全部資源都集中在一臺 Server上，典型案例：基於 LAMP 架構的 PHP 網站；

優勢：簡單、快速迭代達成業務目標；
缺點：存在單點、談不上高可用；
技術點：應用設計要保證可擴展；

2. 緩存出場

當網站發展到有必定的業務量和用戶規模，網站的訪問速度變慢，主要瓶頸是在數據庫上，因此此時再用草根時代的架構顯然已經不能知足咱們業務的需求了，那想提高網站速度，就須要解決數據庫上的瓶頸，因而，緩存出場了。

單機時代+緩存

優勢：簡單有效、方便維護；
缺點：存在單點、談不上高可用；
技術點：客戶端（瀏覽器）緩存、前端頁面緩存、頁面片斷緩存、本地數據緩存/數據庫緩存、遠程緩存；

緩存分類：

頁面緩存：客戶端緩存，減小對網站的訪問；
本地緩存：訪問速度快，但數據量有限，減小對DB查詢；
遠程緩存：遠程訪問，能夠集羣，所以容量不受限制；

3. 數據庫和應用邏輯分離

市場反響還不錯，用戶量天天在增加，數據庫瘋狂讀寫，逐漸發現一臺服務器快撐不住了。因而，決定把數據服務和應用邏輯業務作分離。

數據庫和應用邏輯分離

優勢：簡單有效、方便維護、提升不一樣Server對硬件資源的利用率；
缺點：存在單點、談不上高可用；
技術點：文件服務器部署、數據庫服務器，擴展數據訪問模塊；

分離後三臺 Server 對硬件資源的需求各不相同：

應用服務器：須要更快更強大的 CPU；
數據庫服務器：須要更快的硬盤和更大的內存；
文件服務器：須要更大的硬盤；

4. 數據庫主從分離

單臺數據庫也感受快撐不住了，通常都會嘗試作「讀寫分離」。因爲大部分互聯網「讀多寫少」的特性所決定的。Salve的臺數，取決於按業務評估的讀寫比例

數據庫讀寫分離

優勢：簡單有效、下降數據庫單臺壓力；
缺點：讀寫分離，增長程序難度，架構變複雜，維護難度增長；
技術點：數據庫主從同步部署，擴展數據訪問模塊，實現讀寫分離；

5. 應用服務集羣

數據庫層面是緩解了，可是應用程序層面也出現了瓶頸，因爲訪問量增大，加上早期程序員水平有限寫的代碼也很爛，人員流動性也大，很難去維護和優化。因此，很經常使用的辦法仍是「堆機器」。

應用出現瓶頸 負載均衡集羣

優勢：增長服務器和HA機制，系統性能及可用性獲得保證；
缺點：應用之間緩存、Session一致性問題；
技術點：負載均衡；

經過集羣解決高併發、海量數據問題的經常使用手段，實現系統的可伸縮性。經過負載均衡調度器，可將用戶訪問分發到集羣中的某臺 Server 上，應用服務器的負載壓力再也不成爲整個網站的瓶頸

6. 集中式緩存、Session集中存儲

加機器誰都會加，關鍵是加完以後得有效果，加完以後可能會引起一些問題。例如很是常見的：集羣應用之間頁面輸出緩存和本地緩存一致性的問題，Session保存的問題……

集中式緩存 Session集中存儲

優勢：應用之間緩存、Session一致，存儲無限制，能夠擴展；
缺點：不如本地緩存訪問快，緩存服務器、Session服務器等仍存在單點問題；
技術點：緩存服務器部署、Session集中存儲方案；

7. 動靜分離

動靜分離也是提升網站響應速度的一種經常使用方式。將動態請求與靜態請求分離開，儘可能減小對應用服務器的壓力。同時，能夠再進一步對靜態請求，進行緩存，以加快響應速度。能夠須要開發人員配合（把靜態資源放獨立站點下），也能夠不須要開發人員配合（利用7層反向代理來處理，根據後綴名等信息來判斷資源類型）

動靜分離好處

優勢：減輕應用負載壓力，針對靜態文件緩存；
缺點：靜態文件緩存更新失效問題；
技術點：動靜分離、靜態文件緩存方案；

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

使用反向代理和CDN加速網站響應：CDN和反向代理的基本原理都是緩存，區別在於：

• CDN部署在網絡提供商的機房；
• 反向代理則部署在網站的中心機房；

使用 CDN 和反向代理的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另外一方面也減輕後端服務器的負載壓力

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

優勢：減輕應用負載壓力，異地緩存有效解決不一樣地方用戶訪問過慢的問題；
缺點：成本大幅增長，架構進一步複雜化，也維護難度進一步增大，靜態文件緩存更新失效問題；
技術點：CDN、反向代理方案；

9. 使用NoSQL緩存和搜索引擎

到這裏，已經基本作到了DB層面和應用層面的橫向擴展了，能夠開始關注一些其它方面，例如：站內搜索的精準度，對DB的依賴，開始引入全文索引、NoSQL

NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具備更好的支持。應用服務器則經過一個統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩

優缺點

優勢：下降DB依賴；
缺點：單點問題，談不上高可用；
技術點：NoSQL、搜索引擎、分佈式；

到目前爲止，一個可以承載日均百萬級訪問量的中型網站架構基本介紹完了

如何保證高可用

在作擴展知足了基本的性能需求後，咱們會逐漸關注「可用性」（也就是咱們一般聽別人吹牛時說的SLA、幾個9）。如何保證真正「高可用」，也是個難題。

對關鍵應用/服務，作集羣冗餘負載，這也是保證高可用比較經常使用的手段

• 文件系統、數據庫系統集羣；
• 靜態內容服務器集羣；
• CDN服務器集羣；
• 反向代理服務器集羣；
• 負載均衡調度器集羣；
• 分佈式NoSQL服務器集羣；
• 搜索引擎服務器集羣；
• 分佈式緩存服務器集羣；
• 分佈式Session服務器集羣

集羣保證高可用

優勢：集羣負載，保證高可用；
缺點：數據一致性、數據有狀態問題；
技術點：負載調度器、集羣方案；

截止目前爲止，都沒有怎麼去改動應用程序的架構，或者說通俗點，都不怎麼須要大面積的修改代碼。

若是上面那些手段都用光了，仍是支撐不住怎麼辦？不停的加機器也不是辦法啊？

應用垂直拆分

隨着業務愈來愈複雜，網站的功能愈來愈多，雖然部署層面是採用的集羣，可是應用程序架構層面仍是「集中式」的，這樣會致使不少耦合，不便於開發、維護，並且容易「一榮俱損」。因此，一般會把網站拆分出不一樣的子站點來單獨宿主

經過分而治之的手段將整個網站業務分紅不一樣的產品線，如首頁、商鋪、訂單、賣家、買家等拆分紅不一樣的產品線，分歸不一樣的業務團隊負責。各個應用之間能夠經過創建一個超連接創建關係，也能夠經過消息隊列進行數據分發

應用垂直拆分

優勢：下降耦合、分壓；
缺點：應用架構複雜；
技術點：業務抽取拆分

消息隊列

應用、服務之間仍是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了

消息隊列（服務間異步解耦 高吞吐量）

優勢：提升吞吐量、應用、服務之間解耦；
缺點：存在消息消費延遲問題；
技術點：消息隊列技術方案；

分庫分表

最後，再介紹一個大型互聯網公司都用的絕技–分庫分表。我的經驗，不是業務發展和各方面很是迫切，不要輕易走這一步。

由於分庫分表誰都會幹，關鍵是拆完以後怎麼辦。目前，市面上尚未徹底開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。

分庫分表：

• 橫向拆分；
• 縱向拆分；
• 分佈式數據庫訪問層；
• 數據庫中間件（代理）；

總結

上面講述了在網站業務發展的不一樣階段，會面臨不一樣的問題，針對不一樣的問題，會選擇不一樣的架構。大型網站架構就是在不一樣階段時解決不一樣問題的過程當中慢慢演進來的。

最後幾句話，送給有緣的你：

• 一切以解決業務目標爲首要任務；
• 沒有以業務爲目標的任何架構、技術，都是毫無心義的耍流氓；
• 再牛逼的架構、再牛逼的技術，不可以解決業務的問題，你也只能算是會架構、會技術的工匠，而不能算是真正意義上的架構師；
• 業務成就了技術，平臺成就了人，事業成就了人，而不是相反