本文內容
應用服務和數據服務分離
使用緩存改善網站性能
使用應用服務器集羣改善網站的併發處理能力
數據庫讀寫分離
使用反向代理和 CDN 加速網站響應
使用分佈式文件系統和分佈式數據庫系統
使用 NoSQL 和搜索引擎
業務拆分
分佈式服務
本文來自李智慧的《大型網站技術架構——核心原理與案例分析》一書，對於大型網站架構演化做了精闢地說明，書才200多頁，言簡意賅，有興趣可以買來讀讀~
雖然目前（大型）網站不像90年代互聯網剛興起時，什麼都要慢慢摸索，20年後的今天，很多東西都有現成的框架和成熟的解決方案，加之大數據和雲計算有了很好的發展，搭建大型網站不再像當初那麼麻煩，硅谷一些創業公司甚至將站點放在 AWS（亞馬遜雲計算服務）上，但瞭解大型網站架構的演化，還是很有意義的。
大型網站的技術挑戰主要來自龐大的用戶，高併發的訪問和海量的數據，任何簡單的業務一旦需要處理數以P計的數據和麪對數億計的用戶，問題就會變得很棘手。大型網站架構主要就是解決這類問題。
Google 日均 PV（Page View）數 35 億，日均 IP 訪問數 3億；
騰訊 QQ 的最大在線用戶數 1.4 億（2011 年數據）；
淘寶 2012 年“雙十一”活動一天交易額超過 191 億，活動開始第一分鐘訪問用戶達 1000 萬；
2012 年 12306 網站的癱瘓；
京東在 2011 年年末的圖書促銷，由於優惠幅度大引起大量買家訪問，結果導致網站服務不可用，大部分用戶在提交訂單後，頁面顯示“Service is too busy”……；
微信從發佈到擁有 1 億用戶，僅僅用了一年時間；
www.wikipedia.org 創建於 2001 年，到 2012 年已成爲流量排名全球第 6 的大型網站，跟它流量在相同級別的其他大型網站，如 baidu、yahoo，其背後都是市值百億美元、員工上萬的巨無霸企業，運行網站的服務器規模也數以萬計。而 wikipdia 不過只有區區數百臺服務器，並僅由十餘名技術人員維護；
……
注意本文中的架構圖，是如何從圖 1 慢慢“分裂”成圖 10的~
初始階段的網站架構
小型網站最開始時沒有太多人訪問，只需要一臺服務器就綽綽有餘，這時的網站架構如圖 1 所示。
圖 1 初始階段的網站架構
（這是一臺服務器）
應用程序、數據庫、文件等所有的資源都在一臺服務器上。
通常服務器操作系統使用 Linux，應用程序使用 PHP 開發，部署在 Apache 上，數據庫使用 MySQL（這就是 LAMP，Linux+Apache+MySQL+PHP/Python，很常見的技術組合，無論是互聯網之初，還是現在，因爲他們完全是免費開源的），彙集各種免費開源軟件及一臺廉價服務器就可以開始網站的發展之路了。
淘寶最開始，服務器在馬雲家裏。Facebook 最開始在哈佛大學宿舍裏。
應用服務和數據服務分離
隨着網站業務的發展，一臺服務器逐漸不能滿足需求：越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足。這時就需要將應用和數據分離。
應用和數據分離後，整個網站使用三臺服務器，也就是一臺拆成三臺：應用服務器、文件服務器和數據庫服務器。如圖 2 所示。
圖 2 應用服務和數據服務分離
（這是三臺服務器）
這三臺服務器對硬件資源的要求各不相同：
應用服務器需要處理大量的業務邏輯，因此需要更快更強大的CPU；
數據庫服務器需要快速磁盤檢索和數據緩存，因此需要更快的磁盤和更大的內存；
文件服務器需要存儲大量用戶上傳的文件，因此需要更大的磁盤。
應用和數據分離後，不同性能的服務器承擔不同的角色，網站的併發處理能力和數據存儲空間得到了很大改善，支持網站業務進一步發展。但隨着用戶逐漸增多，網站又一次面臨挑戰：數據庫壓力太大，導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響。這時需要對網站架構進一步優化。
另外，數據庫壓力大的問題，在考慮調整架構前，最好確定程序代碼以及SQL是否存在問題，儘量減少數據庫訪問，並優化 SQL 性能，這些對數據庫的性能影響很大。
現在建設網站大都從應用服務和數據服務分離開始。互聯網在中國已經普及，如果你建設了一個網站，大家要是覺得好，可能短時間內就會有大量用戶，比如，微信在兩個月時間內，用戶就過億了，要是應用服務、數據服務和文件服務都在一個臺服務器上，顯然支持不了多久。
使用緩存改善網站性能
網站訪問特點和現實世界的財富分配一樣遵循二八定律：80%的業務訪問集中在20%的數據上。
淘寶買家瀏覽的商品集中在少部分成交數多、評價良好的商品上；
百度搜索關鍵詞集中在少部分熱門詞彙上；
只有經常登錄的用戶纔會發微博、看微博，而這部分用戶也只佔總用戶數量的一小部分。
既然大部分的業務訪問集中在一小部分數據上，那麼如果把這一小部分數據緩存在內存中，是不是就可以減少數據庫的訪問壓力，提高整個網站的數據訪問速度，改善數據庫的寫入性能呢？
網站使用的緩存可以分爲兩種：緩存在應用服務器上的本地緩存和緩存在專門的分佈式緩存服務器上的遠程緩存。如圖 3 所示。
本地緩存的訪問速度更快些，但是受應用服務器的內存限制，其緩存數據量有限，而且會出現和應用程序爭內存的情況。
遠程分佈式緩存可以使用集羣的方式，部署大內存的服務器作爲專門的緩存服務器，可以在理論上做到不受內存容量限制的緩存服務。
圖 3 網站使用緩存
（本地緩存，n 臺遠程緩存服務器）
使用緩存後，數據訪問壓力得到有效緩解，但單一應用服務器能夠處理的請求連接有限，在網站訪問高峯期，應用服務器成爲整個網站的瓶頸。
使用應用服務器集羣改善網站的併發處理能力
使用集羣是網站解決高併發、海量數據問題的常用手段。當一臺服務器的處理能力、存儲空間不足時，不要企圖換更強大的服務器（對大型網站來說，無論多麼強大的服務器，都不能滿足網站持續增長的業務需求），更恰當的做法是增加一臺服務器分擔原有服務器的訪問和存儲壓力。
對網站架構而言，只要能通過增加一臺服務器的方式改善負載壓力，就可以以同樣的方式持續增加服務器來不斷改善系統性能，從而實現系統的可伸縮性。應用服務器實現集羣是網站可伸縮集羣架構設計中較爲簡單成熟的一種。如圖 4 所示。
圖 4 應用服務器集羣
通過負載均衡服務器，可以將來自用戶瀏覽器的訪問請求分發到應用服務器集羣中的任何一臺上，如果有更多的用戶，就在集羣中加入更多的應用服務器，是應用服務器的負載壓力不再成爲整個網站的瓶頸。
以上，都是針對應用服務器方面，進行架構的調整，從最容易下手的地方進行改進。
數據庫讀寫分離
網站在使用緩存後，使絕大部分數據讀操作訪問都可以不通過數據庫就能完成，但是仍有一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作需要訪問數據庫，在網站的用戶達到一定規模後，數據庫因爲負載壓力過高而成爲網站的瓶頸。
目前大部分的主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到另一臺上。網站利用數據庫的這一功能，實現數據庫讀寫分離，從而改善數據庫負載壓力，如圖 5 所示。
圖 5 數據庫讀寫分離
（在圖 4 基礎上，將數據庫讀寫分離，利用數據訪問模塊統一管理，DML 操作使用主數據庫，DQL 操作使用從數據庫）
應用服務器在寫數據時，訪問主數據庫，主數據庫通過主從複製機制將數據更新同步到從數據庫，這樣當應用服務器讀數據時，就可以通過從數據庫獲得數據。爲了便於應用程序訪問讀寫分離後的數據庫，通常在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。
使用反向代理和 CDN 加速網站響應
隨着網站業務不斷髮展，用戶規模越來越大，由於中國複雜的網絡環境，不同地區的用戶訪問網站時，速度差別也極大。有研究表明，網站訪問延遲和用戶流失率正相關。爲了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度。主要手段是使用反向代理和 CND，如圖 6 所示。
圖 6 網站使用反向代理和 CDN 加速訪問
CDN 和反向代理的基本原理都是緩存，區別是：
CDN 部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲得數據；
而反向代理則部署在網站的中心機房，當用戶請求到中心機房後，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。
使用 CDN 和反向代理的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另一個方面也減輕後端服務器的負載壓力。
使用分佈式文件系統和分佈式數據庫系統
任何強大的單一服務器都無法滿足大型網站持續增長的業務需求。上面，數據庫經歷讀寫分離後，從一臺服務器拆分成兩臺，但隨着網站業務的發展依然不能滿足需求，這時需要使用分佈式數據庫。文件系統也是如此，需要使用分佈式文件系統。如圖 7 所示。
圖 7 使用分佈式文件和分佈式數據庫系統
（此時的數據訪問模塊，範圍更大，不僅僅統一了數據庫讀寫，還統一了讀寫文件和讀寫緩存）
分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模非常龐大的時候才使用。不到迫不得已，網站更常用的數據庫拆分手段是業務分庫，將不同業務的數據庫部署在不同的物理服務器上。
使用 NoSQL 和搜索引擎
隨着網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜，網站需要採用一些非關係數據庫技術，如 NoSQL 和非數據庫查詢技術，如搜索引擎，如圖 8 所示。
圖 8 使用 NoSQL 和搜索引擎
NoSQL 和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具有更好的支持。應用服務器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。
業務拆分
大型網站爲了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線，如大型購物交易網站就會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。
具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署維護。應用之間可以通過一個超鏈接建立關係（如，在首頁上的導航鏈接，每個都指向不同的應用地址），也可以通過消息隊列進行數據分發，當然最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統，如圖 9 所示。
圖 9 應用拆分
分佈式服務
隨着業務拆分越來越小，存儲系統越來越大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難。由於所有應用要和所有數據庫系統連接，在數萬臺服務器規模的網站中，這些連接的數量是服務器規模的平方，導致數據庫連接資源不足，拒絕服務。
既然每個應用系統都需要執行許多相同的業務操作，比如，用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的業務連接數據庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分佈式服務器調用共用業務服務完成具體業務操作，如圖 10 所示。
圖 10 分佈式服務