文章轉(zhuǎn)載自公眾號：小姐姐味道
目前HTTP協(xié)議，乃至WebSocket協(xié)議，乃至采用了MQTT協(xié)議的WebSocket協(xié)議，都不可避免的使用了 Nginx 。所謂病從口入，禍從口出。作為入口，Nginx 承擔的責任非常的重要。假如某個時刻不能用了，那可真是災(zāi)難。
如何保證 Nginx 的高可用呢？這是個問題。不論你用什么樣的方案，到最后總是要歸為單一，很讓人苦惱。
所謂的高可用，無非兩種方式。一種方式就是在組件自身上做文章，另外一種方式，就是加入一個中間層。我們通常希望在高可用的時候，同時還能夠負載均衡，典型的貓和狗都想要，貪婪的很。
每當解決不了問題的時候，我們都會加入一個中間層，然后把希望寄托在這個新生的組件上。
如果這個中間層解決不了問題，我們就可以加入另外一個中間層。就這樣一層套一層，到最后系統(tǒng)高可用架構(gòu)就會變得非常復(fù)雜。
DNS保證高可用
第一種方式當然是要在 DNS 上做文章了。通過在 DNS 上，綁定多個 Nginx 的 IP 地址，即可完成高可用。不僅能夠完成高可用，還能順便完成負載均衡。
但這玩意有一個致命的問題，那就是故障的感知時間。
我們的瀏覽器在訪問到真正的 Nginx 之前，需要把域名轉(zhuǎn)化為真正的 IP 地址，DNS 就是干解析這個動作的，每次需要耗費20-20ms不等。
為了加快解析速度，一般都會有多級的緩存。比如瀏覽器就有 DNS 的緩存；你使用的 PC 機上也有這樣的緩存；IPS 服務(wù)提供商，也會有緩存；再加上有的企業(yè)為了加速訪問所自建的 DNS 服務(wù)器，中間的緩存層就更多了。
只有所有的緩存都不命中的情況下，DNS 才會查詢真正的 IP 地址。所以，如果有一臺 Nginx 當機了，這個故障的感知能力就會特別的差?？傆幸徊糠钟脩舻恼埱?，會落在這臺已經(jīng)死亡的機器上。
硬件保證高可用
我們前面說了。解決不了的問題，就可以加中間層，即使這個中間層是硬件，比如F5。
這種架構(gòu)一般的企業(yè)玩不起，只有那些采購有回扣有油水的公司，才會喜歡這個?；ヂ?lián)網(wǎng)中用的很少，就不過多介紹了。
當然，F(xiàn)5同樣有單點的問題。雖然硬件肯定要比軟件穩(wěn)定上一點，但是總歸是一個隱患。就像 Oracle 無論再厲害，它還是有出問題的時候，到時候備機是必須的。
有的廠商在賣硬件的時候，推薦你一次買3個！為啥呢？這也有理由。
你的一臺硬件正在服務(wù)，有兩臺備份機器。當你服務(wù)的這臺機器出現(xiàn)問題時，就可以選取備份機中的其中一臺作為主機，另一臺依然是備機，集群還是高可用的。
這理由真讓人陶醉。按照這個邏輯，碰到傻子，我可以賣出100臺！
主備模式
硬的不行，就要來軟的。采用主備的模式，使用軟件來完成切換過程。
如圖，使用keepalived組件，通過VRRP協(xié)議，即可完成最簡單的高可用配置。
我們把DNS的地址綁定在VIP上，當正在服務(wù)的Nginx發(fā)生問題，VIP會發(fā)生漂移，轉(zhuǎn)移到另外一臺Nginx上。
可以看到，備份的Nginx，正常情況下是無法進行服務(wù)的，它也叫做影子節(jié)點，只有主Nginx發(fā)生問題的時候才有用。如果你的節(jié)點非常多，這種模式下，會有非常大的浪費。
除了浪費，還有一個非常大的問題。那就是，單臺 Nginx 無論性能多么牛X，總是有上限的。當網(wǎng)卡的流量達到頂峰，接下來何去何從呢？
這種模式肯定是不滿足需求的。
簡單組合模式
這個時候，我們就可以配合 DNS 解析，以及主備模式做文章了。如下圖，DNS 解析到兩個 VIP 上，VIP 本身也做了高可用。這樣就能夠縮短故障時間，同時也能夠保證每個組件的高可用。
這種架構(gòu)模式思路是非常清晰的，但依然存在影子節(jié)點的浪費。
LVS+KeepAlived+Nginx
LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務(wù)器?，F(xiàn)在 LVS 已經(jīng)是 Linux 標準內(nèi)核的一部分，從 Linux2.4 內(nèi)核以后，已經(jīng)完全內(nèi)置了 LVS 的各個功能模塊，無需給內(nèi)核打任何補丁，可以直接使用 LVS 提供的各種功能。
LVS 工作在 OSI 模型的第4層：傳輸層，比如 TCP/UDP，所以像7層網(wǎng)絡(luò)的 HTTP 協(xié)議，它是識別不出來的。也就是說，我們不能拿 HTTP 協(xié)議的一些內(nèi)容來控制路由，它的路由切入層次更低一些。
如下圖，LVS 架設(shè)的服務(wù)器集群系統(tǒng)有三個部分組成：
- 最前端的負載均衡層，用 Load Balancer 表示
- 中間的服務(wù)器集群層，用 Server Array 表示
- 最底端的數(shù)據(jù)共享存儲層，用 Shared Storage 表示
DR（直接路由）模式可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸，是目前采用最為廣泛的方式（數(shù)據(jù)不詳，fullnat模式使用也比較廣泛）。
所以，配合 DNS 的負載均衡，加上LVS的負載均衡，可以實現(xiàn)雙層的負載均衡和高可用。
如圖，DNS 可以將請求綁定在 VIP 上。由于 LVS DR 模式的效率非常高，網(wǎng)卡要達到瓶頸也需要非常大的請求量（只有入口流量才走LVS），所以一般通過 LVS 做 nginx 的負載均衡就足夠了。如果 LVS 還有瓶頸，那么就可以在 DNS 上再做文章。
還有哪些挑戰(zhàn)？
其實，我們上面談到的這些方案，大多數(shù)是在同機房的。如果在多個機房，如何讓用戶選擇最快的節(jié)點、如何保證負載均衡，又是一個大的問題。另外，你可以看到數(shù)據(jù)包經(jīng)過層層的轉(zhuǎn)發(fā)和協(xié)調(diào)，還有多種負載均衡算法參與其中，如何保持會話，也是一個挑戰(zhàn)。一般的，四層會話會通過 IP 地址去實現(xiàn)，七層會話會通過 cookie 或者頭信息等去實現(xiàn)。
開發(fā)人員一般情況下接觸不到這么入口級的東西，但一旦遇到了，可能會受忙腳亂。本文是xjjdog根據(jù)一些即有的經(jīng)驗進行整理，希望你在公司需要一些高可用方案的時候，能夠助你一臂之力。
什么叫方案？你只需要 當時 把你的領(lǐng)導(dǎo)哄好，讓他感覺很認同的樣子就行了。至于要不要做，具體怎么做，那都是后面的事。君不見，扯了這么半天，很多企業(yè)其實一個nginx，就可以走天下。
以上就是W3Cschool編程獅關(guān)于HA（高可用）就像套娃，像胖子，剝掉一層還有一層的相關(guān)介紹了，希望對大家有所幫助。
