關(guān)于nginx的負(fù)載均衡軟件配置很多朋友都有接觸過。但是，對于硬件產(chǎn)品，由于其高昂的費(fèi)用，接觸的人相對較少一些。下面，我就來針對Nginx負(fù)載均衡器與大家做一些探討。

在項(xiàng)目實(shí)施過程中發(fā)現(xiàn)，業(yè)務(wù)系統(tǒng)最前端的Cisco PIX535防火墻的外網(wǎng)IP映射的是內(nèi)網(wǎng)Nginx負(fù)載均稀器的內(nèi)網(wǎng)IP（DNAT），這時(shí)的Nginx負(fù)載均衡器的作用相當(dāng)于整套系統(tǒng)的樞紐，如果該服務(wù)器發(fā)生故障，會導(dǎo)致整個網(wǎng)站無法訪問，所以我們需要二臺以上的Nginx負(fù)載均稀器，以實(shí)現(xiàn)故障轉(zhuǎn)移和高可用性。

實(shí)現(xiàn)的辦法有如下：

一、二臺Nginx負(fù)載均衡器通過Keepalived形成高可用，防火墻映射的是Keepalived形成的vip地址；keepalived是lvs的擴(kuò)展形式，部署起來非常容易，成熟的案例在sina等企業(yè)也得到應(yīng)用；但Keepalived做不到監(jiān)控nginx服務(wù)級別，即如果nginx服務(wù)崩潰了，Keepalived也沒有辦法，雖然可以通過Heartbeat來解決這個問題，但Heartbeat本身就存在著裂腦情況，所以目前我只是將Heartbeat用于內(nèi)部測試環(huán)境，生產(chǎn)環(huán)境我仍然是用Keepalived。

二、最前端不用Cisco防火墻映射，而用F5代替；第二層用二臺或二臺以上的Nginx負(fù)載均衡器，第三層才是web集群。

這樣的好處很明顯：不存在單點(diǎn)Nginx負(fù)載均衡出現(xiàn)故障問題。

同樣缺點(diǎn)也很明顯：整個工程的成本增加，你的客戶和老板很可能非常不滿意。

三、張宴兄采用的辦法是用DNS輪詢，二臺Nginx負(fù)載均衡器均提供一個虛擬的外網(wǎng)IP對應(yīng)用DNS（應(yīng)用環(huán)境為逍遙網(wǎng)xoyo．com），二臺Nginx上的故障轉(zhuǎn)移通過自身的shell腳本來實(shí)現(xiàn)，具體請參見張宴的《實(shí)戰(zhàn)Nginx－取代Apache的高性能web服務(wù)器》一書。方案很實(shí)用，而且也是線上環(huán)境，但美中不足的是我手上的證券系統(tǒng)，都只有IP，并無DNS域名對應(yīng)，看來這個需要跟券商談判爭取了。

四、目前我手上跑的三套在線系統(tǒng)都是單機(jī)Nginx，是由于券商都有值班人員和監(jiān)控系統(tǒng)Nagios，但這樣會增加生產(chǎn)成本。

我目前想的一個辦法是：

在Nginx負(fù)載均衡器上開啟sendmail服務(wù)，運(yùn)行一個監(jiān)控shell腳本，每2－5分鐘就wgethttp：／／172．16．110．61／test．php（為了避免Cisco防火墻某些技術(shù)上的限制，這里采用內(nèi)網(wǎng)IP形式）即2分鐘或5分鐘就自動去獲取一次后端web的某網(wǎng)頁一次，如果正常就啥也不做；如果發(fā)生異常情況，就向我的139郵箱發(fā)送Ctritical警報(bào)。因?yàn)?39郵箱對應(yīng)了手機(jī)號碼，所以此時(shí)手機(jī)將會收到報(bào)警信息，達(dá)到預(yù)警目的。