大型網站的挑戰主要來自龐大的使用者，高并發的通路和海量資料，任何簡單的業務一旦需要處理數以P計的資料和面對數以億計的使用者，問題就會變得棘手。大型網站架構主要就是解決這類問題。
本文内容大部分來自《大型網站技術架構》，這本書很值得一看，強烈推薦。
大型網站系統的特點
高并發，大流量
需要面對高并發使用者，大流量通路。Google 日均 PV 35 億，日 IP 通路數 3 億；騰訊 QQ 的最大線上使用者數 1.4 億（2011年資料）。
高可用
系統 7 x 24 小時不間斷服務。
海量資料
需要存儲、管理海量資料，需要使用大量伺服器。Facebook 每周上傳的照片數量接近 10 億，百度收錄的網頁數目有數百億，Google 有近百萬台伺服器為全球使用者提供服務。
使用者分布廣泛，網絡情況複雜
許多大型網際網路站都是為全球使用者提供服務的，使用者分布範圍廣，各地網絡情況千差萬别。在國内，還有各個營運商網絡互通難的問題。
安全環境惡劣
由于網際網路的開放性，使得網際網路站更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊。
需求快速變更，釋出頻繁
和傳統軟體的版本釋出頻率不同，網際網路産品為快速适應市場，滿足使用者需求，其産品釋出頻率極高。一般大型網站的産品每周都有新版本釋出上線，中小型網站的釋出更頻繁，有時候一天會釋出幾十次。
漸進式發展
幾乎所有的大型網際網路網站都是從一個小網站開始，漸進地發展起來的。Facebook 是紮克伯格同學在哈佛大學的宿舍裡開發的；Google 的第一台伺服器部署在斯坦福大學的實驗室；阿裡巴巴是在馬雲家的客廳誕生的。好的網際網路産品都是慢慢營運出來的，不是一開始就開發好的，這也正好與網站架構的發展演化過程對應。
大型網站架構演化發展曆程
大型網站的技術挑戰主要來自于龐大的使用者，高并發的通路和海量的資料，任何簡單的業務一旦需要處理數以 P 計的資料和面對數以億計的使用者，問題就會變得很棘手。大型網站架構主要解決這類問題。
初始階段的網站架構
大型網站都是從小型網站發展而來，網站架構也是一樣，是從小型網站架構逐漸演化而來。小型網站最開始沒有太多人通路，隻需要一台伺服器就綽綽有餘，這時的網站架構如下圖所示：
應用程式、資料庫、檔案等所有資源都在一台伺服器上。
應用服務和資料服務分離
随着網站業務的發展，一台伺服器逐漸不能滿足需求：越來越多的使用者通路導緻性能越來越差，越來越多的資料導緻存儲空間不足。這時就需要将應用和資料分離。應用和資料分離後整個網站使用3台伺服器：應用伺服器、檔案伺服器和資料庫伺服器。這 3 台伺服器對硬體資源的要求各不相同：
應用伺服器需要處理大量的業務邏輯，是以需要更快更強大的CPU；
資料庫伺服器需要快速磁盤檢索和資料緩存，是以需要更快的磁盤和更大的記憶體；
檔案伺服器需要存儲大量使用者上傳的檔案，是以需要更大的硬碟。
此時，網站系統的架構如下圖所示：
應用和資料分離後，不同特性的伺服器承擔不同的服務角色，網站的并發處理能力和資料存儲空間得到了很大改善，支援網站業務進一步發展。但是随着使用者逐漸增多，網站又一次面臨挑戰：資料庫壓力太大導緻通路延遲，進而影響整個網站的性能，使用者體驗受到影響。這時需要對網站架構進一步優化。
使用緩存改善網站性能
網站通路的特點和現實世界的财富配置設定一樣遵循二八定律：80% 的業務通路集中在20% 的資料上。既然大部分業務通路集中在一小部分資料上，那麼如果把這一小部分資料緩存在記憶體中，就可以減少資料庫的通路壓力，提高整個網站的資料通路速度，改善資料庫的寫入性能了。 網站使用的緩存可以分為兩種：緩存在應用伺服器上的本地緩存和緩存在專門的分布式緩存伺服器上的遠端緩存。
本地緩存的通路速度更快一些，但是受應用伺服器記憶體限制，其緩存資料量有限，而且會出現和應用程式争用記憶體的情況。
遠端分布式緩存可以使用叢集的方式，部署大記憶體的伺服器作為專門的緩存伺服器，可以在理論上做到不受記憶體容量限制的緩存服務。
使用緩存後，資料通路壓力得到有效緩解，但是單一應用伺服器能夠處理的請求連接配接有限，在網站通路高峰期，應用伺服器成為整個網站的瓶頸。
使用應用伺服器叢集改善網站的并發處理能力
使用叢集是網站解決高并發、海量資料問題的常用手段。當一台伺服器的處理能力、存儲空間不足時，不要企圖去更換更強大的伺服器，對大型網站而言，不管多麼強大的伺服器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一台伺服器分擔原有伺服器的通路及存儲壓力。 對網站架構而言，隻要能通過增加一台伺服器的方式改善負載壓力，就可以以同樣的方式持續增加伺服器不斷改善系統性能，進而實作系統的可伸縮性。應用伺服器實作叢集是網站可伸縮架構設計中較為簡單成熟的一種，如下圖所示：
通過負載均衡排程伺服器，可以将來自使用者浏覽器的通路請求分發到應用伺服器叢集中的任何一台伺服器上，如果有更多使用者，就在叢集中加入更多的應用伺服器，使應用伺服器的壓力不再成為整個網站的瓶頸。
資料庫讀寫分離
網站在使用緩存後，使對大部分資料讀操作通路都可以不通過資料庫就能完成，但是仍有一部分讀操作（緩存通路不命中、緩存過期）和全部的寫操作都需要通路資料庫，在網站的使用者達到一定規模後，資料庫因為負載壓力過高而成為網站的瓶頸。 目前大部分的主流資料庫都提供主從熱備功能，通過配置兩台資料庫主從關系，可以将一台資料庫伺服器的資料更新同步到另一台伺服器上。網站利用資料庫的這一功能，實作資料庫讀寫分離，進而改善資料庫負載壓力。如下圖所示：
應用伺服器在寫資料的時候，通路主資料庫，主資料庫通過主從複制機制将資料更新同步到從資料庫，這樣當應用伺服器讀資料的時候，就可以通過從資料庫獲得資料。為了便于應用程式通路讀寫分離後的資料庫，通常在應用伺服器端使用專門的資料通路子產品，使資料庫讀寫分離對應用透明。
使用反向代理和 CDN 加速網站響應
随着網站業務不斷發展，使用者規模越來越大，由于中國複雜的網絡環境，不同地區的使用者通路網站時，速度差别也極大。有研究表明，網站通路延遲和使用者流失率正相關，網站通路越慢，使用者越容易失去耐心而離開。為了提供更好的使用者體驗，留住使用者，網站需要加速網站通路速度。主要手段有使用 CDN 和方向代理。如下圖所示：
CDN 和反向代理的基本原理都是緩存。
CDN 部署在網絡提供商的機房，使使用者在請求網站服務時，可以從距離自己最近的網絡提供商機房擷取資料
反向代理則部署在網站的中心機房，當使用者請求到達中心機房後，首先通路的伺服器是反向代理伺服器，如果反向代理伺服器中緩存着使用者請求的資源，就将其直接傳回給使用者
使用 CDN 和反向代理的目的都是盡早傳回資料給使用者，一方面加快使用者通路速度，另一方面也減輕後端伺服器的負載壓力。
使用分布式檔案系統和分布式資料庫系統
任何強大的單一伺服器都滿足不了大型網站持續增長的業務需求。資料庫經過讀寫分離後，從一台伺服器拆分成兩台伺服器，但是随着網站業務的發展依然不能滿足需求，這時需要使用分布式資料庫。檔案系統也一樣，需要使用分布式檔案系統。如下圖所示：
分布式資料庫是網站資料庫拆分的最後手段，隻有在單表資料規模非常龐大的時候才使用。不到不得已時，網站更常用的資料庫拆分手段是業務分庫，将不同業務的資料部署在不同的實體伺服器上。
使用 NoSQL 和搜尋引擎
随着網站業務越來越複雜，對資料存儲和檢索的需求也越來越複雜，網站需要采用一些非關系資料庫技術如 NoSQL 和非資料庫查詢技術如搜尋引擎。如下圖所示：
NoSQL 和搜尋引擎都是源自網際網路的技術手段，對可伸縮的分布式特性具有更好的支援。應用伺服器則通過一個統一資料通路子產品通路各種資料，減輕應用程式管理諸多資料源的麻煩。
業務拆分
大型網站為了應對日益複雜的業務場景，通過使用分而治之的手段将整個網站業務分成不同的産品線。如大型購物交易網站都會将首頁、商鋪、訂單、買家、賣家等拆分成不同的産品線，分歸不同的業務團隊負責。
具體到技術上，也會根據産品線劃分，将一個網站拆分成許多不同的應用，每個應用獨立部署。應用之間可以通過一個超連結建立關系（在首頁上的導航連結每個都指向不同的應用位址），也可以通過消息隊列進行資料分發，當然最多的還是通過通路同一個資料存儲系統來構成一個關聯的完整系統，如下圖所示：
分布式服務
随着業務拆分越來越小，存儲系統越來越龐大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難。由于所有應用要和所有資料庫系統連接配接，在數萬台伺服器規模的網站中，這些連接配接的數目是伺服器規模的平方，導緻資料庫連接配接資源不足，拒絕服務。
既然每一個應用系統都需要執行許多相同的業務操作，比如使用者管理、商品管理等，那麼可以将這些共用的業務提取出來，獨立部署。由這些可複用的業務連接配接資料庫，提供共用業務服務，而應用系統隻需要管理使用者界面，通過分布式服務調用共用業務服務完成具體業務操作。如下圖所示：