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

這個問題很難，涉及到 HTTP，TCP，網(wǎng)關(guān)，LVS 等一系列相關(guān)的概念及諸多協(xié)議的工作機(jī)制，如果你能掌握到這其中的每個知識點，那將極大地點亮你的技能樹,對于網(wǎng)絡(luò)是如何運作也會了然于胸，即便不能完全掌握，但知道流量怎么流轉(zhuǎn)的對你排查定位問題會大有幫助，我之前就利用這些知識定位到不少問題，為了弄清楚整個流程，我查閱了很多資料，相信應(yīng)該可以把這個問題講明白，不過寫著寫著發(fā)現(xiàn)篇幅實在太長，所以分為上下兩篇來分別介紹一下，本篇先介紹流量在后端的的整體架構(gòu)圖，下一篇會深入剖析各個細(xì)節(jié)點，如 LVS ，NAT 的工作細(xì)節(jié)等，這其中會涉及到交換機(jī)，路由器的工作機(jī)制等知識點，相信大家看了肯定有幫助

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

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

現(xiàn)在問題來了，client 到底該打向這三臺機(jī)器的哪一臺呢，如果讓 client 來選擇肯定不合適，因為如果讓 client 來選擇具體的 server，那么它必須知道有哪幾臺 server，然后再用輪詢等方式隨機(jī)連接其中一臺機(jī)器，但如果其中某臺 server 宕機(jī)了，client 是無法提前感知到的，那么很可能 client 會連接到這臺掛掉的 server 上，所以選擇哪臺機(jī)器來連接的工作最好放在 server 中，具體怎么做呢，在架構(gòu)設(shè)計中有個經(jīng)典的共識：沒有什么是加一層解決不了的，如果有那就再加一層，所以我們在 server 端再加一層，將其命名為 LB（Load Balance，負(fù)載均衡），由 LB 統(tǒng)一接收 client 的請求，然后再由它來決定具體與哪一個 server 通信，一般業(yè)界普遍使用 Nginx 作為 LB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果不用 LVS 則架構(gòu)圖是這樣的

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

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

總結(jié)

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

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

以上就是本文的全部內(nèi)容，希望大家看了有收獲^^，下一篇我們再繼續(xù)深入探究一個請求的往返鏈路，會深入剖析 LVS，交換機(jī)，路由器等的工作原理，敬請期待 ^^