服務器划分
對於訪問量大的網站而言，將網站的各個部分拆分分別部署到不同服務器上是很有必要的。例如將圖片和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 |
可跨越表空間,不同的物理屬性 |
| 存儲方式 |
分布式 |
集中式 |
| 擴展性 |
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來解決此類問題
參考：
http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html