【51CTO.com獨(dú)家特稿】這段時(shí)間，公司的web架構(gòu)要升級(jí)，考慮用負(fù)載均衡；初期準(zhǔn)備采用LVS+Keepalived，我比較有自信，剛剛在一個(gè)客戶的局域網(wǎng)里實(shí)現(xiàn)了這個(gè)，所以直接把腳本移過來了；然而，杯具開始了，發(fā)現(xiàn)LVS怎么也實(shí)現(xiàn)不了后端二臺(tái)web的轉(zhuǎn)發(fā)。

后來關(guān)于此問題我請(qǐng)教了田逸兄，他懷疑我們的網(wǎng)絡(luò)環(huán)境太復(fù)雜了，因?yàn)闋可娴絻?nèi)外網(wǎng)的問題，我們的每臺(tái)機(jī)器上有5條靜態(tài)路由，2個(gè)gateway，直接導(dǎo)致了LVS的不成功；我們?cè)噲D跟network Engeneer溝通，結(jié)果是網(wǎng)絡(luò)不能做一絲一毫改動(dòng)，所以白白測(cè)試了二天。

后來改用了Nginx負(fù)載均衡器，5分鐘就解決了問題，真真切切的體會(huì)到了Nginx對(duì)網(wǎng)絡(luò)的依賴較小，理論上只要ping得通，網(wǎng)頁訪問正常，nginx就能連得通。為了以防萬一，我采用的是Nginx+keepalived高可用架構(gòu)。

在這里，我不是神話Nginx，只是說這是一種解決問題的方法而矣，LVS也有適用的場(chǎng)合，穩(wěn)定性方面是眾所周知的，所以只要提到web層的負(fù)載均衡，我就想到LVS，但LVS不僅僅是；如果網(wǎng)絡(luò)環(huán)境比較復(fù)雜的朋友們，不妨換種思路解決問題。

當(dāng)然用了Nginx后，大問題暫時(shí)沒有；小問題就都來了，首先是SSL，這個(gè)目前支持得算是比較好的，在負(fù)載均衡器上開啟ssl功能，監(jiān)聽443端口，將證書放在Nginx代理上，非后面的web服務(wù)器,輕構(gòu)解決掉問題，詳細(xì)見以下http.conf配置文件

server  
    {  
        listen  443;  
        server_name www.cn7788.com;  
 
        ssl on;  
        ssl_certificate /usr/local/nginx/keys/www.cn7788.com.crt;  
        ssl_certificate_key /usr/local/nginx/keys/www.cn7788.com.key;         
 
        ssl_protocols  SSLv3 TLSv1;  
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;  
        } 

但問題又來了，這么有個(gè)問題，跑在后方 apache 上的應(yīng)用獲取到的IP都是Nginx所在服務(wù)器的IP ，或者是本機(jī) 127.0.0.1 。最明顯就是查看 apache 的訪問日志。就會(huì)見到來來去去都是內(nèi)網(wǎng)的IP；雖然可以通過Nginx日志來判斷客戶的client,但有些考慮不周全的應(yīng)用，例如 Tattertools (一個(gè)博客程序) 就會(huì)犯誤,后臺(tái)的訪問日志死活顯示訪客數(shù) 1，ip來自 127.0.0.1。這時(shí)候就要想辦法來處理了。你可以通過修改 nginx proxy 的參數(shù)令后端應(yīng)用獲取到Nginx 發(fā)來的請(qǐng)求報(bào)文獲取到外網(wǎng)的IP。

proxy_set_header        Host $host;  
proxy_set_header        X-Real-IP $remote_addr;  
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for; 

這僅僅只是讓Nginx獲到到外網(wǎng)IP，Apache未必買帳呢，即Aapche端也需要設(shè)置，搜尋了一下，發(fā)現(xiàn)了apache這一個(gè)來自第三方的mod 配合Nginx proxy 使用。

說明：http://stderr.net/apache/rpaf/

下載：http://stderr.net/apache/rpaf/download/

最新版本是 mod_rpaf-0.6.tar.gz

安裝也相當(dāng)簡(jiǎn)單。

# tar zxvf mod_rpaf-0.6.tar.gz 下載后解壓# cd mod_rpaf-0.6

Apache 的目錄按自己的環(huán)境修改，并選擇相應(yīng)的安裝方式：

#/usr/local/apache/bin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c  

完成后會(huì)在 http.conf  的 LoadModule 區(qū)域?yàn)槟愣嗉恿艘恍小?/p>

LoadModule mod_rpaf-2.0.so_module modules/mod_rpaf-2.0.so 經(jīng) apache 2.2.6 的實(shí)驗(yàn)，使用這一行啟動(dòng) apache 的時(shí)候會(huì)報(bào)錯(cuò)的。

所以改為：

LoadModule rpaf_module        modules/mod_rpaf-2.0.so

并在下方添加

RPAFenable On  
RPAFsethostname On  
RPAFproxy_ips 127.0.0.1 192.168.1.101 192.168.102 

#填寫Nginx所在的內(nèi)網(wǎng)IP，Nginx的內(nèi)網(wǎng)地址必寫，不然一樣失敗的，這問題花了幾個(gè)小時(shí)測(cè)試；有幾個(gè)代理服務(wù)器的IP就寫幾個(gè)代理服務(wù)器的IP

RPAFheader X-Forwarded-For

保存退出后重啟apache，再看看 apache 的日志內(nèi)容？不再是來來去去的那幾個(gè)IP了吧，呵呵。

另外這里來個(gè)小插曲，我做的某個(gè)小項(xiàng)目本為是基于Nginx的1+3架構(gòu)，突然要加一臺(tái)機(jī)器是windows2003系統(tǒng)，專門作存放圖片及 PDF等，但項(xiàng)目的要求是能在nginx后的三臺(tái)web上有顯示圖片及pdf下載的需求；當(dāng)時(shí)迷糊了下，因?yàn)槌绦蚴怯玫降腪end Framwork，所以一直用正則作跳轉(zhuǎn)；后來才想明白，IE程序是先在nginx負(fù)載均衡器上提申請(qǐng)，所以nginx.conf是做分發(fā)而非正則跳轉(zhuǎn)，此時(shí)最前端的nginx，既是負(fù)載勻衡器也是反向代理，明白這個(gè)就好做多了，語法如下；另外注意location /StockInfo與location ~^/StockInfo的差異性，Nginx默認(rèn)的是正則優(yōu)先的，by the way,proxy_pass支持直接寫IP的方式。

upstream mysrv {  
    ip_hash;  
    server 192.168.110.62;  
    server 192.168.110.63;  
    }  
 
upstream myjpg {  
    server 192.168.110.3:88;  
    }  
 
 
    server  
    {  
        listen 80;  
        server_name web.tfzq.com;  
        proxy_redirect off;  
 
        location ~ ^/StockInfo{  
        proxy_pass http://myjpg;  
} 

再說下Nginx下的并發(fā)，這是個(gè)容易讓人誤會(huì)的概念?，F(xiàn)在Nginx的文章滿天飛，好像只要一涉及到web并發(fā)，就非將Apache換成nginx不可，其實(shí)完全沒這必要；在內(nèi)存足夠的情況，Apache的抗并發(fā)能力也是很強(qiáng)的。玩了幾年nginx了，遇到的最大并發(fā)也是以前在北京維護(hù)的CDN之廣告網(wǎng)站，大約在3000-5000之間(這種情況建議用Nginx)，一般的資訊類金融網(wǎng)站也就100多，電子商務(wù)網(wǎng)站1100左右，web層的并發(fā)壓力并沒有想象中的大；相反，我感覺文件和數(shù)據(jù)層的壓力越來越大，單個(gè)NFS服務(wù)器越來越難受了，所以我后期準(zhǔn)備布署moosefs；而mysql數(shù)據(jù)庫我一般用的是主從復(fù)制，壓力也不小，目前只是從二方面來解決此問題：一、用公司最好的服務(wù)器來作數(shù)據(jù)庫服務(wù)器；二、盡可能的優(yōu)化，如果壓力持續(xù)增長(zhǎng)的話，后期我考慮從架構(gòu)級(jí)方面優(yōu)化了。對(duì)于一個(gè)網(wǎng)站而言，建議多從架構(gòu)極的觀念來看問題和解決問題。

今天一直測(cè)試網(wǎng)站的響應(yīng)時(shí)間是用Linux/unix下工具h(yuǎn)ttping,今天同事找了個(gè)專業(yè)網(wǎng)站給我，發(fā)現(xiàn)很好用，特的拿出來與大家共享http://tools.pingdom.com,可以測(cè)試個(gè)幾十次然后取平均值，這樣得出的結(jié)果較為精準(zhǔn)；系統(tǒng)運(yùn)維工作本來就是一個(gè)細(xì)膩活，有時(shí)短短幾行代碼，說不定就要調(diào)試幾天；而有時(shí)維護(hù)的服務(wù)器日志，經(jīng)常是十幾萬行，看得人心花繚亂...痛并快樂著，這也是算是目前工作的心態(tài)吧。

【51CTO.com獨(dú)家特稿，非經(jīng)授權(quán)謝絕轉(zhuǎn)載，合作媒體轉(zhuǎn)載請(qǐng)注明原文出處及作者！】