大家知道什么是負(fù)載均衡嗎

相信大家都聽(tīng)過(guò)這樣的一道經(jīng)典面試題：「請(qǐng)說(shuō)出在淘寶網(wǎng)輸入一個(gè)關(guān)鍵詞到最終展示網(wǎng)頁(yè)的整個(gè)流程，越詳細(xì)越好」

這個(gè)問(wèn)題很難，涉及到 HTTP，TCP，網(wǎng)關(guān)，LVS 等一系列相關(guān)的概念及諸多協(xié)議的工作機(jī)制，如果你能掌握到這其中的每個(gè)知識(shí)點(diǎn)，那將極大地點(diǎn)亮你的技能樹，對(duì)于網(wǎng)絡(luò)是如何運(yùn)作也會(huì)了然于胸，即便不能完全掌握，但知道流量怎么流轉(zhuǎn)的對(duì)你排查定位問(wèn)題會(huì)大有幫助。

我之前就利用這些知識(shí)定位到不少問(wèn)題，為了弄清楚整個(gè)流程，我查閱了很多資料，相信應(yīng)該可以把這個(gè)問(wèn)題講明白，不過(guò)寫著寫著發(fā)現(xiàn)篇幅實(shí)在太長(zhǎng)，所以分為上下兩篇來(lái)分別介紹一下，本篇先介紹流量在后端的的整體架構(gòu)圖，下一篇會(huì)深入剖析各個(gè)細(xì)節(jié)點(diǎn)，如 LVS ，NAT 的工作細(xì)節(jié)等，這其中會(huì)涉及到交換機(jī)，路由器的工作機(jī)制等知識(shí)點(diǎn)，相信大家看了肯定有幫助

李大牛創(chuàng)業(yè)了，由于前期沒(méi)啥流量，所以他只部署了一臺(tái) tomcat server，讓客戶端將請(qǐng)求直接打到這臺(tái) server 上

這樣部署一開始也沒(méi)啥問(wèn)題，因?yàn)闃I(yè)務(wù)量不是很大，單機(jī)足以扛住，但后來(lái)李大牛的業(yè)務(wù)踩中了風(fēng)口，業(yè)務(wù)迅猛發(fā)展，于是單機(jī)的性能逐漸遇到了瓶頸，而且由于只部署了一臺(tái)機(jī)器，這臺(tái)機(jī)器掛掉了業(yè)務(wù)也就跌零了，這可不行，所以為了避免單機(jī)性能瓶頸與解決單點(diǎn)故障的隱患，李大牛決定多部署幾臺(tái)機(jī)器（假設(shè)為三臺(tái)），這樣可以讓 client 隨機(jī)打向其中的一臺(tái)機(jī)器，這樣就算其中一臺(tái)機(jī)器掛了，另外的機(jī)器還存活，讓 client 打向其它沒(méi)有宕機(jī)的機(jī)器即可

現(xiàn)在問(wèn)題來(lái)了，client 到底該打向這三臺(tái)機(jī)器的哪一臺(tái)呢，如果讓 client 來(lái)選擇肯定不合適，因?yàn)槿绻?client 來(lái)選擇具體的 server，那么它必須知道有哪幾臺(tái) server，然后再用輪詢等方式隨機(jī)連接其中一臺(tái)機(jī)器，但如果其中某臺(tái) server 宕機(jī)了，client 是無(wú)法提前感知到的。

那么很可能 client 會(huì)連接到這臺(tái)掛掉的 server 上，所以選擇哪臺(tái)機(jī)器來(lái)連接的工作最好放在 server 中，具體怎么做呢，在架構(gòu)設(shè)計(jì)中有個(gè)經(jīng)典的共識(shí)：沒(méi)有什么是加一層解決不了的，如果有那就再加一層，所以我們?cè)?server 端再加一層，將其命名為 LB（Load Balance，負(fù)載均衡），由 LB 統(tǒng)一接收 client 的請(qǐng)求，然后再由它來(lái)決定具體與哪一個(gè) server 通信，一般業(yè)界普遍使用 Nginx 作為 LB

采用這樣的架構(gòu)設(shè)計(jì)總算支撐了業(yè)務(wù)的快速增長(zhǎng)，但隨后不久李大牛發(fā)現(xiàn)這樣的架構(gòu)有點(diǎn)問(wèn)題：所有的流量都能打到 server 上，這顯然是有問(wèn)題的，不太安全，那能不能在流量打到 server 前再做一層鑒權(quán)操作呢，鑒權(quán)通過(guò)了我們才讓它打到 server 上，我們把這一層叫做網(wǎng)關(guān)（為了避免單點(diǎn)故障，網(wǎng)關(guān)也要以集群的形式存在）

這樣的話所有的流量在打到 server 前都要經(jīng)過(guò)網(wǎng)關(guān)這一層，鑒權(quán)通過(guò)后才把流量轉(zhuǎn)發(fā)到 server 中，否則就向 client 返回報(bào)錯(cuò)信息，除了鑒權(quán)外，網(wǎng)關(guān)還起到風(fēng)控（防止羊毛黨），協(xié)議轉(zhuǎn)換（比如將 HTTP 轉(zhuǎn)換成 Dubbo），流量控制等功能，以最大程度地保證轉(zhuǎn)發(fā)給 server 的流量是安全的，可控的。

這樣的設(shè)計(jì)持續(xù)了很長(zhǎng)一段時(shí)間，但是后來(lái)李大牛發(fā)現(xiàn)這樣的設(shè)計(jì)其實(shí)還是有問(wèn)題，不管是動(dòng)態(tài)請(qǐng)求，還是靜態(tài)資源（如 js，css文件）請(qǐng)求都打到 tomcat 了，這樣在流量大時(shí)會(huì)造成 tomcat 承受極大的壓力，其實(shí)對(duì)于靜態(tài)資源的處理 tomcat 不如 Nginx，tomcat 每次都要從磁盤加載文件比較影響性能，而 Nginx 有 proxy cache 等功能可以極大提升對(duì)靜態(tài)資源的處理能力。

畫外音：所謂的 proxy cache 是指 nginx 從靜態(tài)資源服務(wù)器上獲取資源后會(huì)緩存在本地的內(nèi)存+磁盤中，下次請(qǐng)求如果命中緩存就從 Nginx 本機(jī)的 Cache 中直接返回了

所以李大牛又作了如下優(yōu)化：如果是動(dòng)態(tài)請(qǐng)求，則經(jīng)過(guò) gateway 打到 tomcat，如果是 Nginx，則打到靜態(tài)資源服務(wù)器上

這就是我們所說(shuō)的動(dòng)靜分離，將靜態(tài)請(qǐng)求與動(dòng)態(tài)請(qǐng)求分開，這樣 tomcat 就可以專注于處理其擅長(zhǎng)的動(dòng)態(tài)請(qǐng)求，而靜態(tài)資源由于利用到了 Nginx 的 proxy cache 等功能，后端的處理能力又上了一個(gè)臺(tái)階。

另外需要注意的是并不是所有的動(dòng)態(tài)請(qǐng)求都需要經(jīng)過(guò)網(wǎng)關(guān)，像我們的運(yùn)營(yíng)中心后臺(tái)由于是內(nèi)部員工使用的，所以它的鑒權(quán)與網(wǎng)關(guān)的 api 鑒權(quán)并不相同，所以我們直接部署了兩臺(tái)運(yùn)營(yíng)中心的 server ，直接讓 Nginx 將運(yùn)營(yíng)中心的請(qǐng)求打到了這兩臺(tái) server 上，繞過(guò)了網(wǎng)關(guān)。

當(dāng)然為了避免單點(diǎn)故障 Nginx 也需要部署至少兩臺(tái)機(jī)器，于是我們的架構(gòu)變成了下面這樣，Nginx 部署兩臺(tái)，以主備的形式存在，備 Nginx 會(huì)通過(guò) keepalived 機(jī)制（發(fā)送心跳包） 來(lái)及時(shí)感知到主 Nginx 的存活，發(fā)現(xiàn)宕機(jī)自己就頂上充當(dāng)主 Nginx 的角色

看起來(lái)這樣的架構(gòu)確實(shí)不錯(cuò)，但要注意的是 Nginx 是七層（即應(yīng)用 層）負(fù)載均衡器 ，這意味著如果它要轉(zhuǎn)發(fā)流量首先得和 client 建立一個(gè) TCP 連接，并且轉(zhuǎn)發(fā)的時(shí)候也要與轉(zhuǎn)發(fā)到的上游 server 建立一個(gè) TCP 連接，而我們知道建立 TCP 連接其實(shí)是需要耗費(fèi)內(nèi)存（TCP Socket，接收/發(fā)送緩存區(qū)等需要占用內(nèi)存）的，客戶端和上游服務(wù)器要發(fā)送數(shù)據(jù)都需要先發(fā)送暫存到到 Nginx 再經(jīng)由另一端的 TCP 連接傳給對(duì)方。

所以 Nginx 的負(fù)載能力受限于機(jī)器I/O，CPU內(nèi)存等一系列配置，一旦連接很多（比如達(dá)到百萬(wàn)）的話，Nginx 抗負(fù)載能力就會(huì)急遽下降。

經(jīng)過(guò)分析可知 Nginx 的負(fù)載能力較差主要是因?yàn)樗瞧邔迂?fù)載均衡器必須要在上下游分別建立兩個(gè) TCP 所致，那么是否能設(shè)計(jì)一個(gè)類似路由器那樣的只負(fù)載轉(zhuǎn)發(fā)包但不需要建立連接的負(fù)載均衡器呢，這樣由于不需要建立連接，只負(fù)責(zé)轉(zhuǎn)發(fā)包，不需要維護(hù)額外的 TCP 連接，它的負(fù)載能力必然大大提升，于是四層負(fù)載均衡器 LVS 就誕生了，簡(jiǎn)單對(duì)比下兩者的區(qū)別

可以看到 LVS 只是單純地轉(zhuǎn)發(fā)包，不需要和上下游建立連接即可轉(zhuǎn)發(fā)包，相比于 Nginx 它的抗負(fù)載能力強(qiáng)、性能高（能達(dá)到 F5 硬件的 60%），對(duì)內(nèi)存和cpu資源消耗比較低

那么四層負(fù)載均衡器是如何工作的呢

負(fù)載均衡設(shè)備在接收到第一個(gè)來(lái)自客戶端的SYN 請(qǐng)求時(shí)，即通過(guò)負(fù)載均衡算法選擇一個(gè)最佳的服務(wù)器，并對(duì)報(bào)文中目標(biāo)IP地址進(jìn)行修改（改為后端服務(wù)器 IP ），直接轉(zhuǎn)發(fā)給該服務(wù)器。TCP 的連接建立，即三次握手是客戶端和服務(wù)器直接建立的，負(fù)載均衡設(shè)備只是起到一個(gè)類似路由器的轉(zhuǎn)發(fā)動(dòng)作。在某些部署情況下，為保證服務(wù)器回包可以正確返回給負(fù)載均衡設(shè)備，在轉(zhuǎn)發(fā)報(bào)文的同時(shí)可能還會(huì)對(duì)報(bào)文原來(lái)的源地址進(jìn)行修改。

綜上所述，我們?cè)?Nginx 上再加了一層 LVS，以讓它來(lái)承接我們的所有流量，當(dāng)然為了保證 LVS 的可用性，我們也采用主備的方式部署 LVS，另外采用這種架構(gòu)如果 Nginx 容量不夠我們可以很方便地進(jìn)行水平擴(kuò)容，于是我們的架構(gòu)改進(jìn)如下：

當(dāng)然只有一臺(tái) LVS 的話在流量很大的情況下也是扛不住的，怎么辦，多加幾臺(tái)啊，使用 DNS 負(fù)載均衡，在 DNS 服務(wù)器解析域名的時(shí)候隨機(jī)打到其中一臺(tái) LVS 不就行了

通過(guò)這樣的方式終于可以讓流量穩(wěn)定流轉(zhuǎn)了，有個(gè)點(diǎn)可能一些朋友會(huì)有疑問(wèn)，下面我們一起來(lái)看看

既然 LVS 可以采用部署多臺(tái)的形式來(lái)避免單點(diǎn)故障，那 Nginx 也可以啊，而且 Nginx 在 1.9 之后也開始支持四層負(fù)載均衡了，所以貌似 LVS 不是很有必要？

通過(guò)部署多臺(tái) Nginx 的方式在流量不是那么大的時(shí)候確實(shí)是可行，但 LVS 是 Linux 的內(nèi)核模塊，工作在內(nèi)核態(tài)，而 Nginx 工作在用戶態(tài)，也相對(duì)比較重，所以在性能和穩(wěn)定性上 Nginx 是不如 LVS 的，這就是為什么我們要采用 LVS + Nginx 的部署方式。

另外相信大家也注意到了，如果流量很大時(shí)，靜態(tài)資源應(yīng)該部署在 CDN 上， CDN 會(huì)自動(dòng)選擇離用戶最近的節(jié)點(diǎn)返回給用戶，所以我們最終的架構(gòu)改進(jìn)如下

總結(jié)架構(gòu)一定要結(jié)合業(yè)務(wù)的實(shí)際情況來(lái)設(shè)計(jì)，脫離業(yè)務(wù)談架構(gòu)其實(shí)是耍流氓，可以看到上文每一個(gè)架構(gòu)的衍化都與我們的業(yè)務(wù)發(fā)展息息相關(guān)，對(duì)于中小型流量沒(méi)有那么大的公司，其實(shí)用 Nginx 作為負(fù)載均衡足夠，在流量迅猛增長(zhǎng)后則考慮使用 lvs+nginx，當(dāng)然像美團(tuán)這樣的巨量流量（數(shù)十 Gbps的流量、上千萬(wàn)的并發(fā)連接），lvs 也不管用了（實(shí)測(cè)雖然使用了 lvs 但依然出現(xiàn)了不少丟包的現(xiàn)象）所以它們開發(fā)出了自己的一套四層負(fù)載均衡器 MGW

另外看了本文相信大家對(duì)分層的概念應(yīng)該有更透徹的理解，沒(méi)有什么是分層解決不了的事，如果有，那就再多加一層，分層使每個(gè)模塊各司其職，功能解藕，而且方便擴(kuò)展，大家很熟悉的 TCP/IP 就是個(gè)很好的例子，每層只管負(fù)責(zé)自己的事，至于下層是什么實(shí)現(xiàn)的上層是不 care 的

以上就是本文的全部?jī)?nèi)容，希望大家看了有收獲

編輯：jq