實現(xiàn)高可用的思路和負(fù)載均衡的一些解決方案

下文給大家?guī)韺崿F(xiàn)高可用的思路和負(fù)載均衡的一些解決方案，希望能夠給大家在實際運用中帶來一定的幫助，負(fù)載均衡涉及的東西比較多，理論也不多，網(wǎng)上有很多書籍，今天我們就用億速云在行業(yè)內(nèi)累計的經(jīng)驗來做一個解答。

一、為什么沒有DNS？

再翻出第一篇中放出的一張圖來回顧一下。

cdn.xitu.io/2018/10/22/1669bee11791a171?w=1099&h=1043&f=png&s=76592">

之前也有的小伙伴問到，為什么沒有列出DNS？我認(rèn)為，DNS的本質(zhì)是解決「domain name --> ip」的問題。雖然DNS除了在公網(wǎng)運用的之外，還會運用于做內(nèi)網(wǎng)的自定義domain name解析，但是在程序里單靠它來做負(fù)載均衡的話，還是太勉強了。

當(dāng)然，基于DNS“智能解析”功能可以做到IP的動態(tài)返回，也算起到了負(fù)載均衡的作用。但是，由于其本身是一個工作在L3（網(wǎng)絡(luò)層）的解決方案，所以無法對“端口”進行工作。而一般我們程序之間的通訊很多都會涉及到端口，因此我們本篇先不討論DNS~

二、如何實施？

在清楚了我們應(yīng)該在哪些環(huán)節(jié)考慮做負(fù)載均衡之后，接下去就是思考如何能夠循序漸進的進行。

古時候軍隊打仗的時候一般都是拿盾的抗在前面，頂住***。而負(fù)載均衡解決方案從某種角度來說也是一個類似盾一般的防御性設(shè)施，因為前提就是要能承載上游過來的流量。因此，越往“前”做負(fù)載均衡解決方案，效果肯定會越好，因為受保護的應(yīng)用范圍越廣。

如果說，系統(tǒng)之前沒有運用過負(fù)載均衡，現(xiàn)在開始第一次做，該如何選擇呢？小Z根據(jù)心目當(dāng)中的優(yōu)先級來和大家聊一下。

01 硬件負(fù)載均衡

硬件這塊名氣最大的還屬F5（根據(jù)ZOL的數(shù)據(jù)，其在市場占有率51.44%），大大蓋過了其它幾家硬件商的風(fēng)頭。此類硬件負(fù)載均衡器的特點是“壕”，畢竟是純商業(yè)化的東西，投入的資源和精力自然是眾多開源軟件負(fù)載均衡所無法比擬的，所以功能非常強大。包含訪問加速、壓縮、安全等等負(fù)載均衡之外的許多附加功能。

題外話：如果用F5組網(wǎng)的話，有兩種結(jié)構(gòu)，串行結(jié)構(gòu)和并行結(jié)構(gòu)，也稱為直連模式和旁路模式。前者的優(yōu)勢在對硬件產(chǎn)生壓力較小、且天然安全性高，而后者對原網(wǎng)絡(luò)架構(gòu)的改動較小、且擴展性較好。大家在實際的使用中結(jié)合自身情況來部署。

“壕”物能夠同時支持L2~L7的轉(zhuǎn)發(fā)，所以上圖中的每一個標(biāo)注點都可以用硬件來做負(fù)載均衡。因此，如果在經(jīng)濟允許的情況下，直接上F5能解決很多原本需要花更多時間去解決的問題。所以當(dāng)“時間”的重要度大于“金錢”的時候，建議優(yōu)先采用硬件方案。

02 軟件負(fù)載均衡（L7）

當(dāng)“金錢”的重要程度大于“時間”的時候，我們可以通過軟件來達到我們要的效果。相應(yīng)的，也增加了一些運維成本。

一般情況下，只要對數(shù)據(jù)庫不濫用，往往我們從「單應(yīng)用 + 單庫」組合最先需要突破的是應(yīng)用，變成「多應(yīng)用 + 單庫」。那么針對Web應(yīng)用的L7負(fù)載均衡，比較主流的產(chǎn)品是2個Nginx、HAProxy。在L7做負(fù)載均衡，最大的特點就是靈活，請求的URL、Header都是我們可以去掌控的，所以我們可以利用其中的任何信息為負(fù)載均衡策略所用。

這一類就是前面圖中的「反向代理」。作為「客戶端」和「Web應(yīng)用」、「前端」和「后端」之間的橋梁。實際操作中主要做2步：

1. 在公網(wǎng)的域名解析中，配置解析到「反向代理」。記錄類型是「A」，記錄值是「反向代理」的IP。
   

2. 配置真實提供服務(wù)的Web應(yīng)用IP和端口，和負(fù)載均衡均衡策略。上圖中的配置是Nginx中的示例，負(fù)載均衡策略的缺省值是輪詢。
   

03 軟件負(fù)載均衡（L4）

當(dāng)「Web應(yīng)用」所依賴的TCP協(xié)議的「服務(wù)」需要橫向擴展，或者需要做「數(shù)據(jù)庫」、「分布式緩存」的多主、主從集群時，那么就需要一個支持L4的負(fù)載均衡軟件。這里最知名的就屬LVS了，1998年5月由章文嵩博士建立，2004年底被納入Lunix內(nèi)核。也正因為它是內(nèi)核態(tài)的程序，所以相比用Nginx、HAProxy來做L4的負(fù)載均衡，在性能、資源的消耗上會更優(yōu)一些。

實際運用中的操作步驟主要也是2步：

1. 1在LVS中添加一個IP虛擬服務(wù)（IPVS），并指定它的IP、端口和負(fù)載均衡策略。
   

2. 將IP虛擬服務(wù)關(guān)聯(lián)到真實的服務(wù)上，并指定模式和權(quán)重的信息。（做L4的負(fù)載均衡可以使用NAT或者FULLNAT模式）
   

題外話：LVS的模式一共有四種，除了NAT和FULLNAT（NAT的增強版）模式外，它的TUN模式可以在L3做負(fù)載均衡，DR模式可以在L2做負(fù)載均衡，到這個層面其實就和做硬件同處于一個層次了。并且，隨著層次的深入，雖然對功能性上有所弱化，但是如果不考慮端口的話，單從IP層面的負(fù)載均衡來說，用DR模式做，則對數(shù)據(jù)包的加工介入度會降到最低，因此也是通過軟件做負(fù)載均衡能夠達到的性能極致。

另外，LVS中運用的虛擬IP概念，本質(zhì)上和Nginx中的“server”概念一樣，定義了一個統(tǒng)一入口，作用上并沒有差別。將Nginx中的upstream關(guān)聯(lián)到server，就如LVS操作步驟第2點中的關(guān)聯(lián)一般。

這些每個具體的解決方案的使用教程網(wǎng)上比較多，就不展開了，大家實際用到的時候自行查閱一下，當(dāng)然盡量優(yōu)先看官方的。

三、優(yōu)缺點

做了一個苦差事，把所有同類型的產(chǎn)品都整合了一下優(yōu)缺點和使用場景。不過，其中有不少是我沒用過的，所以僅供大家參考。順手將一些網(wǎng)上到處充斥的一些過時結(jié)論做了更新，如：Nginx不支持session sticky等。

我們可以看到，不同的解決方案有不同的側(cè)重點。因此在單個解決方案已經(jīng)無法滿足的情況下，我們可以組合使用，各盡所長。

負(fù)載均衡這個領(lǐng)域還是以高可用和性能為2個最重要因素，下面是小Z推薦的一種組合方式，也是在系統(tǒng)量級達到每小時上億PV之后最被廣泛使用的一種。理論上，利用第一步DNS的域名解析所帶的負(fù)載均衡效果，只要復(fù)制多套LVS主備出來，綁上多個不同的虛IP，可以做到無限橫向擴展，以支撐不斷增長的流量。

用到的3個軟件目前都是開源產(chǎn)品，LVS+Keepalived負(fù)責(zé)做Nginx的負(fù)載均衡，而Nginx負(fù)責(zé)分發(fā)到實際的請求到Http和Tcp協(xié)議的應(yīng)用上。

關(guān)于LVS的模式選擇，如果在同網(wǎng)段內(nèi)的話優(yōu)先使用DR模式進行L2轉(zhuǎn)發(fā)，性能最好。否則使用TUN模式進行L3分發(fā)。與此同時，在L4、L7的分發(fā)上使用Nginx來做，可以發(fā)揮其靈活易擴展的特點以及其它的一些額外特性如緩存等，也算是物盡其用。

云時代，service mesh風(fēng)興起。以sidecar模式為核心的后起之秀Linkerd、Conduit、NginMesh、Istio等軟件除了滿足負(fù)載均衡之外，還為高可用相關(guān)的做了眾多的考量，后續(xù)有機會小Z和大家一起來梳理一下。很久之前寫過一篇調(diào)研服務(wù)治理框架的文章，里面順帶有提到一下，有興趣的小伙伴們可以跳過去看看：《分布式系統(tǒng)中的必備良藥 —— 服務(wù)治理》。

看了以上關(guān)于實現(xiàn)高可用的思路和負(fù)載均衡的一些解決方案，如果大家還有什么地方需要了解的可以在億速云行業(yè)資訊里查找自己感興趣的或者找我們的專業(yè)技術(shù)工程師解答的，億速云技術(shù)工程師在行業(yè)內(nèi)擁有十幾年的經(jīng)驗了。