網站服務架構

 

服務器劃分

       對於訪問量大的網站而言，將網站的各個部分拆分分別部署到不一樣服務器上是頗有必要的。例如將圖片和web站點分開。通常而言，在網站的整個服務器部署上分爲以下幾種類型：

       文件服務器：通常存儲系統的相關圖片和文件，給各個子系統提供統一的文件調用

       代理服務器：通常使用linux+Nginx做爲反向代理

       web服務器：.net中最經常使用的Web服務器IIS，Mono中通常使用Nginx

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

       緩存服務器：提供MemCached緩存服務

       數據庫服務器：負責網站數據的提供，通常爲Sqlserver,mysql,oracle等

帶寬的計算

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

       一、假設峯值流量爲平均流量的5倍；

       二、假設每次訪問的平均頁面大小爲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就導 致了全站都不可用，還有其餘的像調優很差操做（由於機器上部署的應用什麼都要作，根本就沒法進行鍼對性的調優）等因素，根據這樣的分析，開始痛下決心，將 系統根據職責進行拆分，因而一個大型的分佈式應用就誕生了，一般，這個步驟須要耗費至關長的時間，由於會碰到不少的挑戰：
一、拆成分佈式後須要提供一個高性能、穩定的通訊框架，而且須要支持多種不一樣的通訊和遠程調用方式；
二、將一個龐大的應用拆分須要耗費很長的時間，須要進行業務的整理和系統依賴關係的控制等；
三、如何運維（依賴管理、運行情況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分佈式應用。
通過這一步，差很少系統的架構進入相對穩定的階段，同時也能開始採用大量的廉價機器來支撐着巨大的訪問量和數據量，結合這套架構以及這麼屢次演變過程吸收的經驗來採用其餘各類各樣的方法來支撐着愈來愈高的訪問量。

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