網站從構建之初的很少有人問津，用戶數量較少，並發量較低，到之后的擁有千萬上億用戶，數萬量級的高並發，之間經歷了怎樣的過程，小型網站架構是怎樣逐步演化的，本文簡單探討下這方面的內容，主要參考《大型網站架構設計》，這本書知識點總結的還是比較全面的。
1. 初始階段
網站開始是沒有太多訪問量的，只需一台服務器就綽綽有余了，應用程序，數據庫，靜態資源等全部都在一台服務器上，一般使用LAMP/LNMP（Linux+Apache/Nginx+MySQL+PHP/Python等）就可以實現自己的網站了，具體架構如下所示：
2. 應用服務與數據服務分離
隨着網站業務的發展，用戶訪問量的增加，存儲數據的增長，單台服務器逐漸不能滿足需求，需要將應用服務與數據服務分離，具體如下圖所示：
由於負責提供的服務不同，每台服務器對硬件資源的需求是不同的，具體如下所示：
| 服務器類型 | 處理業務 | 所需資源 |
| 應用服務器 | 處理所有業務邏輯 | 更快、更多CPU |
| 文件服務器 | 存儲用戶上傳文件或服務自身所需文件資源 | 更大的磁盤空間 |
| 數據庫服務器 | 做數據緩存以及進行數據檢索 | 更大的內存以及更快的磁盤 |
3. 緩存
隨着用戶逐漸增多，數據庫壓力太大，導致訪問延遲，影響用戶體驗，而網站性能優化最優先考慮的就是緩存；
網站訪問特點所遵循的二八定律：80%的業務訪問集中在20%的數據上；
網站使用緩存又可分為應用服務器本地緩存和遠程分布式緩存，遠程分布式緩存一般可采用集群的方式部署，對服務器內存有比較高的要求，具體如下圖所示：
4. 應用服務器集群部署
隨着訪問量進一步增大，單台應用服務器已逐漸不能應對越來越多的請求連接，單台服務器硬件資源再強，也會逐漸滿足不了業務高峰時的負載壓力；
網站解決高並發、海量數據問題最常用的手段還是使用集群，做橫向擴展，集群可以很好地滿足伸縮性；
負載均衡服務器實現可以有比較多的方案，LVS，Nginx，F5等，可以和HA軟件，如Heartbeat與Keepalived等一起使用；
通過應用服務器集群部署，使用負載均衡調度器，可以將用戶的請求分發到多台應用服務器集群中的任一台機器上，而且根據用戶訪問量的多少，可以很容易增刪服務器，是每台服務器負載都在可接受范圍之內，具體如下圖所示：
5. 數據庫讀寫分離
對於緩存沒命中和緩存過期的數據，仍需要從數據庫中來讀取，並且所有寫操作也都需要訪問數據庫，數據庫壓力還是會隨着訪問量增加而增大；
可采用主從熱備的方案，實現讀寫分離，例如mysql的master-slave模式，當讀操作量級更高時，還可采用一主多從的方式來實現；
應用程序中的數據訪問模塊需要保證數據庫的讀寫分離對應用透明；
具體如下圖所示：
6. 使用CDN和反向代理加速網站
中國網絡環境復雜，不同地區用戶訪問相同網站，速度差別較大，而網站訪問延時和用戶流失率正相關；
主要加速網站訪問速度，減輕后端服務器負載壓力的方式就是使用CDN和反向代理；
CDN和反向代理的基本原理都是緩存：
CDN部署在網絡提供商的機房，緩存網站的一些熱點靜態資源，用戶在請求網站服務時，從距離自己最近的網絡提供商機房獲取數據，如視頻、圖片等；
反向代理部署在網站的中心機房，屬於網站前端架構的一部分，當用戶請求到達中心機房后，首先訪問反向代理服務器，如果緩存着用戶請求的資源（靜態），就直接返回；
反向代理比較成熟的開源軟件：Squid、Varnish，推薦使用Varnish，從穩定性、訪問速度、並發連接數目比較來看，Varnish都更強大一點；
使用緩存的前提條件： 1. 數據訪問熱點不均衡，某些數據會被頻繁訪問； 2. 數據在某個時間段內有效，不會很快過期，否則可能造成緩存數據已經失效，產生臟讀，影響結果正確性
具體如下圖所示：
7. 分布式文件系統和分布式數據庫系統
隨着業務量的增長，網站最常用的數據庫拆分是按業務分庫，將不同業務的數據庫部署在不同的服務器上；
一般分布式數據庫是網站數據庫拆分的最后手段，只有在單表規模非常龐大的時候才使用；
具體如下圖所示：
8. 使用NoSQL和搜索引擎
全文檢索對於大型網站來說已成為不可或缺的一部分，例如Lucene、Solr等；
對非格式化的數據使用NoSQL存儲更為方便，NoSQL也更適合大數據計算，較為流行的NoSQL數據庫有HBase、MongoDB、CouchDB、Redis、Cassandra等；
不同NoSQL數據庫使用的存儲方式不同，例如Redis，Memcache等采用的是Key/Value鍵值對存儲，MongoDB，CouchDB等采用的是按文檔存儲，一條記錄中所有數據都存儲在文檔中，HBase，Cassandra等采用的是列存儲；
具體如下圖所示：
9. 按業務拆分
網站在發展壯大之后，往往包含了多種復雜的業務場景，使用分而治之的手段將整個網站業務分成不同的產品線，將網站拆分成多個不同的應用，每個應用獨立部署維護，應用之間可以通過超鏈接、消息隊列等關聯起來，具體如下圖所示：
10. 分布式服務
在上面業務拆分的基礎上，將一些公共的業務抽取出來，獨立部署，如給用戶管理、商品管理等，這些可復用的業務連接數據庫，提供公共服務，而應用系統只需管理用戶界面；
具體如下圖所示：
分布式主要還是為了解決高並發問題，但也引入了一些其他問題： 1. 服務調用必須通過網絡，可能會對性能造成較大影響； 2. 服務器越多，故障概率越大，一台服務器宕機可能會導致連鎖反應（滾雪球效應），導致很多應用不可訪問，網站可用性降低，設計時應盡量避免； 3. 數據在分布式環境保持數據一致性也比較困難，分布式事務難以保證，這對網站業務正確性和業務流程可能造成影響； 4. 導致網站依賴錯綜復雜，開發管理維護困難；
簡單總結
驅動網站技術發展的主要力量永遠是網站業務的發展； 網站都是逐漸演化而來的，根據需要靈活應對才是最重要的； 技術是為了業務而服務的，永遠不要為了技術而技術；
網站性能優化
詳見：網站架構之性能優化