[[340893]]

目前HTTP協(xié)議，乃至WebSocket協(xié)議，乃至采用了MQTT協(xié)議的WebSocket協(xié)議，都不可避免的使用了Nginx。所謂病從口入，禍從口出。作為入口，Nginx承擔(dān)的責(zé)任非常的重要。假如某個(gè)時(shí)刻不能用了，那可真是災(zāi)難。

如何保證Nginx的高可用呢?這是個(gè)問題。不論你用什么樣的方案，到最后總是要?dú)w為單一，很讓人苦惱。

所謂的高可用，無非兩種方式。一種方式就是在組件自身上做文章，另外一種方式，就是加入一個(gè)中間層。我們通常希望在高可用的時(shí)候，同時(shí)還能夠負(fù)載均衡，典型的貓和狗都想要，貪婪的很。

每當(dāng)解決不了問題的時(shí)候，我們都會(huì)加入一個(gè)中間層，然后把希望寄托在這個(gè)新生的組件上。

如果這個(gè)中間層解決不了問題，我們就可以加入另外一個(gè)中間層。就這樣一層套一層，到最后系統(tǒng)高可用架構(gòu)就會(huì)變得非常復(fù)雜。

DNS保證高可用第一種方式當(dāng)然是要在DNS上做文章了。通過在DNS上，綁定多個(gè)Nginx的IP地址，即可完成高可用。不僅能夠完成高可用，還能順便完成負(fù)載均衡。

但這玩意有一個(gè)致命的問題，那就是故障的感知時(shí)間。

我們的瀏覽器在訪問到真正的Nginx之前，需要把域名轉(zhuǎn)化為真正的IP地址，DNS就是干解析這個(gè)動(dòng)作的，每次需要耗費(fèi)20-20ms不等。

為了加快解析速度，一般都會(huì)有多級(jí)的緩存。比如瀏覽器就有DNS的緩存;你使用的PC機(jī)上也有這樣的緩存;IPS服務(wù)提供商，也會(huì)有緩存;再加上有的企業(yè)為了加速訪問所自建的DNS服務(wù)器，中間的緩存層就更多了。

只有所有的緩存都不命中的情況下，DNS才會(huì)查詢真正的IP地址。所以，如果有一臺(tái)Nginx當(dāng)機(jī)了，這個(gè)故障的感知能力就會(huì)特別的差。總有一部分用戶的請(qǐng)求，會(huì)落在這臺(tái)已經(jīng)死亡的機(jī)器上。

硬件保證高可用我們前面說了。解決不了的問題，就可以加中間層，即使這個(gè)中間層是硬件，比如F5。

這種架構(gòu)一般的企業(yè)玩不起，只有那些采購有回扣有油水的公司，才會(huì)喜歡這個(gè)。互聯(lián)網(wǎng)中用的很少，就不過多介紹了。

當(dāng)然，F(xiàn)5同樣有單點(diǎn)的問題。雖然硬件肯定要比軟件穩(wěn)定上一點(diǎn)，但是總歸是一個(gè)隱患。就像Oracle無論再厲害，它還是有出問題的時(shí)候，到時(shí)候備機(jī)是必須的。

有的廠商在賣硬件的時(shí)候，推薦你一次買3個(gè)!為啥呢?這也有理由。

你的一臺(tái)硬件正在服務(wù)，有兩臺(tái)備份機(jī)器。當(dāng)你服務(wù)的這臺(tái)機(jī)器出現(xiàn)問題時(shí)，就可以選取備份機(jī)中的其中一臺(tái)作為主機(jī)，另一臺(tái)依然是備機(jī)，集群還是高可用的。

這理由真讓人陶醉。按照這個(gè)邏輯，碰到傻子，我可以賣出100臺(tái)!

主備模式硬的不行，就要來軟的。采用主備的模式，使用軟件來完成切換過程。

如圖，使用keepalived組件，通過VRRP協(xié)議，即可完成最簡(jiǎn)單的高可用配置。

我們把DNS的地址綁定在VIP上，當(dāng)正在服務(wù)的Nginx發(fā)生問題，VIP會(huì)發(fā)生漂移，轉(zhuǎn)移到另外一臺(tái)Nginx上。

可以看到，備份的Nginx，正常情況下是無法進(jìn)行服務(wù)的，它也叫做影子節(jié)點(diǎn)，只有主Nginx發(fā)生問題的時(shí)候才有用。如果你的節(jié)點(diǎn)非常多，這種模式下，會(huì)有非常大的浪費(fèi)。

除了浪費(fèi)，還有一個(gè)非常大的問題。那就是，單臺(tái)Nginx無論性能多么牛X，總是有上限的。當(dāng)網(wǎng)卡的流量達(dá)到頂峰，接下來何去何從呢?

這種模式肯定是不滿足需求的。

簡(jiǎn)單組合模式這個(gè)時(shí)候，我們就可以配合DNS解析，以及主備模式做文章了。如下圖，DNS解析到兩個(gè)VIP上，VIP本身也做了高可用。這樣就能夠縮短故障時(shí)間，同時(shí)也能夠保證每個(gè)組件的高可用。

這種架構(gòu)模式思路是非常清晰的，但依然存在影子節(jié)點(diǎn)的浪費(fèi)。

LVS+KeepAlived+NginxLVS 是 Linux Virtual Server 的簡(jiǎn)稱，也就是 Linux 虛擬服務(wù)器。現(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分，從 Linux2.4 內(nèi)核以后，已經(jīng)完全內(nèi)置了 LVS 的各個(gè)功能模塊，無需給內(nèi)核打任何補(bǔ)丁，可以直接使用 LVS 提供的各種功能。

LVS工作在OSI模型的第4層：傳輸層，比如TCP/UDP，所以像7層網(wǎng)絡(luò)的HTTP協(xié)議，它是識(shí)別不出來的。也就是說，我們不能拿HTTP協(xié)議的一些內(nèi)容來控制路由，它的路由切入層次更低一些。

如下圖，LVS 架設(shè)的服務(wù)器集群系統(tǒng)有三個(gè)部分組成：

最前端的負(fù)載均衡層，用 Load Balancer 表示

中間的服務(wù)器集群層，用 Server Array 表示

最底端的數(shù)據(jù)共享存儲(chǔ)層，用 Shared Storage 表示

DR(直接路由)模式可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸，是目前采用最為廣泛的方式(數(shù)據(jù)不詳，fullnat模式使用也比較廣泛)。

所以，配合DNS的負(fù)載均衡，加上LVS的負(fù)載均衡，可以實(shí)現(xiàn)雙層的負(fù)載均衡和高可用。

如圖，DNS可以將請(qǐng)求綁定在VIP上。由于LVS DR模式的效率非常高，網(wǎng)卡要達(dá)到瓶頸也需要非常大的請(qǐng)求量(只有入口流量才走LVS)，所以一般通過LVS做nginx的負(fù)載均衡就足夠了。如果LVS還有瓶頸，那么就可以在DNS上再做文章。

還有哪些挑戰(zhàn)?其實(shí)，我們上面談到的這些方案，大多數(shù)是在同機(jī)房的。如果在多個(gè)機(jī)房，如何讓用戶選擇最快的節(jié)點(diǎn)、如何保證負(fù)載均衡，又是一個(gè)大的問題。另外，你可以看到數(shù)據(jù)包經(jīng)過層層的轉(zhuǎn)發(fā)和協(xié)調(diào)，還有多種負(fù)載均衡算法參與其中，如何保持會(huì)話，也是一個(gè)挑戰(zhàn)。一般的，四層會(huì)話會(huì)通過IP地址去實(shí)現(xiàn)，七層會(huì)話會(huì)通過cookie或者頭信息等去實(shí)現(xiàn)。

開發(fā)人員一般情況下接觸不到這么入口級(jí)的東西，但一旦遇到了，可能會(huì)受忙腳亂。本文是xjjdog根據(jù)一些即有的經(jīng)驗(yàn)進(jìn)行整理，希望你在公司需要一些高可用方案的時(shí)候，能夠助你一臂之力。

什么叫方案?你只需要 當(dāng)時(shí) 把你的領(lǐng)導(dǎo)哄好，讓他感覺很認(rèn)同的樣子就行了。至于要不要做，具體怎么做，那都是后面的事。君不見，扯了這么半天，很多企業(yè)其實(shí)一個(gè)nginx，就可以走天下。

作者簡(jiǎn)介：小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個(gè)人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。