服務器劃分
對於訪問量大的網站而言，將網站的各個部分拆分分別部署到不一樣服務器上是頗有必要的。例如將圖片和web站點分開。通常而言，在網站的整個服務器部署上分爲以下幾種類型：css
文件服務器：通常存儲系統的相關圖片和文件，給各個子系統提供統一的文件調用html
代理服務器：通常使用linux+Nginx做爲反向代理mysql
web服務器：.net中最經常使用的Web服務器IIS，Mono中通常使用Nginxlinux
應用服務器：負責系統中各個業務邏輯的提供，好比用戶中心，結算中心，支付中心等git
緩存服務器：提供MemCached緩存服務web
數據庫服務器：負責網站數據的提供，通常爲Sqlserver,mysql,oracle等redis
帶寬的計算
假設網站天天要承受100萬pv的訪問量，計算帶寬要涉及到兩個指標(峯值流量和頁面平均大小),帶寬單位爲bps(bit/s)。sql
一、假設峯值流量爲平均流量的5倍；數據庫
二、假設每次訪問的平均頁面大小爲100KB左右。windows
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就導 致了全站都不可用，還有其餘的像調優很差操做（由於機器上部署的應用什麼都要作，根本就沒法進行鍼對性的調優）等因素，根據這樣的分析，開始痛下決心，將 系統根據職責進行拆分，因而一個大型的分佈式應用就誕生了，一般，這個步驟須要耗費至關長的時間，由於會碰到不少的挑戰：
一、拆成分佈式後須要提供一個高性能、穩定的通訊框架，而且須要支持多種不一樣的通訊和遠程調用方式；
二、將一個龐大的應用拆分須要耗費很長的時間，須要進行業務的整理和系統依賴關係的控制等；
三、如何運維（依賴管理、運行情況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分佈式應用。
通過這一步，差很少系統的架構進入相對穩定的階段，同時也能開始採用大量的廉價機器來支撐着巨大的訪問量和數據量，結合這套架構以及這麼屢次演變過程吸收的經驗來採用其餘各類各樣的方法來支撐着愈來愈高的訪問量。
參考：http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html
| 博客地址： | http://www.cnblogs.com/jiekzou/ |
| 博客版權： | 本文以學習、研究和分享爲主，歡迎轉載，但必須在文章頁面明顯位置給出原文鏈接。 若是文中有不妥或者錯誤的地方還望高手的你指出，以避免誤人子弟。若是以爲本文對你有所幫助不如【推薦】一下！若是你有更好的建議，不如留言一塊兒討論，共同進步！ 再次感謝您耐心的讀完本篇文章。 |
而你要的支撐scale out的、分佈式的架構一般這樣考慮問題：
1.storage & cache & replication
rdb sharding(OLTP) + redis cache + hbase(archive)(OLAP)
2.sync & consistency
zookeeper + curator (paxos)
3.stream computing
source : rdb(MySQL、SQL Server、Oracle)、hdfs、hive、hbase
replayble source : kafka
stream computing engine : samza、storm
4.communication
thrift
5.off-line computing
hadoop
6.memory computing & iterative computing
spark
have fun : ]