前言

??????加入了微博以后，經常聽到運維老師說到四層負載均衡，當然，年輕的我也是淺顯的理解，哦，要用四層負載均衡，得申請?zhí)摂MIP(VIP)，得確定服務端口。可是經歷一段時間，我申請負載均衡的時候，公司的運維老師又跟我說，你申請七層的吧，七層的方便管理，(內心ps：專業(yè)性有點強啊，啥是七層，四層都沒搞明白呢，咋又來了個七層），“好的，老師，我在xxx后臺申請是吧，咱七層的好處是？”。吧啦吧啦。。。。。運維老師說了一堆，我似懂非懂的聽完恩了一聲就走了，回來一想，咱得弄明白啊，不然顯不出咱是高級工程師。于是網上各種搜索文章，終于找到了一篇“傳道授業(yè)解惑”的文章，分享給大家。

第一部分：簡單理解四層和七層負載均衡

• 所謂四層就是基于IP+端口的負載均衡；七層就是基于URL等應用層信息的負載均衡；同理，還有基于MAC地址的二層負載均衡和基于IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然后再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然后再分配到真實的IP地址；四層通過虛擬IP+端口接收請求，然后再分配到真實的服務器；七層通過虛擬的URL或主機名接收請求，然后再分配到真實的服務器。

• 所謂的四到七層負載均衡，就是在對后臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎么樣轉發(fā)流量。 比如四層的負載均衡，就是通過發(fā)布三層的IP地址（VIP），然后加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發(fā)至后臺服務器，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，后續(xù)這個連接的所有流量都同樣轉發(fā)到同一臺服務器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特征，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web服務器分成兩組，一組是中文語言的，一組是英文語言的，那么七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然后選擇對應的語言服務器組進行負載均衡處理。

• 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現(xiàn)四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協(xié)議URI或Cookie信息。

1. 負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解為應用協(xié)議（如HTTP/FTP/MySQL等等）。例子：LVS，F(xiàn)5。
2. 另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解為應用協(xié)議。例子： haproxy，MySQL Proxy。

注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。

第二部分：四層和七層兩者到底區(qū)別

一、技術原理上的區(qū)別

??????所謂四層負載均衡，也就是主要通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
??????以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的服務器，并對報文中目標IP地址進行修改(改為后端服務器IP），直接轉發(fā)給該服務器。TCP的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡設備只是起到一個類似路由器的轉發(fā)動作。在某些部署情況下，為保證服務器回包可以正確返回給負載均衡設備，在轉發(fā)報文的同時可能還會對報文原來的源地址進行修改。

image.png

二、應用場景的需求

?????? 七層應用負載的好處 ，是使得整個網絡更"智能化"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發(fā)到特定的圖片服務器并可以使用緩存技術；將對文字類的請求可以轉發(fā)到特定的文字服務器并可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提升了應用系統(tǒng)在網絡層的靈活性。很多在后臺，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。
??????另外一個常常被提到功能就是安全性。網絡中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標發(fā)送SYN攻擊，通常這種攻擊會大量發(fā)送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發(fā)到后端的服務器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響后臺服務器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統(tǒng)整體安全。
??????現(xiàn)在的7層負載均衡，主要還是著重于應用HTTP協(xié)議，所以其應用范圍主要是眾多的網站或者內部信息平臺等基于B/S開發(fā)的系統(tǒng)。 4層負載均衡則對應其他TCP應用，例如基于C/S開發(fā)的ERP等系統(tǒng)。

三、七層應用需要考慮的問題

• 是否真的必要。七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置復雜，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統(tǒng)時需要考慮四層七層同時應用的混雜情況。

• 是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使服務器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。

• 是否有足夠的靈活度。七層應用的優(yōu)勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基于應用的調度。最簡單的一個考核就是能否取代后臺Nginx或者Apache等服務器上的調度功能。能夠提供一個七層應用開發(fā)接口的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。
  （本節(jié)出自 “ADC技術博客” 博客，請務必保留此出處http://virtualadc.blog.51cto.com/3027116/591396）

第三部分：負載均衡策略

• 輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N然后重新開始。此種均衡算法適合于服務器組中的所有服務器都有相同的軟硬件配置并且平均服務請求相對均衡的情況。

• 權重輪循均衡（Weighted Round Robin）：根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是 3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。

• 隨機均衡（Random）：把來自網絡的請求隨機分配給內部中的多個服務器。

• 權重隨機均衡（Weighted Random）：此種均衡算法類似于權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。

• 響應速度均衡（Response Time）：負載均衡設備對內部各服務器發(fā)出一個探測請求（例如Ping），然后根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態(tài)，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。

• 最少連接數均衡（Least Connection）：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨著工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一臺服務器上的連接進程可能會產生極大的不同，并沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。

• 處理能力均衡：此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的服務器，由于考慮到了內部服務器的處理能力及當前網絡運行狀況，所以此種均衡算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。

• DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到服務器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，并在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在同一位地理位置的服務器的IP地址）并返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續(xù)請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。

第四部分：引入均衡方案時可能要考慮的問題

• 性能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鐘通過網絡的數據包數目做為一個參數，另一個參數是均衡方案中服務器群所能處理的最大并發(fā)連接數目，但是，假設一個均衡系統(tǒng)能處理百萬計的并發(fā)連接數，可是卻只能以每秒2個包的速率轉發(fā)，這顯然是沒有任何作用的。性能的優(yōu)劣與負載均衡設備的處理能力、采用的均衡策略息息相關，并且有兩點需要注意：一、均衡方案對服務器群整體的性能，這是響應客戶端連接請求速度的關鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮采用混合型負載均衡策略來提升服務器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態(tài)文檔請求的站點，也可以考慮采用高速緩存技術，相對來說更節(jié)省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮采用ssl/xml加速技術。

• 可擴展性：IT技術日新月異，一年以前最新的產品，現(xiàn)在或許已是網絡中性能最低的產品；業(yè)務量的急速上升，一年前的網絡，現(xiàn)在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求，能均衡不同操作系統(tǒng)和硬件平臺之間的負載，能均衡HTTP、郵件、新聞、代理、數據庫、防火墻和 Cache等不同服務器的負載，并且能以對客戶端完全透明的方式動態(tài)增加或刪除某些資源。

• 靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的服務器群有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。

• 可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為服務器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現(xiàn)故障時，應該有良好的冗余解決方案，提高可靠性。使用冗余時，處于同一個冗余單元的多個負載均衡設備必須具有有效的方式以便互相進行監(jiān)控，保護系統(tǒng)盡可能地避免遭受到重大故障的損失。

• 易管理性：不管是通過軟件還是硬件方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便于安裝、配置、維護和監(jiān)控，提高工作效率，避免差錯。在硬件負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行接口（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串行接口來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶接口（GUI：Graphical User Interfaces），有基于普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management Protocol，簡單網絡管理協(xié)議）支持，通過第三方網絡管理軟件對符合SNMP標準的設備進行管理。

??????原文鏈接：
1.https://blog.csdn.net/azzfanke/article/details/2234301
2.https://blog.csdn.net/friends99/article/details/79803638
3.http://virtualadc.blog.51cto.com/3027116/591396