網站服務架構

　伺服器劃分

　　對於訪問量大的網站而言，將網站的各個部分拆分分別部署到不同伺服器上是很有必要的。例如將圖片和web站點分開。一般而言，在網站的整個伺服器部署上分為如下幾種型別：

　　檔案伺服器：一般儲存系統的相關圖片和檔案，給各個子系統提供統一的檔案呼叫

　　代理伺服器：一般使用linux+Nginx作為反向代理

　　web伺服器：.net中最常用的Web伺服器IIS，Mono中一般使用Nginx

　　應用伺服器：負責系統中各個業務邏輯的提供，比如使用者中心，結算中心，支付中心等

　　快取伺服器：提供MemCached快取服務

　　資料庫伺服器：負責網站資料的提供，一般為Sqlserver,mysql,oracle等

　頻寬的計算

　　假設網站每天要承受100萬pv的訪問量，計算頻寬要涉及到兩個指標(峰值流量和頁面平均大小),頻寬單位為bps(bit/s)。

　　1、假設峰值流量為平均流量的5倍；

　　2、假設每次訪問的平均頁面大小為100KB左右。

　　1B=8b---------------------1B/s=8b/s(1Bps=8bps)

　　1KB=1024B ------------- 1KB/s=1024B/s

　　1MB=1024KB------------1Mps=1024KB/s

　　100萬pv訪問量一天平均分佈，摺合每秒大約訪問12次，頁面大小為位元組(Byte),總共訪問頁面大小就是12*100KB=1200KB,1Byte=8bit,則1200KB=9600Kb，9600Kb/1024大約9Mb/s(9Mbps)，我們網站在峰值流量時一定要保持正常訪問，則真實頻寬應該在9M*5=45Mbps左右。

　網站架構的演變過程之一

　　公司剛剛起步，業務量不大，往往可能在某個虛擬主機空間商租用一個虛擬主機和一個資料庫就搭建了一個最基本的網站

 

　網站架構的演變過程之二增加快取

　　隨著業務量增加，使用者的訪問越來越多，網站經常性的打不開，慢，甚至出現資料庫連結達到最大限制數，這個時候需要針對網站做一些優化策略：

• 減少Http請求，壓縮css，js，圖片的大小
• 將Microsoft Ajax Minifier整合到VS2010對JS，CSS進行編譯時壓縮
• 增加頁面快取和增加資料快取處理
• cnblogs上的快取全解析
• 自購伺服器進行IDC託管
• 自購伺服器能夠提升硬體的檔次以及頻寬可以自由控制，一般都是獨享頻寬，相比共享頻寬來說能夠支撐更多的訪問量

 

　網站架構的演變過程之三增加web伺服器

　　當系統訪問量的再度增加，webserver機器的壓力在高峰會上升到比較高，這個時候開始考慮增加一臺WebServer，但是增加一臺WebServer的時候意味著要在兩臺的伺服器上分別建立相同的站點，那麼就會出現如下問題：

　　如何讓訪問分配到這兩臺機器上？Nginx

　　如何保持狀態資訊的同步，例如使用者session等？

　　正常考慮的方案有寫入資料庫、開啟狀態伺服器、cookie、寫入快取等。

　　如何保持資料快取資訊的同步？

　　快取伺服器

　　如何讓上傳檔案這些類似的功能繼續正常？

　　採用檔案伺服器統一管理

　網站架構的演變過程之四分庫，分表，分散式快取

　　通過增加web伺服器享受了一段快速訪問的幸福後，發現系統又開始變慢了，經過查詢，發現資料庫寫入、更新的這些操作的部分資料庫連線的 資源競爭非常激烈，導致了系統變慢，這下怎麼辦呢？

　　分庫

　　分表

　　Memcache,Redis分散式快取

　　水平分割槽 VS 垂直分割槽

 

	水平	垂直
儲存依賴	可跨越DB 可跨越物理機器	可跨越表空間,不同的物理屬性 不能跨DB儲存
儲存方式	分散式	集中式
擴充套件性	Scale Out(橫向擴充套件，增加便宜裝置)	Scale Up(升級裝置)
可用性	無單點	存在單點(DB資料本身)
價格	低廉	適中，甚至昂貴
應用場景	web 2.0

　架構演變過程之五Web園或增加更多WebServer

　　在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了,這個時候可能到了下一個瓶頸，檢視windows的效能計數器發現有大量的阻塞請求，於是可以做Web園或者新增一些webserver伺服器。在這個新增webserver伺服器的過程，有可能會出現如下幾個問題：

　　一臺Nginx伺服器的軟負載已經無法承擔巨大的web訪問量了，可以用硬體負載解決F5或應用從邏輯上做一定的分類，然後分散到不同的軟負載叢集中

　　原有的一些狀態資訊同步、檔案共享等方案可能會出現瓶頸，需要進行改進，也許這個時候會根據情況編寫符合網站業務需求的分散式檔案系統等；

　　在做完這些工作後，開始進入一個看似完美的無限伸縮的時代，當網站流量增加時，應對的解決方案就是不斷的新增webserver。

　架構演變之六讀寫分離和廉價儲存方案

　　通過增加web伺服器享受了一段快速訪問的幸福後，發現系統又開始變慢了，經過查詢，發現資料庫寫入、更新的這些操作的部分資料庫連線的 資源競爭非常激烈，導致了系統變慢，這下怎麼辦呢，讀寫分離,訂閱和釋出

 

　　廉價儲存方案Nosql

　　NoSQL = Not Only SQL 指的是非關係型的資料庫。隨著網際網路web2.0網站的興起，傳統的關聯式資料庫在應付web2.0網站，特別是超大規模和高併發的SNS型別的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的資料庫則由於其本身的特點得到了非常迅速的發展。

　　NoSql資料庫大量應用於微博系統等事務性不強的系統

　　BigTable

　　MongoDB 

　　http://tech.it168.com/topic/2011/10-1/nosqlapp/index.html

　架構演變之七進入大型分散式應用時代和廉價伺服器群夢想時代

　　經過上面這個漫長而痛苦的過程，終於再度迎來了完美的時代，不斷的增加webserver就可以支撐越來越高的訪問量了，但是原來部署在webserver上的那個web應用已經非常龐大 了，當多個團隊都開始對其進行改動時，相當的不方便，複用性也相當糟糕，基本上每個團隊都做了或多或少重複的事情，而且部署和維護也是相當的麻煩，因為龐大的應用包在N臺機器上覆制、啟動都需要耗費不少的時間，出問題的時候也不是很好查，另外一個更糟糕的狀況是很有可能會出現某個應用上的bug就導 致了全站都不可用，還有其他的像調優不好操作（因為機器上部署的應用什麼都要做，根本就無法進行鍼對性的調優）等因素，根據這樣的分析，開始痛下決心，將 系統根據職責進行拆分，於是一個大型的分散式應用就誕生了，通常，這個步驟需要耗費相當長的時間，因為會碰到很多的挑戰：

　　1、拆成分散式後需要提供一個高效能、穩定的通訊框架，並且需要支援多種不同的通訊和遠端呼叫方式；

　　2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關係的控制等；

　　3、如何運維（依賴管理、執行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分散式應用。

　　經過這一步，差不多系統的架構進入相對穩定的階段，同時也能開始採用大量的廉價機器來支撐著巨大的訪問量和資料量，結合這套架構以及這麼多次演變過程吸取的經驗來採用其他各種各樣的方法來支撐著越來越高的訪問量。

　CDN內容分發網路

　　什麼是CDN？

　　CDN的全稱是Content Delivery Network，即內容分發網路。其目的是通過在現有的Internet中增加一層新的網路架構，將網站的內容釋出到最接近使用者的網路”邊緣”，使使用者可 以就近取得所需的內容，解決Internet網路擁塞狀況，提高使用者訪問網站的響應速度。從技術上全面解決由於網路頻寬小、使用者訪問量大、網點分佈不均等 原因，解決使用者訪問網站的響應速度慢的根本原因。

　　狹義地講，內容分釋出網路(CDN)是一種新型的網路構建方式，它是為能在傳統的IP網釋出寬頻豐富媒體而特別優化的網路覆蓋層；而從廣義的角 度，CDN代表了一種基於質量與秩序的網路服務模式。簡單地說，內容釋出網路(CDN)是一個經策略性部署的整體系統，包括分散式儲存、負載均衡、網路請 求的重定向和內容管理４個要件，而內容管理和全域性的網路流量管理(Traffic Management)是CDN的核心所在。通過使用者就近性和伺服器負載的判斷，CDN確保內容以一種極為高效的方式為使用者的請求提供服務。總的來說，內 容服務基於快取伺服器，也稱作代理快取(Surrogate)，它位於網路的邊緣，距使用者僅有”一跳”(Single Hop)之遙。同時，代理快取是內容提供商源伺服器（通常位於CDN服務提供商的資料中心）的一個透明映象。這樣的架構使得CDN服務提供商能夠代表他們 客戶，即內容供應商，向終端使用者提供儘可能好的體驗，而這些使用者是不能容忍請求響應時間有任何延遲的。據統計，採用CDN技術，能處理整個網站頁面的 70%～95％的內容訪問量，減輕伺服器的壓力，提升了網站的效能和可擴充套件性。

　　CDN 的工作原理

　　在描述CDN的實現原理，讓我們先看傳統的未加快取服務的訪問過程，以便了解CDN快取訪問方式與未加快取訪問方式的差別：

　　由上圖可見，使用者訪問未使用CDN快取網站的過程為:

　　1)、使用者向瀏覽器提供要訪問的域名；

　　2)、瀏覽器呼叫域名解析函式庫對域名進行解析，以得到此域名對應的IP地址；

　　3)、瀏覽器使用所得到的IP地址，域名的服務主機發出資料訪問請求；

　　4)、瀏覽器根據域名主機返回的資料顯示網頁的內容。

　　CDN的通俗理解就是網站加速，可以解決跨運營商，跨地區，伺服器負載能力過低，頻寬過少等帶來的網站開啟速度慢等問題。網宿，睿江，藍訊

　一致性Hash演算法

　　分散式架構中，節點的故障是不可避免的，當新增和刪除某一節點時，會導致大量雜湊資料失效，需要重新雜湊。這意味著這些丟失的資料要去資料庫中請求一次以後才能按照hash(key) /伺服器數 =伺服器編號 重新雜湊快取到對應的伺服器上。這對於高訪問量的系統來講影響是非常大的。

　　人們採用一致性Hash來解決此類問題

　　更多：一致性Hash演算法(KetamaHash)的c#實現

　　參考：

　　http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html

　　CDN