大型網站技術架構

原文：segmentfault.com/a/1190000007390358

（點擊文末閱讀原文即可前往）

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

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

初始階段

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

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

應用程序、資料庫、文件等所有資源都在一台伺服器上，通常使用 LinuxPHP MySQLApache 就可以完成整個項目部署，然後再買個域名，租一個廉價的伺服器就可以開始我們的網站之旅了。

應用服務與數據服務分離

隨著業務的發展，逐漸的一台伺服器已經不能滿足需求，這時我們可以將 應用與數據分離

分離之後我們使用到三台伺服器：應用伺服器、文件伺服器和資料庫伺服器，如下所示：

對於這三台伺服器要求各不相同：

• 應用伺服器 要處理大量的業務邏輯，所以需要更好更快更強大的 CPU

• 資料庫伺服器 需要快速的進行磁碟檢索和數據緩存，因此需要更快的硬碟和更大的內存

• 文件伺服器 需要存儲用戶上傳的文件資源，因此需要更大的硬碟存儲空間

應用與數據分離后，各個的職責變得更加專一，網站的性能得到進一步的提升，但隨著用戶的繼續增加，我們需要對網站架構進一步優化。

使用緩存改善性能

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

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

網站的緩存可以分為兩種：緩存在應用伺服器上的本地緩存和緩存在專門的分散式緩存伺服器上的遠程緩存

• 本地緩存 的訪問速度會快一些，但是受應用伺服器內存限制，緩存數據量很有限，而且會出現內存爭用的情況；

• 遠程分散式緩存 可以使用集群的方式，部署大內存的伺服器作為專門的緩存伺服器，可以在理論上做到不受內存容量限制的緩存服務。

如下所示：

使用緩存后，數據訪問壓力得到了有效的緩解，但單一的應用伺服器能夠處理的請求連接數有限，在訪問的高峰期，應用伺服器又會成為網站性能的瓶頸。

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

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

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

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

通過負載均衡調度伺服器，可以將用戶請求分發到應用伺服器集群里的任何一台伺服器上，如果有更多的用戶，可以增加更多的應用伺服器，使應用伺服器的負載壓力不再成為網站的性能問題。

資料庫讀寫分離

在使用了緩存后，大多數的操作不經過資料庫訪問就能完成，但仍有一部分讀操作（緩存訪問未命中，緩存過期）和所有的寫操作需要訪問資料庫，在網站的用戶量達到一定時，資料庫的負載問題就來了

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

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

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

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

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

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

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

使用分散式文件系統和分散式資料庫系統

隨著網站業務的繼續發展，這時候就可以像分散式應用伺服器一樣，對資料庫系統和文件系統進行分散式管理

分散式資料庫 是網站資料庫拆分的最後手段，一般我們可以採取業務分庫，根據不同業務的資料庫部署在不同的資料庫伺服器上

使用 NoSQL 和搜索引擎

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

業務拆分

對於大型網站，我們可以分而治之，把整個網站的業務分為不同的模塊，比如大型的交易購物完整可以分為首頁、店鋪、訂單、買家等，分別交給不同的業務團隊來負責。

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

分散式服務

隨著業務拆分，整個系統越來越大，應用的整體複雜度呈指數級增加，部署維護越來越困難，並且所有的應用伺服器都要與資料庫服務連接， 在數萬台伺服器規模的情況下，這些連接的數目是伺服器規模的平方，導致資源不足

這時候就要對相同的業務進行提取，獨立部署，把這些可重用的業務和連接資料庫等，提取出來作為公共業務服務，而應用系統只需要通過分散式服務訪問公共業務服務完成業務操作

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