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