網站架構之性能優化（轉）

網站從構建之初的不多有人問津，用戶數量較少，併發量較低，到以後的擁有千萬上億用戶，數萬量級的高併發，之間經歷了怎樣的過程，小型網站架構是怎樣逐步演化的，本文簡單探討下這方面的內容，主要參考《大型網站架構設計》，這本書知識點總結的仍是比較全面的。

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. 致使網站依賴錯綜複雜，開發管理維護困難；

簡單總結

驅動網站技術發展的主要力量永遠是網站業務的發展；
網站都是逐漸演化而來的，根據須要靈活應對纔是最重要的；
技術是爲了業務而服務的，永遠不要爲了技術而技術；

轉自：http://www.cnblogs.com/pflee/p/4508232.htm