网站服务架构
服務(wù)器劃分
?????? 對(duì)于訪問量大的網(wǎng)站而言，將網(wǎng)站的各個(gè)部分拆分分別部署到不同服務(wù)器上是很有必要的。例如將圖片和web站點(diǎn)分開。一般而言，在網(wǎng)站的整個(gè)服務(wù)器部署上分為如下幾種類型：
???????文件服務(wù)器：一般存儲(chǔ)系統(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í)候需要針對(duì)網(wǎng)站做一些優(yōu)化策略：
- 減少Http請(qǐng)求，壓縮css，js，圖片的大小
- 將Microsoft Ajax Minifier集成到VS2010對(duì)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í)候開始考慮增加一臺(tái)WebServer，但是增加一臺(tái)WebServer的時(shí)候意味著要在兩臺(tái)的服務(wù)器上分別建立相同的站點(diǎn)，那么就會(huì)出現(xiàn)如下問題：
?????? 如何讓訪問分配到這兩臺(tái)機(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ū)
| ? | 水平 | 垂直 |
| 存儲(chǔ)依賴 | 可跨越DB | 可跨越表空間,不同的物理屬性 |
| 存儲(chǔ)方式 | 分布式 | 集中式 |
| 擴(kuò)展性 | Scale?Out(橫向擴(kuò)展，增加便宜設(shè)備) | Scale?Up(升級(jí)設(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)有大量的阻塞請(qǐng)求，于是可以做Web園或者添加一些webserver服務(wù)器。在這個(gè)添加webserver服務(wù)器的過程，有可能會(huì)出現(xiàn)如下幾個(gè)問題：
一臺(tái)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)對(duì)的解決方案就是不斷的添加webserver。
架構(gòu)演變之六讀寫分離和廉價(jià)存儲(chǔ)方案
通過增加web服務(wù)器享受了一段快速訪問的幸福后，發(fā)現(xiàn)系統(tǒng)又開始變慢了，經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的?資源競爭非常激烈，導(dǎo)致了系統(tǒng)變慢，這下怎么辦呢，讀寫分離,訂閱和發(fā)布
?
廉價(jià)存儲(chǔ)方案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ù)器群夢(mèng)想時(shí)代
經(jīng)過上面這個(gè)漫長而痛苦的過程，終于再度迎來了完美的時(shí)代，不斷的增加webserver就可以支撐越來越高的訪問量了，但是原來部署在webserver上的那個(gè)web應(yīng)用已經(jīng)非常龐大?了，當(dāng)多個(gè)團(tuán)隊(duì)都開始對(duì)其進(jìn)行改動(dòng)時(shí)，相當(dāng)?shù)牟环奖?#xff0c;復(fù)用性也相當(dāng)糟糕，基本上每個(gè)團(tuán)隊(duì)都做了或多或少重復(fù)的事情，而且部署和維護(hù)也是相當(dāng)?shù)穆闊?#xff0c;因?yàn)辇嫶蟮膽?yīng)用包在N臺(tái)機(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)行針對(duì)性的調(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)入相對(duì)穩(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
與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖總結(jié)
- 上一篇： 潮汐车道（说一说潮汐车道的简介）
- 下一篇： 管家基因和奢侈基因举例（管家基因）