相信大家都聽過這樣的一道經典面試題：「請說出在淘寶網輸入一個關鍵詞到最終展示網頁的整個流程，越詳細越好」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果不用 LVS 則架構圖是這樣的

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

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

總結

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

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

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