|
http://www./blog/index_596.html 隨著21世紀(jì)互聯(lián)網(wǎng)的快速發(fā)展以及web2.0的誕生,最初web服務(wù)器已經(jīng)不能滿足我們的需求.而現(xiàn)在我們要考慮的不再僅僅是web服務(wù)器以及數(shù)據(jù)庫(kù)服務(wù)器這么簡(jiǎn)單,我們所需要考慮的就是設(shè)計(jì)出一套高性能web解決方案,并且實(shí)現(xiàn)多路負(fù)載均衡,自動(dòng)備援等功能.  圖1-1 對(duì)于一個(gè)標(biāo)準(zhǔn)的高性能web架構(gòu),我通常會(huì)分為三層,即”代理層”,”web層”和”數(shù)據(jù)層”,當(dāng)然可能會(huì)隨著需求的不同,我們會(huì)添加其他的應(yīng)用至架構(gòu)中. 而往往它們所需提供的服務(wù)也無非是這三層中的其中之一. 以下我就圖1-1的拓?fù)鋱D做一些解釋. 代理層: 我把web cache 加速和 Load Balancer 放到了同一層,因?yàn)樗麄兊墓ぷ鞫际菃⒌搅藀roxy的作用,只是他們所做的是不同的工作. Web cache 提到Web cache服務(wù)器或web代理服務(wù)器(我們統(tǒng)稱為web加速服務(wù)器),很多人往往就會(huì)想到Squid , 我曾經(jīng)對(duì)一個(gè)網(wǎng)站做過一個(gè)測(cè)試 , 在利用了Squid做加速代理后的速度比沒有利用Squid做加速代理在速度有著很明顯的提升. 當(dāng)然除了Squid之外還有Varnish ,并且在我的對(duì)Varnish的測(cè)試中, 發(fā)現(xiàn)Varnish的效果要比Squid好很多,因?yàn)檎绾芏噘Y料中都提到的,Varnish在內(nèi)存的利用上,比Squid有著很大的優(yōu)勢(shì).所以說在一個(gè)高性能的web架構(gòu)中web cache是web加速是不能缺少的. Load Balancer F5,梭子魚,A10等負(fù)載均衡的設(shè)備我想對(duì)大家來說并不陌生.我用過F5的設(shè)備,也體驗(yàn)過梭子魚,并且A10上海的辦事處目前與我的辦公室也僅僅只有一墻之隔.我不得不去承認(rèn)這些負(fù)載均衡的設(shè)備的性能以及在一些生產(chǎn)環(huán)境中為一些現(xiàn)有的Load Balancer架構(gòu)所作出的貢獻(xiàn).但是這篇文章主要是圍繞著基于Linux/unix,所以在此我所提到的并不是這些廠商所提供的Load Balancer的設(shè)備,而是基于linux的Load Balancer軟件 Haproxy . Haproxy可以支持?jǐn)?shù)以萬計(jì)的并發(fā)連接,并且滿足session保持,適合用于負(fù)載較大的web站點(diǎn),并且haproxy可以保護(hù)web服務(wù)器不被暴露在公網(wǎng)上,提高了web服務(wù)器的安全性. 看到這或許你會(huì)有疑問我為什么會(huì)把web cache 比如varnish放在了haproxy的前面?而在網(wǎng)上很多人都是haproxy在varnish前面,后端再通過nginx做web服務(wù)器的Load Balancer,他們的設(shè)計(jì)并沒有錯(cuò),也是可行的.不過我想讀完下面的內(nèi)容,你會(huì)知道我這么做的原因. 首先,在varnish和squid中,對(duì)負(fù)載均衡的支持并不是很完美,雖然squid和varnish都能夠支持一些簡(jiǎn)單的負(fù)載均衡的工作,但是他們提供的負(fù)載均衡并不能滿足我們的需求,比如squid能夠支持web服務(wù)器的健康檢測(cè),但是在session保持上,squid一直沒有一個(gè)很好的解決方案,還是需要通過第三方的開源軟件來實(shí)現(xiàn)..最后squid和varnish在負(fù)載均衡的執(zhí)行效率上,表現(xiàn)的并不是很好.所以我會(huì)建議如果條件允許的話,還是把兩者分開.當(dāng)然haproxy也可以通過nginx做替代,唯一要考慮的問題就是session保持的問題,但是我們可以通過memcached的session共享來解決.而在Load Balancer這層haproxy的主要工作就是將varnish的請(qǐng)求分發(fā)到不同的web服務(wù)器,并且支持session保持.我想你也不希望在為nginx或者squid搭建一臺(tái)session共享服務(wù)器吧.所以我想haproxy會(huì)是你更好的選擇. Web層: Web層其實(shí)很簡(jiǎn)單,正如我所定義的web層的字面意思一樣,在web層中所提供的服務(wù)無非也就是web服務(wù),比如基于java,php等語言開發(fā)的站點(diǎn).在這一層中有很多開源軟件能夠滿足你的需求.比如Apache,Nginx,lighttpd,thttpd以及cherokee等.在網(wǎng)上看到很多朋友對(duì)apache進(jìn)行一些評(píng)論,并且有些朋友的言語還是比較激烈,而這些曾誤導(dǎo)過很多剛剛接觸linux的朋友.在這我建議各位朋友,根據(jù)不同的需求來選擇不同的web server那才是最完美的,比如,你需要自己定制模塊,那么apache是一個(gè)很不錯(cuò)的選擇,很多公司比如阿里巴巴和sina在apache上都有著自己的定制的模塊.如果你單純只是用來做靜態(tài)頁面,那你可以選擇nginx,lighttpd或者是thttpd,這些都是一個(gè)很不錯(cuò)的選擇.在一個(gè)高性能的web站點(diǎn)中,將動(dòng)態(tài)頁面和靜態(tài)頁面分開,通過不同的web服務(wù)器來完成不同的工作,將會(huì)起到一些關(guān)鍵性的作用.因?yàn)樗麄兡茏屇愕恼军c(diǎn)顯得快些.我想這個(gè)”快”至少是你的管理層所期待的. 數(shù)據(jù)層: 在數(shù)據(jù)層,服務(wù)器所要做的工作就是對(duì)數(shù)據(jù)進(jìn)行處理.而這一層往往也是最重要的,因?yàn)樗坏洚?dāng)著你數(shù)據(jù)的處理工作,而且還充當(dāng)著數(shù)據(jù)的存儲(chǔ).在數(shù)據(jù)的處理上,這個(gè)直接決定著你網(wǎng)站呈現(xiàn)給用戶的速度;在數(shù)據(jù)的存儲(chǔ)上,這層存儲(chǔ)著你網(wǎng)站和用戶的數(shù)據(jù),我想你并不希望哪天因?yàn)榈钠鸪跫軜?gòu)設(shè)計(jì)的不合理導(dǎo)致你頁面的呈現(xiàn)給用戶的速度很慢或者因?yàn)槟愕募軜?gòu)設(shè)計(jì)的不合理導(dǎo)致你最終因?yàn)槟撤N原因而丟失了一部分用戶數(shù)據(jù).我想那時(shí)候你一定會(huì)很后悔,畢竟數(shù)據(jù)是最重要的.他決定著很多. SQL Cache 不用我介紹,我想很多人會(huì)立馬想到了Memcached(請(qǐng)注意是memcached,并不是memcache雖然有很多人稱之為memcache但是那是錯(cuò)誤的.) , 你不知道也沒關(guān)系,因?yàn)橄旅嫖視?huì)講下Memcached,Memcached是一款不錯(cuò)的分布式內(nèi)存緩存系統(tǒng),當(dāng)客戶端在與 memcached 服務(wù)建立連接之后,接下來的事情就是存取對(duì)象了,而Memcached會(huì)將這些對(duì)象存儲(chǔ)到內(nèi)存中而并非硬盤上,這也就是memcached如此高效快速的原因.值得注意的是這些對(duì)象并不是持久的,服務(wù)停止之后,里邊的數(shù)據(jù)就會(huì)丟失.因?yàn)樗膶?duì)象都是存儲(chǔ)在內(nèi)存中的. 我相信現(xiàn)在已經(jīng)有很多人把Memecached運(yùn)用到了生產(chǎn)環(huán)境中去了,而且這些人對(duì)Memcached的評(píng)價(jià)也不會(huì)太差,畢竟也只有使用過Memcached的人才知道,加入了Memcached后整體站點(diǎn)性能的提升的幅度.所以如果你的站點(diǎn)中還沒有Memcached的話,你可以考慮添加Memcached到你的web架構(gòu)中. SQL Server 其實(shí)數(shù)據(jù)庫(kù)的選擇,我想在這個(gè)我可以直接提MySQL,因?yàn)镸ySQL已經(jīng)是一個(gè)很成熟的網(wǎng)絡(luò)數(shù)據(jù)庫(kù)服務(wù),并且在數(shù)據(jù)處理的性能上也已經(jīng)能夠遠(yuǎn)遠(yuǎn)滿足很多企業(yè)的需求,Master-slave和Master-Master也已經(jīng)成為了一個(gè)web架構(gòu)中數(shù)據(jù)庫(kù)經(jīng)常用的方案.但是在這值得一提的是,在一個(gè)高性能的web架構(gòu)中,數(shù)據(jù)庫(kù)的讀寫分離這個(gè)是必不可少的.而數(shù)據(jù)庫(kù)的讀寫分離,可以在程序中進(jìn)行操作,也可以通過一些開源的相關(guān)軟件做mysql的Proxy. 而這個(gè)在下文也會(huì)提到,請(qǐng)務(wù)必繼續(xù)閱讀下去. 對(duì)于web的架構(gòu)的三層已經(jīng)做了一些解釋,其實(shí)以上是一個(gè)很標(biāo)準(zhǔn)的web架構(gòu)方案,雖然稱不上完美,但是我想已經(jīng)足以應(yīng)付一些站點(diǎn)的需求.不過還得請(qǐng)你繼續(xù)往下看.因?yàn)橐幌逻€會(huì)有很多內(nèi)容,當(dāng)然這些介紹可能你早已經(jīng)知道,但是我想花一點(diǎn)時(shí)間讀一讀還是有必要的. 在上面的內(nèi)容中,我沒有對(duì)自動(dòng)備援,數(shù)據(jù)庫(kù)的讀寫分離等應(yīng)用做過多的介紹,是因?yàn)榭赡軙?huì)有很多初學(xué)者看到這篇文章,而往往他們并沒有完全理解我所定義的三層,不過我想如果他們讀完了上面的內(nèi)容,或多或少會(huì)了解一些.接下來,我就會(huì)介紹利用哪些開源的軟件來實(shí)現(xiàn)自動(dòng)備援,數(shù)據(jù)庫(kù)的讀寫分離的proxy等工作. 自動(dòng)備援: 在一個(gè)高可用性的web架構(gòu)中,自動(dòng)備援的功能充當(dāng)著很重要的工作.因?yàn)樗苯泳蜎Q定著你網(wǎng)站的任意一臺(tái)服務(wù)器在down機(jī)后的站點(diǎn)恢復(fù)工作的時(shí)間.就拿圖1-1拓?fù)鋱D來說,如果你用了DNS輪詢來做的負(fù)載均衡,并且解析地址為Varnish的兩臺(tái)服務(wù)器,如果有一天你的一臺(tái)Varnish服務(wù)器因?yàn)橛布栴}down機(jī)后,我想你所要面對(duì)的問題就不用我說了,首先你得去修改你的DNS解析地址,據(jù)我所了解很多公司并沒有自己的DNS服務(wù)器,他利用還是域名提供商的DNS服務(wù)器來完成域名的解析工作,而往往修改過DNS的解析地址之后并不會(huì)立即就生效,需要等待一段時(shí)間之后,最新的額DNS解析才會(huì)生效.而這段時(shí)間,意味著有一部分的客戶打不開你們的網(wǎng)站,而這意味著你們正在面對(duì)著損失一些客戶的風(fēng)險(xiǎn).如果你們銷售知道了,一定會(huì)非常生氣,并且還會(huì)跑到Boss那告狀. 以上的情景很多朋友都曾經(jīng)歷過,并且到現(xiàn)在為止還是沒有在自己的生產(chǎn)環(huán)境中運(yùn)用到自動(dòng)備援的功能.其實(shí)想實(shí)現(xiàn)自動(dòng)備援很簡(jiǎn)單,而現(xiàn)在也已經(jīng)有很多軟件支持了自動(dòng)備援的功能.在這個(gè)我要推薦Heartbeat. 在IT行業(yè)中的心跳這個(gè)術(shù)語,我想也不用我過多的解釋了.而heartbeat 也是一個(gè)心跳程序, 他的工作原理就是先虛擬出一個(gè)IP地址,我們稱為VIP(Virtual IP Address)通過網(wǎng)絡(luò)(此外還有串口,只是生產(chǎn)環(huán)境中很少使用串口)來告訴對(duì)方自己當(dāng)前的活動(dòng)狀態(tài).在兩臺(tái)運(yùn)行的heartbeat的環(huán)境中,當(dāng)一臺(tái)服務(wù)器因?yàn)橛布蛘咂渌麊栴},導(dǎo)致down機(jī)后,由于另外一臺(tái)運(yùn)行著heartbeat的服務(wù)器沒有收到這臺(tái)服務(wù)器的心跳信息時(shí),就會(huì)把這VIP綁定到自己的網(wǎng)卡上,簡(jiǎn)單的說,這臺(tái)服務(wù)器接手了剛剛down掉的服務(wù)器的工作.而這個(gè)時(shí)間是我們所設(shè)定的,一般我們?cè)O(shè)置為10秒. 很多朋友也已經(jīng)在生產(chǎn)環(huán)境中使用了Heartbeat,往往架構(gòu)是這樣,一臺(tái)服務(wù)器正常工作比如運(yùn)行web服務(wù),而另外一臺(tái)服務(wù)器僅僅作為這臺(tái)服務(wù)器的備份機(jī)使用,我相信很多朋友朋友都是這么來操作的,而這樣你的真正在為用戶提供服務(wù)的服務(wù)器也僅僅只有一臺(tái).剛剛接觸Heartbeat的時(shí)候我也是這樣的一個(gè)環(huán)境,但是后來我一直在想,能否讓兩臺(tái)服務(wù)器都能夠利用VIP?這樣的話,兩臺(tái)服務(wù)器不但能夠同時(shí)為用戶提供服務(wù),而且兩臺(tái)服務(wù)器都具備了自動(dòng)備援的功能.讀到這我想你一定會(huì)知道我為什么介紹Heartbeat了. 而實(shí)現(xiàn)原理其實(shí)很簡(jiǎn)單,通過利用不同的端口以及不同的配置文件和不同的服務(wù)來使Heartbeat完成雙向的自動(dòng)援備的功能. MySQL 讀寫分離: 數(shù)據(jù)庫(kù)在一個(gè)站點(diǎn)中起著至關(guān)重要的角色. 而這個(gè)時(shí)候考驗(yàn)的就是你的數(shù)據(jù)庫(kù)的性能.很多公司在數(shù)據(jù)庫(kù)服務(wù)器上花了重金,購(gòu)買了較好的服務(wù)器來滿足數(shù)據(jù)庫(kù)性能的需求.但是這些往往不夠,此時(shí)我們就需要考慮數(shù)據(jù)庫(kù)的讀寫分離,而這里也重點(diǎn)介紹MySQL的讀寫分離. 很多程序員在寫程序的時(shí)候也已經(jīng)考慮到了MySQL的讀寫分離,他們所做的也就是將數(shù)據(jù)庫(kù)的查詢和添加語句區(qū)分開來,這樣雖然說支持了MySQL的讀寫分離,但是在MySQL的Load Balancer上并不能得到很好的支持,并且不方便維護(hù). 在MySQL的讀寫分離上我曾經(jīng)用過MySQL Proxy 而現(xiàn)在用的最多的則是Amoeba,不管是從性能還是從維護(hù)來看, Amoeba的表現(xiàn)都比MySQL Proxy有著很大的優(yōu)勢(shì),而且Amoeba在對(duì)MySQL的Load Balancer上支持也是相當(dāng)?shù)某錾?再配合Heartbeat . 數(shù)據(jù)庫(kù)層也便具有高可用性和自動(dòng)備援.至少你可以睡的香一些. 實(shí)時(shí)同步: 一個(gè)站點(diǎn)中還有存在著一個(gè)讓人頭大的問題,就是數(shù)據(jù)的同步問題,且拋開數(shù)據(jù)庫(kù)那層的同步問題,因?yàn)閙ysql 的master-slave或者master-master的方案已經(jīng)足夠幫助你完成數(shù)據(jù)庫(kù)層面的同步工作.而在其他數(shù)據(jù)的同步問題,我們也并不是沒有解決辦法,我們可以通過利用inotify和rsync的結(jié)合來完成在其他數(shù)據(jù),比如用戶的上傳文件的實(shí)時(shí)同步問題.當(dāng)然如果想具備更可靠的安全性,我們還可以通過inotify和csync2來完成這個(gè)工作. 監(jiān)控: 在一個(gè)高可用性的web架構(gòu)中,監(jiān)控也是必不可少的.而監(jiān)控報(bào)警,也是我們所要做的.雖然上面介紹過的內(nèi)容支持自動(dòng)備援的功能,但是我想監(jiān)控報(bào)警服務(wù)器的架設(shè)能夠讓你在第一時(shí)間知道服務(wù)器down機(jī)的信息.cacti,nagios等監(jiān)控軟件現(xiàn)在也已經(jīng)在很多web架構(gòu)中運(yùn)用. 文件系統(tǒng): 文件系統(tǒng)的選擇也決定著一個(gè)高性能的web架構(gòu)的完美性,在linux下有很多文件系統(tǒng),常見的文件系統(tǒng)有ext3,XFS, ReiserFS以及最新推出的ext4.而這些文件系統(tǒng)都有著自己的所長(zhǎng)之處,根據(jù)需求的不同,選擇不同的文件系統(tǒng),也會(huì)直接影響著一個(gè)高性能的web架構(gòu). 定制腳本: 一個(gè)高性能的web架構(gòu)自然也不能離開定制屬于自己腳本,不管是基于shell還是perl又或者是python所寫的腳本,其實(shí)最終的目的只有幫助你工作.就拿Heartbeat來說,雖然自動(dòng)備援的功能有了,但是卻無法提供服務(wù)的檢測(cè),此時(shí)我們就需要通過定制一個(gè)腳本來對(duì)服務(wù)進(jìn)行檢測(cè),如果發(fā)現(xiàn)此服務(wù)因?yàn)槟撤N原因停止掉了,我們就可以通過定制的腳本關(guān)閉Heartbeat的進(jìn)程,我想這樣這個(gè)會(huì)更完美.而這個(gè)腳本我曾用perl寫過.對(duì)于Heartbeat定制的腳本我也只是舉個(gè)例子,而腳本所完成的工作遠(yuǎn)遠(yuǎn)不止這些. 安全性: 在一個(gè)高性能的web架構(gòu)中,安全問題,也不能忽視,就說DDos吧,我想這個(gè)肯定會(huì)讓你感到很頭疼,因?yàn)槟銜?huì)拿DDos沒有辦法,它是那么的可怕.我不敢保證我能夠抵抗DDos的攻擊,但是我能說的只是我能防范一部分DDos的攻擊,就拿juniper,cisco,中國(guó)的金盾他們的防火墻來說,他們都不敢保證能夠完全抵抗的DDos的攻擊.我們能做的也就是防范一部分DDos的攻擊和其他的一些攻擊手段,在linux下能夠供我們選擇的防火墻有很多iptables大家也不陌生,如果你剛剛接觸Linux可能你會(huì)對(duì)packet filter(PF)感覺到陌生.其實(shí)你不用擔(dān)心太多,因?yàn)椴还苁莍ptables還是基于bsd的PF都能夠幫助完成一個(gè)防火墻的搭建工作,并且具備這比較高的安全性.除了防火墻的安全性之外,我認(rèn)為系統(tǒng)的安全也是很重要的,畢竟你的服務(wù)器是托管在IDC機(jī)房,你并不知道是否有人會(huì)查看你的服務(wù)器,所以我們要做好系統(tǒng)的安全.給grub加入MD5后的密碼是必不可少的.除此之外禁止SSH root用戶的登錄我想也是需要的. 鏈路: 在前面所提到的都是基于開源軟件的.但是在一個(gè)高性能的web服務(wù)器架構(gòu)中,鏈路問題也是值得大家所要考慮的.而我所說的鏈路不包括租用的帶寬,而僅僅是服務(wù)器與服務(wù)器之間交換數(shù)據(jù)的鏈路.我曾參觀過很多機(jī)房,最讓我擔(dān)憂的就是服務(wù)器之間的鏈路問題.首先是線路的質(zhì)量,有些機(jī)房為了節(jié)約開銷,從接入層設(shè)備到服務(wù)器的線的質(zhì)量并不是很好;其次就是線路的雜亂,可能你會(huì)對(duì)雜亂有所疑問.但是你不會(huì)想到以后因?yàn)榉N種原因要對(duì)服務(wù)器或者線路進(jìn)行調(diào)整的時(shí)候,因?yàn)榫€路的雜亂從而導(dǎo)致拔錯(cuò)網(wǎng)線或者碰掉網(wǎng)線,導(dǎo)致服務(wù)器無法提供網(wǎng)絡(luò)服務(wù).那時(shí)候你便會(huì)后悔當(dāng)初沒有好好對(duì)服務(wù)器之間的線路做些整理.因?yàn)檫@些完全是可以避免的. 結(jié)束語: 在一個(gè)高性能的web架構(gòu)中,我們能夠做的還有很多而且利用的開源軟件也還會(huì)有很多,比如LVS, keepalived等等,都能夠?qū)崿F(xiàn)一個(gè)高性能的web架構(gòu),而且也具備自動(dòng)備援等功能,但是我們所要做的并不是盲目的去選擇一個(gè)開源的軟件,而是得根據(jù)客戶或者公司的需求,維護(hù)成本以及日后的擴(kuò)展性等來決定著自己對(duì)開源軟件的選擇. |
|
|
