大型網站技術架構-發展過程

網站都是從小網站一步一步發展爲大型網站的，而這之中的挑戰主要來自於龐大的用戶、安全環境惡劣、高併發的訪問和海量的數據，任何簡單的業務處理，一旦須要處理數以 P 計的數據和麪對數以億計的用戶時，問題就會變的很棘手

下面咱們就來講說這個演變過程：

初始階段

大型網站都是由小型網站演變而來的，網站架構也同樣

小型網站最開始沒有太多人訪問，只須要一臺服務器就綽綽有餘，就像這樣：

應用程序、數據庫、文件等全部資源都在一臺服務器上，一般使用 Linux PHP MySQL Apache 就能夠完成整個項目部署，而後再買個域名，租一個廉價的服務器就能夠開始咱們的網站之旅了

應用服務與數據服務分離

隨着業務的發展，逐漸的一臺服務器已經不能知足需求，這時咱們能夠將 應用與數據分離

分離以後咱們使用到三臺服務器：應用服務器、文件服務器和數據庫服務器，以下所示：

對於這三臺服務器要求各不相同：

• 應用服務器 要處理大量的業務邏輯，因此須要更好更快更強大的 CPU

• 數據庫服務器 須要快速的進行磁盤檢索和數據緩存，所以須要更快的硬盤和更大的內存

• 文件服務器 須要存儲用戶上傳的文件資源，所以須要更大的硬盤存儲空間

應用與數據分離後，各個的職責變得更加專注，網站的性能獲得進一步的提高，但隨着用戶的繼續增長，咱們須要對網站架構進一步優化

使用緩存改善性能

網站的訪問同樣遵循二八定律：80% 的業務訪問集中在 20% 的數據上面

所以咱們要對這一小部分的數據進行緩存來減輕數據庫的訪問壓力，以提升整個網站的數據訪問速度，改善數據庫的讀寫性能

網站的緩存能夠分爲兩種：緩存在應用服務器上的本地緩存和緩存在專門的分佈式緩存服務器上的遠程緩存

• 本地緩存 的訪問速度會快一些，可是受應用服務器內存限制，緩存數據量頗有限，並且會出現內存爭用的狀況

• 遠程分佈式緩存 可使用集羣的方式，部署大內存的服務器做爲專門的緩存服務器，能夠在理論上作到不受內存容量限制的緩存服務

以下所示：

使用緩存後，數據訪問壓力獲得了有效的緩解，但單一的應用服務器可以處理的請求鏈接數有限，在訪問的高峯期，應用服務器又會成爲網站性能的瓶頸

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

使用集羣是網站解決高併發，海量數據問題的經常使用手段，當你縱向提高到必定程度後，那就該開始橫向提高了

當一臺服務器的處理能力不足時，與其換一臺更強大的服務器，不如增長一臺服務器去分擔原有的服務器壓力。對於大型網站而言，不管多麼強大的服務器，都知足不了持續增加的業務需求，更高效的方式就是增長服務器來分擔壓力

對於網站架構而言，若是增添一臺新的服務器能夠改善負載壓力，那麼就可使用一樣的方式來應對源源不斷的業務需求，從而實現系統的可伸縮性

經過負載均衡調度服務器，能夠將用戶請求分發到應用服務器集羣裏的任何一臺服務器上，若是有更多的用戶，能夠增長更多的應用服務器，使應用服務器的負載壓力再也不成爲網站的性能問題

數據庫讀寫分離

在使用了緩存後，大多數的操做不通過數據庫訪問就能完成，但仍有一部分讀操做（緩存訪問未命中，緩存過時）和全部的寫操做須要訪問數據庫，在網站的用戶量達到必定時，數據庫的負載問題就來了

目前大多數的數據庫都支持主從熱備份，經過配置兩臺服務器的主從關係，能夠將一臺數據庫服務器的數據更新同步到另外一臺，網站利用這一功能，實現數據庫讀寫分離，從而進一步改善數據庫負載壓力

應用服務器在寫操做的時候，訪問主數據庫，主數據庫經過主從複製機制把數據同步更新到從數據庫，這樣當應用服務器進行讀操做的時候，就能訪問從數據庫獲取數據

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

CDN 和 反向代理 的基本原理都是緩存

• CDN 部署在網絡供應商的機房，用戶在進行請求時，會從距離最近的網絡供應商機房獲取數據

• 反向代理 則部署在中心機房，當用戶請求到達中心機房後，會首先訪問反向代理服務器，若是反向代理服務器中緩存這用戶請求的資源，就直接返回給用戶

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

使用分佈式文件系統和分佈式數據庫系統

隨着網站業務的繼續發展，這時候就能夠像分佈式應用服務器同樣，對數據庫系統和文件系統進行分佈式管理

分佈式數據庫 是網站數據庫拆分的最後手段，通常咱們能夠採起業務分庫，根據不一樣業務的數據庫部署在不一樣的數據庫服務器上

使用 NoSQL 和搜索引擎

這兩個方式都是依賴於互聯網的技術手段，應用服務器經過一個統一的數據訪問模塊來訪問各類數據，從而減輕應用程序有多個數據源的麻煩

業務拆分

對於大型網站，咱們能夠分而治之，把整個網站的業務分爲不一樣的模塊，好比大型的交易購物完整能夠分爲首頁、店鋪、訂單、買家等，分別交給不一樣的業務團隊來負責

同時咱們將一個網站根據模塊劃分拆分紅多個應用，每一個應用進行單獨的部署和維護，應用之間經過超連接創建關係（指向不一樣的應用地址），最後經過相同的數據存儲系統來構成一個互相關聯的完整系統

分佈式服務

隨着業務拆分，整個系統愈來愈大，應用的總體複雜度呈指數級增長，部署維護愈來愈困難，而且全部的應用服務器都要與數據庫服務鏈接， 在數萬臺服務器規模的狀況下，這些鏈接的數目是服務器規模的平方，致使資源不足

這時候就要對相同的業務進行提取，獨立部署，把這些可重用的業務和鏈接數據庫等，提取出來做爲公共業務服務，而應用系統只須要經過分佈式服務訪問公共業務服務完成業務操做

到這裏，基本上大多數的技術問題都能獲得解決，還有一些實時同步等具體業務問題也均可以經過現有的技術解決