服務(wù)器劃分
對于訪問量大的網(wǎng)站而言，將網(wǎng)站的各個(gè)部分拆分分別部署到不同服務(wù)器上是很有必要的。例如將圖片和web站點(diǎn)分開一般而言，在網(wǎng)站的整個(gè)服務(wù)器部署上分為如下幾種類型：
文件服務(wù)器：一般存儲系統(tǒng)的相關(guān)圖片和文件，給各個(gè)子系統(tǒng)提供統(tǒng)一的文件調(diào)用
代理服務(wù)器：一般使用linux+Nginx作為反向代理
web服務(wù)器：.net中最常用的Web服務(wù)器IIS，Mono中一般使用Nginx
應(yīng)用服務(wù)器：負(fù)責(zé)系統(tǒng)中各個(gè)業(yè)務(wù)邏輯的提供，比如用戶中心，結(jié)算中心，支付中心等
緩存服務(wù)器：提供MemCached緩存服務(wù)
數(shù)據(jù)庫服務(wù)器：負(fù)責(zé)網(wǎng)站數(shù)據(jù)的提供，一般為Sqlserver,mysql,oracle等
帶寬的計(jì)算
假設(shè)網(wǎng)站每天要承受100萬pv的訪問量，計(jì)算帶寬要涉及到兩個(gè)指標(biāo)(峰值流量和頁面平均大小),帶寬單位為bps(bit/s)。
1、假設(shè)峰值流量為平均流量的5倍；
2、假設(shè)每次訪問的平均頁面大小為100KB左右。
1B=8b---------------------1B/s=8b/s(1Bps=8bps)
1KB=1024B ------------- 1KB/s=1024B/s
1MB=1024KB------------1Mps=1024KB/s
100萬pv訪問量一天平均分布，折合每秒大約訪問12次，頁面大小為字節(jié)(Byte),總共訪問頁面大小就是12*100KB=1200KB,1Byte=8bit,則1200KB=9600Kb，9600Kb/1024大約9Mb/s(9Mbps)，我們網(wǎng)站在峰值流量時(shí)一定要保持正常訪問，則真實(shí)帶寬應(yīng)該在9M*5=45Mbps左右。
網(wǎng)站架構(gòu)的演變過程之一
公司剛剛起步，業(yè)務(wù)量不大，往往可能在某個(gè)虛擬主機(jī)空間商租用一個(gè)虛擬主機(jī)和一個(gè)數(shù)據(jù)庫就搭建了一個(gè)最基本的網(wǎng)站
網(wǎng)站架構(gòu)的演變過程之二增加緩存
隨著業(yè)務(wù)量增加，用戶的訪問越來越多，網(wǎng)站經(jīng)常性的打不開，慢，甚至出現(xiàn)數(shù)據(jù)庫鏈接達(dá)到最大限制數(shù)，這個(gè)時(shí)候需要針對網(wǎng)站做一些優(yōu)化策略：
減少Http請求，壓縮css，js，圖片的大小
將Microsoft Ajax Minifier集成到VS2010對JS，CSS進(jìn)行編譯時(shí)壓縮
增加頁面緩存和增加數(shù)據(jù)緩存處理
cnblogs上的緩存全解析
自購服務(wù)器進(jìn)行IDC托管
自購服務(wù)器能夠提升硬件的檔次以及帶寬可以自由控制，一般都是獨(dú)享帶寬，相比共享帶寬來說能夠支撐更多的訪問量
網(wǎng)站架構(gòu)的演變過程之三增加web服務(wù)器
當(dāng)系統(tǒng)訪問量的再度增加，webserver機(jī)器的壓力在高峰會(huì)上升到比較高，這個(gè)時(shí)候開始考慮增加一臺WebServer，但是增加一臺WebServer的時(shí)候意味著要在兩臺的服務(wù)器上分別建立相同的站點(diǎn)，那么就會(huì)出現(xiàn)如下問題：
如何讓訪問分配到這兩臺機(jī)器上？Nginx
如何保持狀態(tài)信息的同步，例如用戶session等？
正?？紤]的方案有寫入數(shù)據(jù)庫、開啟狀態(tài)服務(wù)器、cookie、寫入緩存等。
如何保持?jǐn)?shù)據(jù)緩存信息的同步？
緩存服務(wù)器
如何讓上傳文件這些類似的功能繼續(xù)正常？
采用文件服務(wù)器統(tǒng)一管理
網(wǎng)站架構(gòu)的演變過程之四分庫，分表，分布式緩存
通過增加web服務(wù)器享受了一段快速訪問的幸福后，發(fā)現(xiàn)系統(tǒng)又開始變慢了，經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的 資源競爭非常激烈，導(dǎo)致了系統(tǒng)變慢，這下怎么辦呢？
分庫
分表
Memcache,Redis分布式緩存
水平分區(qū) VS 垂直分區(qū)
水平
垂直
存儲依賴
可跨越DB
可跨越物理機(jī)器
可跨越表空間,不同的物理屬性
不能跨DB存儲
存儲方式
分布式
集中式
擴(kuò)展性
Scale Out(橫向擴(kuò)展，增加便宜設(shè)備)
Scale Up(升級設(shè)備)
可用性
無單點(diǎn)
存在單點(diǎn)(DB數(shù)據(jù)本身)
價(jià)格
低廉
適中，甚至昂貴
應(yīng)用場景
web 2.0
架構(gòu)演變過程之五Web園或增加更多WebServer
在做完分庫分表這些工作后，數(shù)據(jù)庫上的壓力已經(jīng)降到比較低了,這個(gè)時(shí)候可能到了下一個(gè)瓶頸，查看windows的性能計(jì)數(shù)器發(fā)現(xiàn)有大量的阻塞請求，于是可以做Web園或者添加一些webserver服務(wù)器。在這個(gè)添加webserver服務(wù)器的過程，有可能會(huì)出現(xiàn)如下幾個(gè)問題：
一臺Nginx服務(wù)器的軟負(fù)載已經(jīng)無法承擔(dān)巨大的web訪問量了，可以用硬件負(fù)載解決F5或應(yīng)用從邏輯上做一定的分類，然后分散到不同的軟負(fù)載集群中
原有的一些狀態(tài)信息同步、文件共享等方案可能會(huì)出現(xiàn)瓶頸，需要進(jìn)行改進(jìn)，也許這個(gè)時(shí)候會(huì)根據(jù)情況編寫符合網(wǎng)站業(yè)務(wù)需求的分布式文件系統(tǒng)等；
在做完這些工作后，開始進(jìn)入一個(gè)看似完美的無限伸縮的時(shí)代，當(dāng)網(wǎng)站流量增加時(shí)，應(yīng)對的解決方案就是不斷的添加webserver。
架構(gòu)演變之六讀寫分離和廉價(jià)存儲方案
通過增加web服務(wù)器享受了一段快速訪問的幸福后，發(fā)現(xiàn)系統(tǒng)又開始變慢了，經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的 資源競爭非常激烈，導(dǎo)致了系統(tǒng)變慢，這下怎么辦呢，讀寫分離,訂閱和發(fā)布
廉價(jià)存儲方案Nosql
NoSQL = Not Only SQL 指的是非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。
NoSql數(shù)據(jù)庫大量應(yīng)用于微博系統(tǒng)等事務(wù)性不強(qiáng)的系統(tǒng)
BigTable
MongoDB
http://tech.it168.com/topic/2011/10-1/nosqlapp/index.html
架構(gòu)演變之七進(jìn)入大型分布式應(yīng)用時(shí)代和廉價(jià)服務(wù)器群夢想時(shí)代
經(jīng)過上面這個(gè)漫長而痛苦的過程，終于再度迎來了完美的時(shí)代，不斷的增加webserver就可以支撐越來越高的訪問量了，但是原來部署在webserver上的那個(gè)web應(yīng)用已經(jīng)非常龐大 了，當(dāng)多個(gè)團(tuán)隊(duì)都開始對其進(jìn)行改動(dòng)時(shí)，相當(dāng)?shù)牟环奖悖瑥?fù)用性也相當(dāng)糟糕，基本上每個(gè)團(tuán)隊(duì)都做了或多或少重復(fù)的事情，而且部署和維護(hù)也是相當(dāng)?shù)穆闊?，因?yàn)辇嫶蟮膽?yīng)用包在N臺機(jī)器上復(fù)制、啟動(dòng)都需要耗費(fèi)不少的時(shí)間，出問題的時(shí)候也不是很好查，另外一個(gè)更糟糕的狀況是很有可能會(huì)出現(xiàn)某個(gè)應(yīng)用上的bug就導(dǎo) 致了全站都不可用，還有其他的像調(diào)優(yōu)不好操作（因?yàn)闄C(jī)器上部署的應(yīng)用什么都要做，根本就無法進(jìn)行針對性的調(diào)優(yōu)）等因素，根據(jù)這樣的分析，開始痛下決心，將 系統(tǒng)根據(jù)職責(zé)進(jìn)行拆分，于是一個(gè)大型的分布式應(yīng)用就誕生了，通常，這個(gè)步驟需要耗費(fèi)相當(dāng)長的時(shí)間，因?yàn)闀?huì)碰到很多的挑戰(zhàn)：
1、拆成分布式后需要提供一個(gè)高性能、穩(wěn)定的通信框架，并且需要支持多種不同的通信和遠(yuǎn)程調(diào)用方式；
2、將一個(gè)龐大的應(yīng)用拆分需要耗費(fèi)很長的時(shí)間，需要進(jìn)行業(yè)務(wù)的整理和系統(tǒng)依賴關(guān)系的控制等；
3、如何運(yùn)維（依賴管理、運(yùn)行狀況管理、錯(cuò)誤追蹤、調(diào)優(yōu)、監(jiān)控和報(bào)警等）好這個(gè)龐大的分布式應(yīng)用。
經(jīng)過這一步，差不多系統(tǒng)的架構(gòu)進(jìn)入相對穩(wěn)定的階段，同時(shí)也能開始采用大量的廉價(jià)機(jī)器來支撐著巨大的訪問量和數(shù)據(jù)量，結(jié)合這套架構(gòu)以及這么多次演變過程吸取的經(jīng)驗(yàn)來采用其他各種各樣的方法來支撐著越來越高的訪問量。
參考：
http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html
