負載均衡權重演算法

1. 四層負載均衡和七層負載均衡的區別

（一）
簡單理解四層和七層負載均衡:
① 所謂四層就是基於IP+埠的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+埠接收請求，然後再分配到真實的伺服器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的伺服器。
② 所謂的四到七層負載均衡，就是在對後台的伺服器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發布三層的IP地址（VIP），然後加四層的埠號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後台伺服器，並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接的所有流量都同樣轉發到同一台伺服器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言伺服器組進行負載均衡處理。
③ 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
（二）
負載均衡設備也常被稱為"四到七層交換機"，那麼四層和七層兩者到底區別在哪裡？
第一，技術原理上的區別。
所謂四層負載均衡，也就是主要通過報文中的目標地址和埠，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連接建立，即三次握手是客戶端和伺服器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

所謂七層負載均衡，也稱為「內容交換」，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連接(三次握手)後，才可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。負載均衡設備在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
第二，應用場景的需求。
七層應用負載的好處，是使得整個網路更"智能化"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。很多在後台，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，伺服器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，通常這種攻擊會大量發送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響後台伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。
現在的7層負載均衡，主要還是著重於應用HTTP協議，所以其應用范圍主要是眾多的網站或者內部信息平台等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
第三，七層應用需要考慮的問題。

1：是否真的必要，七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置復雜，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2：是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從伺服器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3：是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的調度。最簡單的一個考核就是能否取代後台Nginx或者Apache等伺服器上的調度功能。能夠提供一個七層應用開發介面的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。

（三）
負載均衡四七層介紹:
負載均衡（Load Balance）建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
本文所要介紹的負載均衡技術主要是指在均衡伺服器群中所有伺服器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程序的可用性和可伸縮性。
負載均衡技術分類
目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所採用的設備對象、應用的網路層次（指OSI參考模型）及應用的地理結構等來分類。
軟/硬體負載均衡
軟體負載均衡解決方案是指在一台或多台伺服器相應的操作系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟體解決方案缺點也較多，因為每台伺服器上安裝額外的軟體運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。
本地/全局負載均衡

負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的伺服器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網路負荷過重的問題，並且不需花費昂貴開支購置性能卓越的伺服器，充分利用現有設備，避免伺服器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級，也只是簡單地增加一個新的伺服器到服務群中，而不需改變現有網路結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己伺服器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的伺服器，從而獲得最快的訪問速度，也可用於子公司分散站點分布廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
網路層次上的負載均衡
針對網路上負載過重的不同瓶頸所在，從網路的不同層次入手，我們可以採用相應的負載均衡技術來解決現有問題。
隨著帶寬增加，數據流量不斷增大，網路核心部分的數據介面將面臨瓶頸問題，原有的單一線路將很難滿足需求，而且線路的升級又過於昂貴甚至難以實現，這時就可以考慮採用鏈路聚合（Trunking）技術。
鏈路聚合技術（第二層負載均衡）將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，網路數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能滿足帶寬增加的需求。
現代負載均衡技術通常操作於網路的第四層或第七層。第四層負載均衡將一個Internet上合法注冊的IP地址映射為多個內部伺服器的IP地址，對每次 TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目標地址是伺服器群VIP（虛擬 IP，Virtual IP address）連接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP埠號和一定的負載均衡策略，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接請求。
第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤信息，因而能透明地將連接請求重新定向到另一台伺服器，避免應用層故障。
可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的伺服器來處理，增加系統性能。
能根據連接請求的類型，如是普通文本、圖象等靜態文檔請求，還是asp、cgi等的動態文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。
第七層負載均衡受到其所支持的協議限制（一般只有HTTP），這樣就限制了它應用的廣泛性，並且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量連接請求的情況下，負載均衡設備自身容易成為網路整體性能的瓶頸。
負載均衡策略
在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部伺服器，而不管伺服器是否宕機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求，一台處理服務請求較少的伺服器能分配到更多的服務請求，出現故障的伺服器將不再接受服務請求直至故障恢復等等。
選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網路負載分布不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡演算法，二、對網路系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、伺服器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，為了更加合理的把負載分配給內部的多個伺服器，就需要應用相應的能夠正確反映各個伺服器處理能力及網路狀態的負載均衡演算法：
輪循均衡（Round Robin）：每一次來自網路的請求輪流分配給內部中的伺服器，從1至N然後重新開始。此種均衡演算法適合於伺服器組中的所有伺服器都有相同的軟硬體配置並且平均服務請求相對均衡的情況。
權重輪循均衡（Weighted Round Robin）：根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是 3，C的權值是6，則伺服器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡演算法能確保高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。
隨機均衡（Random）：把來自網路的請求隨機分配給內部中的多個伺服器。
權重隨機均衡（Weighted Random）：此種均衡演算法類似於權重輪循演算法，不過在處理請求分擔時是個隨機選擇的過程。
響應速度均衡（Response Time）：負載均衡設備對內部各伺服器發出一個探測請求（例如Ping），然後根據內部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應客戶端的服務請求。此種均衡演算法能較好的反映伺服器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與伺服器間的最快響應時間，而不是客戶端與伺服器間的最快響應時間。
最少連接數均衡（Least Connection）：客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異，隨著工作時間加長，如果採用簡單的輪循或隨機均衡演算法，每一台伺服器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡演算法對內部中需負載的每一台伺服器都有一個數據記錄，記錄當前該伺服器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的伺服器，使均衡更加符合實際情況，負載更加均衡。此種均衡演算法適合長時處理的請求服務，如FTP。
處理能力均衡：此種均衡演算法將把服務請求分配給內部中處理負荷（根據伺服器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的伺服器，由於考慮到了內部伺服器的處理能力及當前網路運行狀況，所以此種均衡演算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。
DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到伺服器確切的IP地址的。在此均衡演算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應伺服器的IP地址（即與此負載均衡設備在同一位地理位置的伺服器的IP地址）並返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
盡管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載，但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那台伺服器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力：
Ping偵測：通過ping的方式檢測伺服器及網路系統狀況，此種方式簡單快速，但只能大致檢測出網路及伺服器上的操作系統是否正常，對伺服器上的應用服務檢測就無能為力了。
TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測伺服器上某個TCP埠（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
HTTP URL偵測：比如向HTTP伺服器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為伺服器出現故障。
負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一台伺服器去負擔，例如伺服器將客戶端注冊、購物等服務請求信息保存的本地資料庫的情況下，把客戶端的子請求分配給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一台伺服器處理，客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器 cookie內做獨一無二的標識來把多次請求分配給同一台伺服器處理，適合通過代理伺服器上網的客戶端。
還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個伺服器，伺服器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網路負擔就減少了很多，並且給客戶端提供了更快的響應時間。此種模式一般用於HTTP伺服器群，在各伺服器上要安裝一塊虛擬網路適配器，並將其IP地址設為伺服器群的VIP，這樣才能在伺服器直接回應客戶端請求時順利的達成三次握手。
負載均衡實施要素
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨著訪問流量的爆炸性增長，超出決策者的意料，這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時，像其他的許多方案一樣，首先是確定當前及將來的應用需求，然後在代價與收效之間做出權衡。
針對當前及將來的應用需求，分析網路瓶頸的不同所在，我們就需要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要滿足多大的需求，如此等等。
不管負載均衡方案是採用花費較少的軟體方式，還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬體方式來實現，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鍾通過網路的數據包數目做為一個參數，另一個參數是均衡方案中伺服器群所能處理的最大並發連接數目，但是，假設一個均衡系統能處理百萬計的並發連接數，可是卻只能以每秒2個包的速率轉發，這顯然是沒有任何作用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，並且有兩點需要注意：一、均衡方案對伺服器群整體的性能，這是響應客戶端連接請求速度的關鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮採用混合型負載均衡策略來提升伺服器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也可以考慮採用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。
可擴展性：IT技術日新月異，一年以前最新的產品，現在或許已是網路中性能最低的產品；業務量的急速上升，一年前的網路，現在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求，能均衡不同操作系統和硬體平台之間的負載，能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載，並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。
可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決方案，提高可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控，保護系統盡可能地避免遭受到重大故障的損失。
易管理性：不管是通過軟體還是硬體方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和監控，提高工作效率，避免差錯。在硬體負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行介面（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串列介面來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶介面（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management Protocol，簡單網路管理協議）支持，通過第三方網路管理軟體對符合SNMP標準的設備進行管理。

2. 負載均衡權重輪詢演算法中的權重有什麼作用

不理解你說的權重是什麼，優先順序還是比率？
如果你有兩台伺服器，伺服器A和伺服器B
優先順序：伺服器A優先順序100，伺服器B優先順序50
流量全部分發到伺服器A上面，只有伺服器A掛掉才會分到B上面，類似於主備。
比率：伺服器A為3，服務B為1
如果一共有12個連接，伺服器A會分發到3+3+3 伺服器B會分發到1+1+1
也就是每4個連接中會有3個分發到伺服器A，剩下的1個分發到伺服器B。

3. 四層負載均衡和七層負載均衡的區別

簡單理解四層和七層負載均衡:
① 所謂四層就是基於IP+埠的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+埠接收請求，然後再分配到真實的伺服器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的伺服器。
② 所謂的四到七層負載均衡，就是在對後台的伺服器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發布三層的IP地址（VIP），然後加四層的埠號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後台伺服器，並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接的所有流量都同樣轉發到同一台伺服器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言伺服器組進行負載均衡處理。
③ 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
（二）
負載均衡設備也常被稱為」四到七層交換機」，那麼四層和七層兩者到底區別在哪裡？
第一，技術原理上的區別。
所謂四層負載均衡，也就是主要通過報文中的目標地址和埠，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連接建立，即三次握手是客戶端和伺服器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

所謂七層負載均衡，也稱為「內容交換」，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連接(三次握手)後，才可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。負載均衡設備在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
第二，應用場景的需求。
七層應用負載的好處，是使得整個網路更」智能化「。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。很多在後台，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，伺服器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，通常這種攻擊會大量發送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響後台伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。
現在的7層負載均衡，主要還是著重於應用HTTP協議，所以其應用范圍主要是眾多的網站或者內部信息平台等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
第三，七層應用需要考慮的問題。

1：是否真的必要，七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置復雜，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2：是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從伺服器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3：是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的調度。最簡單的一個考核就是能否取代後台Nginx或者Apache等伺服器上的調度功能。能夠提供一個七層應用開發介面的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。
（三）
負載均衡四七層介紹:
負載均衡（Load Balance）建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
本文所要介紹的負載均衡技術主要是指在均衡伺服器群中所有伺服器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程序的可用性和可伸縮性。
負載均衡技術分類
目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所採用的設備對象、應用的網路層次（指OSI參考模型）及應用的地理結構等來分類。
軟/硬體負載均衡
軟體負載均衡解決方案是指在一台或多台伺服器相應的操作系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟體解決方案缺點也較多，因為每台伺服器上安裝額外的軟體運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。
本地/全局負載均衡

負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的伺服器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網路負荷過重的問題，並且不需花費昂貴開支購置性能卓越的伺服器，充分利用現有設備，避免伺服器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級，也只是簡單地增加一個新的伺服器到服務群中，而不需改變現有網路結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己伺服器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的伺服器，從而獲得最快的訪問速度，也可用於子公司分散站點分布廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
網路層次上的負載均衡
針對網路上負載過重的不同瓶頸所在，從網路的不同層次入手，我們可以採用相應的負載均衡技術來解決現有問題。
隨著帶寬增加，數據流量不斷增大，網路核心部分的數據介面將面臨瓶頸問題，原有的單一線路將很難滿足需求，而且線路的升級又過於昂貴甚至難以實現，這時就可以考慮採用鏈路聚合（Trunking）技術。
鏈路聚合技術（第二層負載均衡）將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，網路數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能滿足帶寬增加的需求。
現代負載均衡技術通常操作於網路的第四層或第七層。第四層負載均衡將一個Internet上合法注冊的IP地址映射為多個內部伺服器的IP地址，對每次 TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目標地址是伺服器群VIP（虛擬 IP，Virtual IP address）連接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP埠號和一定的負載均衡策略，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接請求。
第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤信息，因而能透明地將連接請求重新定向到另一台伺服器，避免應用層故障。
可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的伺服器來處理，增加系統性能。
能根據連接請求的類型，如是普通文本、圖象等靜態文檔請求，還是asp、cgi等的動態文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。
第七層負載均衡受到其所支持的協議限制（一般只有HTTP），這樣就限制了它應用的廣泛性，並且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量連接請求的情況下，負載均衡設備自身容易成為網路整體性能的瓶頸。
負載均衡策略
在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部伺服器，而不管伺服器是否宕機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求，一台處理服務請求較少的伺服器能分配到更多的服務請求，出現故障的伺服器將不再接受服務請求直至故障恢復等等。
選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網路負載分布不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡演算法，二、對網路系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、伺服器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，為了更加合理的把負載分配給內部的多個伺服器，就需要應用相應的能夠正確反映各個伺服器處理能力及網路狀態的負載均衡演算法：
輪循均衡（Round Robin）：每一次來自網路的請求輪流分配給內部中的伺服器，從1至N然後重新開始。此種均衡演算法適合於伺服器組中的所有伺服器都有相同的軟硬體配置並且平均服務請求相對均衡的情況。
權重輪循均衡（Weighted Round Robin）：根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是 3，C的權值是6，則伺服器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡演算法能確保高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。
隨機均衡（Random）：把來自網路的請求隨機分配給內部中的多個伺服器。
權重隨機均衡（Weighted Random）：此種均衡演算法類似於權重輪循演算法，不過在處理請求分擔時是個隨機選擇的過程。
響應速度均衡（Response Time）：負載均衡設備對內部各伺服器發出一個探測請求（例如Ping），然後根據內部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應客戶端的服務請求。此種均衡演算法能較好的反映伺服器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與伺服器間的最快響應時間，而不是客戶端與伺服器間的最快響應時間。
最少連接數均衡（Least Connection）：客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異，隨著工作時間加長，如果採用簡單的輪循或隨機均衡演算法，每一台伺服器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡演算法對內部中需負載的每一台伺服器都有一個數據記錄，記錄當前該伺服器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的伺服器，使均衡更加符合實際情況，負載更加均衡。此種均衡演算法適合長時處理的請求服務，如FTP。
處理能力均衡：此種均衡演算法將把服務請求分配給內部中處理負荷（根據伺服器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的伺服器，由於考慮到了內部伺服器的處理能力及當前網路運行狀況，所以此種均衡演算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。
DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到伺服器確切的IP地址的。在此均衡演算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應伺服器的IP地址（即與此負載均衡設備在同一位地理位置的伺服器的IP地址）並返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
盡管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載，但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那台伺服器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力：
Ping偵測：通過ping的方式檢測伺服器及網路系統狀況，此種方式簡單快速，但只能大致檢測出網路及伺服器上的操作系統是否正常，對伺服器上的應用服務檢測就無能為力了。
TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測伺服器上某個TCP埠（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
HTTP URL偵測：比如向HTTP伺服器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為伺服器出現故障。
負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一台伺服器去負擔，例如伺服器將客戶端注冊、購物等服務請求信息保存的本地資料庫的情況下，把客戶端的子請求分配給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一台伺服器處理，客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器 cookie內做獨一無二的標識來把多次請求分配給同一台伺服器處理，適合通過代理伺服器上網的客戶端。
還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個伺服器，伺服器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網路負擔就減少了很多，並且給客戶端提供了更快的響應時間。此種模式一般用於HTTP伺服器群，在各伺服器上要安裝一塊虛擬網路適配器，並將其IP地址設為伺服器群的VIP，這樣才能在伺服器直接回應客戶端請求時順利的達成三次握手。
負載均衡實施要素
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨著訪問流量的爆炸性增長，超出決策者的意料，這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時，像其他的許多方案一樣，首先是確定當前及將來的應用需求，然後在代價與收效之間做出權衡。
針對當前及將來的應用需求，分析網路瓶頸的不同所在，我們就需要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要滿足多大的需求，如此等等。
不管負載均衡方案是採用花費較少的軟體方式，還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬體方式來實現，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鍾通過網路的數據包數目做為一個參數，另一個參數是均衡方案中伺服器群所能處理的最大並發連接數目，但是，假設一個均衡系統能處理百萬計的並發連接數，可是卻只能以每秒2個包的速率轉發，這顯然是沒有任何作用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，並且有兩點需要注意：一、均衡方案對伺服器群整體的性能，這是響應客戶端連接請求速度的關鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮採用混合型負載均衡策略來提升伺服器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也可以考慮採用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。
可擴展性：IT技術日新月異，一年以前最新的產品，現在或許已是網路中性能最低的產品；業務量的急速上升，一年前的網路，現在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求，能均衡不同操作系統和硬體平台之間的負載，能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載，並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。
可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決方案，提高可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控，保護系統盡可能地避免遭受到重大故障的損失。
易管理性：不管是通過軟體還是硬體方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和監控，提高工作效率，避免差錯。在硬體負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行介面（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串列介面來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶介面（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management Protocol，簡單網路管理協議）支持，通過第三方網路管理軟體對符合SNMP標準的設備進行管理。

4. ribbon負載均衡詳解

服務端負載均衡：在客戶端和服務端中間使用代理，lvs  和 nginx。

硬體負載均衡的設備或是軟體負載均衡的軟體模塊都會維護一個下掛可用的服務端清單，通過心跳檢測來剔除故障的服務端節點以保證清單中都是可以正常訪問的服務端節點。當客戶端發送請求到負載均衡設備的時候，該設備按某種演算法（比如線性輪詢、按權重負載、按流量負載等）從維護的可用服務端清單中取出一台服務端端地址，然後進行轉發。

客戶端負載均衡：根據自己的情況做負載。Ribbon。

客戶端負載均衡和服務端負載均衡最大的區別在於 服務端地址列表的存儲位置，以及負載演算法在哪裡。

2、Spring Cloud的負載均衡機制的實現

Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具，它基於Netflix Ribbon實現。通過Spring Cloud的封裝，可以讓我們輕松地將面向服務的REST模版請求自動轉換成客戶端負載均衡的服務調用。Ribbon實現客戶端的負載均衡，負載均衡器提供很多對http和tcp的行為控制。Spring cloud Feign已經集成Ribbon，所以註解@FeignClient的類，默認實現了ribbon的功能。

Ribbon主要包括如下功能

1.支持通過DNS和IP和服務端通信

2.可以根據演算法從多個服務中選取一個服務進行訪問

3.通過將客戶端和伺服器分成幾個區域（zone）來建立客戶端和伺服器之間的關系。客戶端盡量訪問和自己在相同區域(zone)的服務，減少服務的延遲

4.保留伺服器的統計信息，ribbon可以實現用於避免高延遲或頻繁訪問故障的伺服器

5.保留區域(zone)的統計數據，ribbon可以實現避免可能訪問失效的區域(zone)

Ribbon負載均衡主要是通過LoadBalancerClient類實現的，而LoadBalancerClient又將具體處理委託給ILoadBalancer處理；

每個服務都有一個ILoadBalancer，ILoadBalancer裡面有該服務列表。

每個服務 Map<服務名，ILoadBalancer>

ILoadBalancer通過配置IRule、IPing等信息，並通過ServerList獲取伺服器注冊列表的信息，默認以每10s的頻率想服務列表中每個服務實例發送ping請求，檢測服務實例是否存活，最後使用負責均衡策略對ServerListFilter過濾得到最終可用的服務實例列表進行處理，然後交給服務調用器進行調用；

ILoadBalance也是一個介面，提供了3個具體實現，分別是DynamicServerListLoadBalancer、ZoneAwareLoadBalancer和NoOpLoadBalancer；

DynamicServerListLoadBalancer繼承自ILoadBalancer基礎實現BaseLoadBalancer，在基礎的負載均衡功能上增加了運行期間對服務實例動態更新和過濾的功能；

NoOpLoadBalancer沒有操作的實現；

ZoneAwareLoadBalancer（ILoadBalancer的默認的實現類是：ZoneAwareLoadBalancer。）則是繼承DynamicServerListLoadBalancer，在此基礎上增加防止跨區域訪問的問題；

首先它會剔除符合這些規則的Zone區域：所屬實例數位零的Zone區域；Zone區域內實例等平均負載小於零，或者實例故障率（斷路器斷開次數／實例數）大於等於閥值（默認為0.99999）。

然後根據Zone區域等實例平均負載計算出最差的Zone區域，這里的最差指的是實例平均負載最高的Zone區域。

如果在上面的過程中沒有符合剔除要求的區域，同時實例最大平均負載小於閥值（默認為20%），就直接返回所有Zone區域為可用區域。否則，從最壞Zone區域集合中隨機選擇一個，將它從可用Zone區域集合中剔除。

 ▪️當獲得的可用Zone區域集合不為空，並且個數小於Zone區域總數，就隨機選擇一個Zone區域。

▪️在確定了某個Zone區域後，則獲取了對應Zone區域的服務均衡器，並調用chooseServer來選擇具體的服務實例，而在chooseServer中將使用IRule介面的choose函數來選擇具體的服務實例。在這里，IRule介面的實現會使用ZoneAvoidanceRule來挑選出具體的服務實例。

服務列表就是客戶端負載均衡所使用的(同一注冊中心集群)各服務的服務實例列表。Ribbon在實現上支持以下幾種服務列表方式

靜態伺服器列表：通過Ribbon的BaseLoadBalancer所提供的setServerList()方法，初始化時直接進行動態設置指定；

基於配置的伺服器列表：需要在項目配置文件中通過<服務名稱>.ribbon.listOfServers進行設置。（如user-service.ribbon.listOfServers=http://127.0.0.1:8082,http://127.0.0.1:8083）

基於服務發現的伺服器列表：同時使用Ribbon和Eureka時，默認使用該方式，在應用啟動時Ribbon就會從Eureka伺服器中獲取所有注冊服務的列表數據，並保持同步。

該組件會對原始服務列表使用一定策略進行過濾返回有效可用的伺服器列表給客戶端負載均衡器使用。常用服務列表過濾器如下：ZoneAffinityServerListFilter：基於區域感知的方式，實現對服務實例的過濾，僅返回與本身所處區域一直的服務提供者實例列表；ServerListSubsetFilter：該過濾器繼承自ZoneAffinityServerListFilter，在進行區域感知過濾後，僅返回一個固定大小的服務列表。默認將返回20個服務實例，可以通過ribbon.ServerListSubsetFilter.size進行設置；

：使用Eureka和Ribbon時默認的過濾器。實現通過配置或者Eureka所屬區域來過濾出同區域的服務實例列表。

它實現了通過配置或者Eureka實例元數據的所屬區域（Zone）來過濾出同區域的服務實例。如下面的源碼所示，它的實現非常簡單，首先通過父類ZoneAffinityServerListFilter的過濾器來獲得「區域感知」的服務實例列表，然後遍歷這個結果，取出根據消費者配置預設的區域Zone來進行過濾，如果過濾掉結果是空就直接返回父類獲取的結果，如果不為空就返回通過消費者配置的Zone過濾後的結果。

用來檢測一個微服務實例是否存活是否有響應，Ribbon通過該組件來判斷所持有的服務實例列表中各服務可用情況，如果檢測到某服務實例不存在/一定時間未響應，則會從持有服務列表中及時移除。

PingUrl：通過定期訪問指定的URL判斷；

PingConstant：不做任何處理，只返回一個固定值，用來表示該服務是否可用，默認值為true；

NoOpPing：不做任何處理，直接返回true，表示該伺服器可用，默認策略；

DummyPing：直接返回true，但實現了initWithNiwsConfig方法；

NIWSDiscoverPing：根據DiscoveryEnabledServer中InstanceInfo的InstanceStatus屬性判斷，如果該屬性的值為InstanceStatus.UP，則表示伺服器可用；

作用就是選擇一個最終服務實例地址作為負載均衡處理結果。Ribbon提供的選擇策略有隨機 (Random)、輪詢 (RoundRobin)、一致性哈希 (ConsistentHash)、哈希 (Hash)、加權（Weighted）。

IRule負載均衡策略：通過實現該介面定義自己的負載均衡策略。它的choose方法就是從一堆伺服器列表中按規則選出一個伺服器。

默認實現：

ZoneAvoidanceRule（區域權衡策略）：復合判斷Server所在區域的性能和Server的可用性，輪詢選擇伺服器。

其他規則：

BestAvailableRule（最低並發策略）：會先過濾掉由於多次訪問故障而處於斷路器跳閘狀態的服務，然後選擇一個並發量最小的服務。逐個找服務，如果斷路器打開，則忽略。

RoundRobinRule（輪詢策略）：以簡單輪詢選擇一個伺服器。按順序循環選擇一個server。

RandomRule（隨機策略）：隨機選擇一個伺服器。

AvailabilityFilteringRule（可用過濾策略）：會先過濾掉多次訪問故障而處於斷路器跳閘狀態的服務和過濾並發的連接數量超過閥值得服務，然後對剩餘的服務列表安裝輪詢策略進行訪問。

WeightedResponseTimeRule（響應時間加權策略）：據平均響應時間計算所有的服務的權重，響應時間越快服務權重越大，容易被選中的概率就越高。剛啟動時，如果統計信息不中，則使用RoundRobinRule(輪詢)策略，等統計的信息足夠了會自動的切換到WeightedResponseTimeRule。響應時間長，權重低，被選擇的概率低。反之，同樣道理。此策略綜合了各種因素（網路，磁碟，IO等），這些因素直接影響響應時間。

RetryRule（重試策略）：先按照RoundRobinRule(輪詢)的策略獲取服務，如果獲取的服務失敗則在指定的時間會進行重試，進行獲取可用的服務。如多次獲取某個服務失敗，就不會再次獲取該服務。主要是在一個時間段內，如果選擇一個服務不成功，就繼續找可用的服務，直到超時。

1. <clientName>：這是調用ribbon的客戶端名稱，如果此值為沒有配置，則此條屬性會作用到所有的客戶端。

2. <nameSpace>：默認值為 「ribbon」

3. <propertyName>：所有的可用的屬性都在com.netflix.client.conf.CommonClientConfigKey。

<clientName>.<nameSpace>.NFLoadBalancerClassName=xx

<clientName>.<nameSpace>.NFLoadBalancerRuleClassName=xx

<clientName>.<nameSpace>.NFLoadBalancerPingClassName=xx

<clientName>.<nameSpace>.NIWSServerListClassName=xx

<clientName>.<nameSpace>.NIWSServerListFilterClassName=xx

com.netflix.client.config.IClientConfig：Ribbon的客戶端配置，默認採用com.netflix.client.config.DefaultClientConfigImpl實現。

com.netflix.loadbalancer.IRule：Ribbon的負載均衡策略，默認採用com.netflix.loadbalancer.ZoneAvoidanceRule實現，該策略能夠在多區域環境下選出最佳區域的實例進行訪問。

com.netflix.loadbalancer.IPing：Ribbon的實例檢查策略，默認採用com.netflix.loadbalancer.NoOpPing實現，該檢查策略是一個特殊的實現，實際上它並不會檢查實例是否可用，而是始終返回true，默認認為所有服務實例都是可用的。

com.netflix.loadbalancer.ServerList：服務實例清單的維護機制，默認採用com.netflix.loadbalancer.ConfigurationBasedServerList實現。

com.netflix.loadbalancer.ServerListFilter：服務實例清單過濾機制，默認采org.springframework.cloud.netflix.ribbon.，該策略能夠優先過濾出與請求方處於同區域的服務實例。

com.netflix.loadbalancer.ILoadBalancer：負載均衡器，默認採用com.netflix.loadbalancer.ZoneAwareLoadBalancer實現，它具備了區域感知的能力。

上面的配置是在項目中沒有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依賴時，自動化配置會有一些不同。

通過自動化配置的實現，可以輕松的實現客戶端的負載均衡。同時，針對一些個性化需求，我們可以方便的替換上面的這些默認實現，只需要在springboot應用中創建對應的實現實例就能覆蓋這些默認的配置實現。

@Configuration

public class MyRibbonConfiguration {

    @Bean

    public IRule ribbonRule(){

        return new RandomRule();

    }

}

這樣就會使用P使用了RandomRule實例替代了默認的com.netflix.loadbalancer.ZoneAvoidanceRule。

也可以使用@RibbonClient註解實現更細粒度的客戶端配置

對於Ribbon的參數通常有二種方式：全局配置以及指定客戶端配置

全局配置的方式很簡單

只需要使用ribbon.<key>=<value>格式進行配置即可。其中，<key>代表了Ribbon客戶端配置的參數名，<value>則代表了對應參數的值。比如，我們可以想下面這樣配置Ribbon的超時時間

ribbon.ConnectTimeout=250

ribbon.ServerListRefreshInterval=2000   ribbon獲取服務定時時間

全局配置可以作為默認值進行設置，當指定客戶端配置了相應的key的值時，將覆蓋全局配置的內容

指定客戶端的配置方式

<client>.ribbon.<key>=<value>的格式進行配置.<client>表示服務名，比如沒有服務治理框架的時候（如Eureka），我們需要指定實例清單，可以指定服務名來做詳細的配置，

user-service.ribbon.listOfServers=localhost:8080,localhost:8081,localhost:8082

對於Ribbon參數的key以及value類型的定義，可以通過查看com.netflix.client.config.CommonClientConfigKey類。

當在spring Cloud的應用同時引入Spring cloud Ribbon和Spring Cloud Eureka依賴時，會觸發Eureka中實現的對Ribbon的自動化配置。這時的serverList的維護機制實現將被com.netflix.niws.loadbalancer.的實例所覆蓋，該實現會講服務清單列表交給Eureka的服務治理機制來進行維護。IPing的實現將被com.netflix.niws.loadbalancer.NIWSDiscoveryPing的實例所覆蓋，該實例也將實例介面的任務交給了服務治理框架來進行維護。默認情況下，用於獲取實例請求的ServerList介面實現將採用Spring Cloud Eureka中封裝的org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerList，其目的是為了讓實例維護策略更加通用，所以將使用物理元數據來進行負載均衡，而不是使用原生的AWS AMI元數據。在與Spring cloud Eureka結合使用的時候，不需要再去指定類似的user-service.ribbon.listOfServers的參數來指定具體的服務實例清單，因為Eureka將會為我們維護所有服務的實例清單，而對於Ribbon的參數配置，我們依然可以採用之前的兩種配置方式來實現。

此外，由於spring Cloud Ribbon默認實現了區域親和策略，所以，可以通過Eureka實例的元數據配置來實現區域化的實例配置方案。比如可以將不同機房的實例配置成不同的區域值，作為跨區域的容器機制實現。而實現也非常簡單，只需要服務實例的元數據中增加zone參數來指定自己所在的區域，比如：

eureka.instance.metadataMap.zone=shanghai

在Spring Cloud Ribbon與Spring Cloud Eureka結合的工程中，我們可以通過參數禁用Eureka對Ribbon服務實例的維護實現。這時又需要自己去維護服務實例列表了。

ribbon.eureka.enabled=false.

由於Spring Cloud Eureka實現的服務治理機制強調了cap原理的ap機制（即可用性和可靠性），與zookeeper這類強調cp（一致性，可靠性）服務質量框架最大的區別就是，Eureka為了實現更高的服務可用性，犧牲了一定的一致性，在極端情況下寧願接受故障實例也不要丟棄"健康"實例。

比如說，當服務注冊中心的網路發生故障斷開時候，由於所有的服務實例無法維護續約心跳，在強調ap的服務治理中將會把所有服務實例剔除掉，而Eureka則會因為超過85%的實例丟失心跳而觸發保護機制，注冊中心將會保留此時的所有節點，以實現服務間依然可以進行互相調用的場景，即使其中有部分故障節點，但這樣做可以繼續保障大多數服務的正常消費。

在Camden版本，整合了spring retry來增強RestTemplate的重試能力，對於我們開發者來說，只需要簡單配置，即可完成重試策略。

spring.cloud.loadbalancer.retry.enabled=true

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

user-service.ribbon.ConnectTimeout=250

user-service.ribbon.ReadTimeout=1000

user-service.ribbon.OkToRetryOnAllOperations=true

user-service.ribbon.MaxAutoRetriesNextServer=2

user-service.ribbon.maxAutoRetries=1

spring.cloud.loadbalancer.retry.enabled:該參數用來開啟重試機制，它默認是關閉的。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：斷路器的超時時間需要大於Ribbon的超時時間，不然不會觸發重試。

user-service.ribbon.ConnectTimeout：請求連接超時時間。

user-service.ribbon.ReadTimeout：請求處理的超時時間

user-service.ribbon.OkToRetryOnAllOperations：對所有操作請求都進行重試。

user-service.ribbon.MaxAutoRetriesNextServer：切換實例的重試次數。

user-service.ribbon.maxAutoRetries：對當前實例的重試次數。

根據以上配置，當訪問到故障請求的時候，它會再嘗試訪問一次當前實例（次數由maxAutoRetries配置），如果不行，就換一個實例進行訪問，如果還是不行，再換一個實例訪問（更換次數由MaxAutoRetriesNextServer配置），如果依然不行，返回失敗

項目啟動的時候會自動的為我們載入LoadBalancerAutoConfiguration自動配置類，該自動配置類初始化條件是要求classpath必須要有RestTemplate這個類，必須要有LoadBalancerClient實現類。

LoadBalancerAutoConfiguration為我們幹了二件事，第一件是創建了LoadBalancerInterceptor攔截器bean，用於實現對客戶端發起請求時進行攔截，以實現客戶端負載均衡。創建了一個

RestTemplateCustomizer的bean，用於給RestTemplate增加LoadBalancerInterceptor攔截器。

每次請求的時候都會執行org.springframework.cloud.client.loadbalancer.LoadBalancerInterceptor的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客戶端負載客戶端）實例的一個引用，

在攔截器中通過方法獲取服務名的請求url（比如http://user-service/user），及服務名（比如user-service），然後調用負載均衡客戶端的execute方法。

執行負載客戶端RibbonLoadBalancerClient（LoadBalancerClient的實現）的execute方法，得到ILoadBalancer（負載均衡器）的實現ZoneAwareLoadBalancer，並且通過調用其chooseServer方法獲得服務列表中的一個實例，比如說user-service列表注冊到eureka中一個實例。然後向其中的一個具體實例發起請求，得到結果。

Ribbon詳解 

https://www.jianshu.com/p/1bd66db5dc46

Spring cloud系列六 Ribbon的功能概述、主要組件和屬性文件配置  

https://blog.csdn.net/hry2015/article/details/78357990

Ribbon的ZoneAwareLoadBalancer  

https://blog.csdn.net/chengqiuming/article/details/81209131

Ribbon的實際使用

https://www.jianshu.com/p/f86af82fa782

本人有道雲筆記中記錄的參考文章

文檔：04_ribbon 負載均衡.note

鏈接：http://note.you.com/noteshare?id=&sub=

5. nginx 負載均衡之一致性hash，普通hash

哈希負載均衡原理
  ngx_http_upstream_hash_mole支持普通的hash及一致性hash兩種負載均衡演算法，默認的是普通的hash來進行負載均衡。
  nginx 普通的hash演算法支持配置http變數值作為hash值計算的key，通過hash計算得出的hash值和總權重的余數作為挑選server的依據；nginx的一致性hash(chash)演算法則要復雜一些。這里會對一致性hash的機制原理作詳細的說明。
一致性hash演算法的原理
一致性hash用於對hash演算法的改進，後端伺服器在配置的server的數量發生變化後，同一個upstream server接收到的請求會的數量和server數量變化之間會有變化。尤其是在負載均衡配置的upstream server數量發生增長後，造成產生的請求可能會在後端的upstream server中並不均勻，有的upstream server負載很低，有的upstream server負載較高，這樣的負載均衡的效果比較差，可能對upstream server造成不良的影響。由此，產生了一致性hash演算法來均衡。
   那麼為什麼一致性hash演算法能改善這種情況呢？這里引用網上資料的一致性hash演算法的圖例。
因為對於hash(k)的范圍在int范圍，所以我們將0~2^32作為一個環。其步驟為：
1，求出每個伺服器的hash（伺服器ip）值，將其配置到一個 0~2^n 的圓環上（n通常取32）。
2，用同樣的方法求出待存儲對象的主鍵 hash值，也將其配置到這個圓環上，然後從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
其分布如圖：

除了上邊的優點，其實還有一個優點：對於熱點數據，如果發現node1訪問量明顯很大，負載高於其他節點，這就說明node1存儲的數據是熱點數據。這時候，為了減少node1的負載，我們可以在熱點數據位置再加入一個node，用來分擔熱點數據的壓力。
雪崩效應

接下來我們來看一下，當有節點宕機時會有什麼問題。如下圖：

如上圖，當B節點宕機後，原本存儲在B節點的k1，k2將會遷移到節點C上，這可能會導致很大的問題。如果B上存儲的是熱點數據，將數據遷移到C節點上，然後C需要承受B+C的數據，也承受不住，也掛了。。。。然後繼續CD都掛了。這就造成了雪崩效應。
上面會造成雪崩效應的原因分析：
如果不存在熱點數據的時候，每台機器的承受的壓力是M/2(假設每台機器的最高負載能力為M)，原本是不會有問題的，但是，這個時候A伺服器由於有熱點數據掛了，然後A的數據遷移至B，導致B所需要承受的壓力變為M（還不考慮熱點數據訪問的壓力），所以這個失敗B是必掛的，然後C至少需要承受1.5M的壓力。。。。然後大家一起掛。。。
所以我們通過上面可以看到，之所以會大家一起掛，原因在於如果一台機器掛了，那麼它的壓力全部被分配到一台機器上，導致雪崩。

怎麼解決雪崩問題呢，這時候需要引入虛擬節點來進行解決。
虛擬節點

虛擬節點，我們可以針對每個實際的節點，虛擬出多個虛擬節點，用來映射到圈上的位置，進行存儲對應的數據。如下圖：

如上圖：A節點對應A1，A2，BCD節點同理。這時候，如果A節點掛了，A節點的數據遷移情況是:A1數據會遷移到C2，A2數據遷移到D1。這就相當於A的數據被C和D分擔了，這就避免了雪崩效應的發送，而且虛擬節點我們可以自定義設置，使其適用於我們的應用。

ngx_http_upstream_consistent_hash
該模塊可以根據配置參數採取不同的方式將請求均勻映射到後端機器，比如：

指令
語法：consistent_hash variable_name
默認值：none
上下文：upstream

配置upstream採用一致性hash作為負載均衡演算法，並使用配置的變數名作為hash輸入。

參考文檔：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/

6. 伺服器集群的負載均衡演算法有哪些

輪轉(Round-Robin)演算法
加權輪轉(Weighted Round Robin)演算法
最小連接數（Least Connections）演算法
加權最小連接數（Weighted Least Connections）演算法
目的地址哈希散列（Destination Hashing Scheling）演算法
源地址哈希散列（Source Hashing Scheling）演算法
隨機（Random）演算法

7. 常見的負載均衡技術

四層負責均衡：主要是指通過判斷報文的IP地址和埠並通過一定的負載均衡演算法來決定轉發到哪個指定目標，主要工作在OSI模型的第四層。四層負載均衡對數據包只是起一個數據轉發的作用，並不會干預客戶端與伺服器之間應用層的通信（如：三次握手等）。所以能對數據所進行的操作也就很少，但相對於七層負載均衡來講效率會高上很多

七層負載均衡：也被稱為「內容交換」，指的是負載均衡設備通過報文中的應用層信息(URL、HTTP頭部等信息)和負載均衡演算法，選擇到達目的的內部伺服器。七層負載均衡可以「智能化」地篩選報文中 應用層信息，然後根據不同的信息進行特定的負載均衡調度。這種方式提升了應用系統在網路層上的靈活性，另外也在一定程度上提升了後端系統的安全性。因為像網路常見的DoS攻擊，這些攻擊在七層負載均衡的環境下通常都在負載均衡設備上就截止了，不會影響到後台伺服器的正常運行。

前網路中常見的負載均衡主要分為硬體負載均衡和軟體負載均衡。硬體負載均衡比較知名的產品有F5 Big-IP、Cirtix Netscaler等等。而軟體負載均衡就有著眾多的開源項目，常見的有Haproxy、nginx、lvs等。
Haproxy：

lvs:

nginx:

Haproxy可以做代理服務相對於nginx而言有很多相同之處，統一可以基於mode tcp進行四層代理也可以基於mode http進行七層代理，但不同的是其無法使用location和if等進行匹配判斷。突出優勢在於有會話綁定，web管理界面，狀態統計非常詳細。官方推薦只啟用一個進程，相對於nginx多進程架構工作並不理想，更多的線程可能會受到系統內存的一些限制。
程序環境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service

查看配置文件

重要的幾個參數，及性能調優，多數無需修改

發現日誌發送給本機rsyslog的local2的facility，而本機的rsyslog里並沒有定義，需要我們自己去配置
所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對應日誌文件中

由於HAProxy可以工作在七層模型下，因此，要實現HAProxy的強大功能，一定要使用強大靈活的ACL規則，通過ACL規則可以實現基於HAProxy的智能負載均衡系統。HAProxy通過ACL規則完成兩種主要的功能，分別是：
1）通過設置的ACL規則檢查客戶端請求是否合法。如果符合ACL規則要求，那麼將放行；如果不符合規則，則直接中斷請求。
2）符合ACL規則要求的請求將被提交到後端的backend伺服器集群，進而實現基於ACL規則的負載均衡。HAProxy中的ACL規則經常使用在frontend段中，使用方法如下：
acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：
·acl：是一個關鍵字，表示定義ACL規則的開始。後面需要跟上自定義的ACL名稱。
·acl方法：這個欄位用來定義實現ACL的方法，HAProxy定義了很多ACL方法，經常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不區分大小寫，後面需要跟上匹配的路徑或文件或正則表達式。與ACL規則一起使用的HAProxy參數還有use_backend，use_backend後面需要跟上一個backend實例名，表示在滿足ACL規則後去請求哪個backend實例，與use_backend對應的還有default_backend參數，它表示在沒有滿足ACL條件的時候默認使用哪個後端

這些例子定義了www_policy、bbs_policy、url_policy三個ACL規則，第一條規則表示如果客戶端以 www.z.cn 或 z.cn 開頭的域名發送請求時，則此規則返回true，同理第二條規則表示如果客戶端通過 bbs.z.cn 域名發送請求時，則此規則返回true，而第三條規則表示如果客戶端在請求的URL中包含「buy_sid=」字元串時，則此規則返回true。
第四、第五、第六條規則定義了當www_policy、bbs_policy、url_policy三個ACL規則返回true時要調度到哪個後端backend，例如，當用戶的請求滿足www_policy規則時，那麼HAProxy會將用戶的請求直接發往名為server_www的後端backend，其他以此類推。而當用戶的請求不滿足任何一個ACL規則時，HAProxy就會把請求發往由default_backend選項指定的server_cache這個後端backend。

與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規則，其中，第一條規則通過path_end參數定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結尾時返回true，第二條規則通過hdr_beg（host）參數定義了如果客戶端以www開頭的域名發送請求時則返回true，同理，第三條規則也是通過hdr_beg（host）參數定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發送請求時則返回true。
第四、第五條規則定義了當滿足ACL規則後要調度到哪個後端backend，例如，當用戶的請求同時滿足host_static規則與url_static規則，或同時滿足host_www和url_static規則時，那麼會將用戶請求直接發往名為static的後端backend，如果用戶請求滿足host_www規則，那麼請求將被調度到名為www的後端backend，如果不滿足所有規則，那麼將用戶請求默認調度到名為server_cache的這個後端backend。

log：全局的日誌配置，local0是日誌設備，info表示日誌級別。其中日誌級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務中的local0日誌設備，記錄日誌等級為info。

maxconn：設定每個HAProxy進程可接受的最大並發連接數，此選項等同於Linux命令行選項「ulimit -n」。

user/group：設置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。

daemon：設置HAProxy進程進入後台運行。這是推薦的運行模式。

nbproc：設置HAProxy啟動時可創建的進程數，此參數要求將HAProxy運行模式設置為daemon，默認只啟動一個進程。該值的設置應該小於伺服器的CPU核數。創建多個進程，能夠減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。

pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的許可權。

mode：設置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。

retries：設置連接後端伺服器的失敗重試次數，如果連接失敗的次數超過這里設置的值，HAProxy會將對應的後端伺服器標記為不可用。此參數也可在後面部分進行設置。

timeout connect：設置成功連接到一台伺服器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位後綴。

timeout client：設置連接客戶端發送數據時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

timeout server：設置伺服器端回應客戶端數據發送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

timeout check：設置對後端伺服器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位後綴。

bind：此選項只能在frontend和listen部分進行定義，用於定義一個或幾個監聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設置為「*」或「0.0.0.0」，將監聽當前系統的所有IPv4地址。port_range可以是一個特定的TCP埠，也可是一個埠范圍，小於1024的埠需要有特定許可權的用戶才能使用。interface為可選選項，用來指定網路介面的名稱，只能在Linux系統上使用。

option httplog：在默認情況下，HAProxy日誌是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監控。通過此選項可以啟用日誌記錄HTTP請求。

option forwardfor：如果後端伺服器需要獲得客戶端的真實IP，就需要配置此參數。由於HAProxy工作於反向代理模式，因此發往後端真實伺服器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導致真實伺服器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用於解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發往後端真實伺服器的請求添加X-Forwarded-For記錄，這樣後端真實伺服器日誌可以通過「X-Forwarded-For」信息來記錄客戶端來源IP。

option httpclose：此選項表示在客戶端和伺服器端完成一次連接請求後，HAProxy將主動關閉此TCP連接。這是對性能非常有幫助的一個參數。

log global：表示使用全局的日誌配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。

default_backend：指定默認的後端伺服器池，也就是指定一組後端真實伺服器，而這些真實伺服器組將在backend段進行定義。這里的htmpool就是一個後端伺服器組。

option redispatch：此參數用於cookie保持的環境中。在默認情況下，HAProxy會將其請求的後端伺服器的serverID插入cookie中，以保證會話的session持久性。而如果後端的伺服器出現故障，客戶端的cookie是不會刷新的，這就會出現問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一台健康的後端伺服器上，以保證服務正常。

option abortonclose：如果設置了此參數，可以在伺服器負載很高的情況下，自動結束當前隊列中處理時間比較長的連接。
-balance：此關鍵字用來定義負載均衡演算法。目前HAProxy支持多種負載均衡演算法，常用的有如下幾種：

cookie：表示允許向cookie插入SERVERID，每台伺服器的SERVERID可在下面的server關鍵字中使用cookie關鍵字定義。

option httpchk：此選項表示啟用HTTP的服務狀態檢測功能。HAProxy作為一個專業的負載均衡器，它支持對backend部分指定的後端服務節點的健康檢查，以保證在後端backend中某個節點不能服務時，把從frotend端進來的客戶端請求分配至backend中其他健康節點上，從而保證整體服務的可用性。
option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數的含義如下：

check：表示啟用對此後端伺服器執行健康狀態檢查。

inter：設置健康狀態檢查的時間間隔，單位為毫秒。

rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如，「rise 2」表示2次檢查正確就認為此伺服器可用。

fall：設置後端伺服器從正常狀態轉換為不可用狀態需要檢查的次數，例如，「fall 3」表示3次檢查失敗就認為此伺服器不可用。

cookie：為指定的後端伺服器設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的後端伺服器將在後續的請求中一直被選中，其目的在於實現持久連接的功能。上面的「cookie server1」表示web1的serverid為server1。同理，「cookie server2」表示web2的serverid為server2。

weight：設置後端真實伺服器的權重，默認為1，最大值為256。設置為0表示不參與負載均衡。

backup：設置後端真實伺服器的備份伺服器，僅僅在後端所有真實伺服器均不可用的情況下才啟用。

用nginx反代後端的兩台tomcat主機，做動靜分離，如果是jsp結尾的就發往後端，否則就交給nginx處理。
在兩台tomcat主機上創建應用

nginx配置

則動靜分離就實現了，並且我們還基於uri實現了會話粘性

8. 負載均衡中的權重有什麼作用

權重是會根據負載大小變化的，如果負載一直增加，那麼權重就會一直減少到不是最大，也就不會再分配任務給它了，反而分配給新的權重最大的伺服器。

9. 負載均衡是怎麼做的~

1、服務直接返回：這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。

2、橋接模式：橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。

3、路由模式：路由模式的部署方式，伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。

(9)負載均衡權重演算法擴展閱讀

負載均衡的演算法:

1、隨機演算法：Random隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

2、哈希演算法：一致性哈希一致性Hash，相同參數的請求總是發到同一提供者。當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

3、URL散列：通過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一伺服器的演算法。

參考資料

網路-負載均衡

10. 負載均衡進階：SLB常見問題解決方法

摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。

摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。想知道如何藉助SLB構建高可用系統以及健康檢查是如何實現的，本文不容錯過！

本文內容根據演講嘉賓分享視頻以及PPT整理而成。

本次的分享將會主要圍繞以下5個部分

基本概念回顧

如何構建高可用系統

選擇性能共享型還是性能保障型實例

為什麼健康檢查異常

為什麼負載不均衡

一、基本概念回顧

SLB是什麼

SLB是阿里雲推出的一款雲負載均衡服務，其主要針對於多台雲伺服器進行流量分發，能夠將業務流量分發到由多台雲伺服器所組成的後端伺服器池上去，以此來提升系統的處理能力。負載均衡所解決的問題主要包括兩點：第一點，SLB能夠消除系統的單點故障，這是因為SLB的後面是由多台雲伺服器組成的伺服器池，那麼當其中某一台伺服器出現故障的時候並不會影響整個系統的可服務性。第二點，由於後端的雲伺服器能夠橫向地進行擴展，所以也具有為海量業務提供服務的能力。那麼，為什麼要使用雲上的負載均衡呢？這是因為雲上負載均衡主要有這樣的幾個特點：高可靠、高性能、低成本、安全性、易用性。

SLB基本組件

阿里雲的SLB主要包括了三個基本組件，這里也進行簡單地介紹。第一個基本組件就是實例，每個實例都唯一地標識了雲負載均衡器，並且每個實例都對應一個VIP，VIP唯一地標識了負載均衡實例，也是負載均衡對外提供服務的地址。第二個組件是監聽，監聽是由VIP+埠號來唯一標識的，一個監聽中包含用戶定製的負載均衡策略和轉發規則。最後一個基本組件就是後端掛載的伺服器，也就是雲伺服器ECS，負責處理真正的業務請求。

二、如何構建高可用系統

多層次的高可用

如下圖所示，阿里雲的負載均衡是從四個層面上去構建高可用的。從底層往上層看，分別是應用級別的高可用、集群級別的高可用、可用區級別(AZ)的高可用以及地域級別(Region)的高可用。

應用級別的高可用主要是通過針對SLB後端的ECS實例的健康檢查來實現的。當SLB發現後端不健康的或者不能正常工作的ECS的時候，會將這些不健康的ECS從SLB的轉發路徑中剔除掉，保證業務流量能夠轉發到正常的工作伺服器當中。集群級別的高可用主要是通過集群中LVS機器間的session同步來保障任何一個用戶的業務會話都能夠在所有的LVS機器上是相互同步的，當其中某一台LVS出現故障時，可以由其他的LVS來接替出現故障的機器的工作。同時，由於會話保持的存在，用戶的業務是不會發生中斷的。對於可用區級別的高可用和地域級別的高可用，在本文的後面會進行更加詳細的介紹。

細說可用區級別容災

這里詳細地介紹一下可用區級別的容災。可用區級別容災的設計初衷是在當一個可用區出現重大災情的時候，比如整個可用區的機房發生了掉電、光纜出現了中斷、整個可用區機房中所有的物理機都無法正常工作的時候，也就是整個可用區都宕掉了的情況下，能夠由備可用區來繼續提供服務，這就是可用區級別容災的設計初衷。可用區級別的容災並不是說某一個可用區中的某一個實例或者是某幾個實例出現了故障就會發生可用區的切換，實例自動從可用區A切換到可用區B，這是一個比較常見的誤區。而針對於這樣的誤區，阿里雲也建議用戶在構建可用區級別的高可用的時候採取以下兩個步驟：

首先，建議用戶在SLB實例的後端盡可能地去掛載多個可用區的ECS實例。SLB能夠支持跨可用區地掛載ECS雲伺服器，這樣可以避免某個可用區的ECS都出現故障的情況下，還有其他可用區的ECS能夠接替工作，雖然跨可用區掛在ECS會存在大約2毫秒左右的延遲，但是卻能夠大大地提升服務的可用性。

第二步就是針對於一些特別重要的業務，建議在不同的可用區分別地去購買SLB的實例。比如在可用區A和可用區B各自購買一個SLB實例，在此基礎之上再使用全球負載均衡GSLB來進行實例間的調度。

跨地域容災的實現

跨地域容災這一部分與上面介紹的可用區級別容災的第二步非常相似，也是藉助於GSLB產品實現的，GSLB即 智能DNS實現了針對於後端的健康檢查、路由調度的優化功能，能夠實現在地域之間的負載均衡實例的調度。關於這部分的更詳細的內容請參考：全球負載均衡跨地域容災解決方案(https://promotion.aliyun.com/ntms/act/globalslb.html)。

三、選擇性能共享型還是性能保障型實例

共享型vs保障型-WHY保障型

在如今這個共享經濟的時代，像滴滴打車這樣的模式是非常火的。但是即便是有了滴滴打車，但是還有人會去買車，這是因為會出現如下兩個大家可能曾經都碰到過的場景：

早晚高峰叫不到車？雨雪天氣路邊凍成狗？還大幅提價？

假期想遠離塵囂，找個僻靜曠野放空自我，叫個滴滴？也許有去，但保證無回！

所以說共享和保障都是客戶的需求。出於對於類似需求的考慮，阿里雲的負載均衡也推出了性能保障型實例。以前所推出的SLB共享型實例是因為性能指標沒有辦法實現隔離，因為所有的共享型實例都處於同一個大共享資源池中，所以在高峰期的時候就會出現資源的爭搶，這樣就無法滿足對於性能具有剛性需求的大客戶的訴求。除此之外，還有一些體量特別大的超級用戶，他們對於性能的要求會是非常高的，但是由於共享型實例無法做到性能隔離，也支持不了大顆粒度的性能指標，所以也無法完成這樣的工作。因此，阿里雲推出了性能保障型的負載均衡實例。

超強性能

保障型實例的性能規格如上圖所示，其並發連接數最大可以達到500萬，每秒的新建鏈接數(CPS)可以達到50萬，針對於七層負載均衡系統的QPS可以達到10萬。除此之外，性能保障型實例還具有以下的特點：

超強HTTPS性能。 性能保障型實例針對於七層系統，特別是HTTPS的業務進行了優化，實現了高性能硬加解卡，並且能夠實現使HTTPS的業務單實例可達10萬QPS。

超大並發連接數。 性能保障型實例的單實例的並發連接數可達500萬，所以其可承載物聯網場景的下海量連接，可以支撐共享自行車、智能手錶等存在特別大量長連接的場景。

共享型實例平滑升級。 原有的共享型實例可以平滑升級至性能保障型實例，而無需更換VIP。

完善的業務監控系統。 在推出性能保障型實例之後，因為每個實例都有相應的性能規格和性能指標，所以阿里雲也為用戶提供了完整的業務指標監控系統，並支持電話、簡訊、釘釘企業群等方式的告警。

性能規格

上圖所展現的是阿里雲SLB性能保障型實例的規格參數。圖中的最後兩行規格7、8默認在控制台上是無法購買的，目前只針對企業級用戶，而且需通過客戶經理申請後，通過白名單開放。

如何選擇規格

對於保障型實例而言，主要有如下幾個性能指標：

最大連接數：一個實例可承載的最大連接數。

新建連接數：CPS表示一個實例每秒可以新建的鏈接數。

每秒查詢數：QPS表示一個實例7層的像HTTP或者HTTPS系統的吞吐量。

通常一個4層SLB的性能好壞由最大連接數和新建連接數來衡量，它們表示了一個SLB系統的並發能力和處理突發連接的能力。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層系統的吞吐量。這里需要注意的是QPS是7層獨有概念。雖然每個規格都定義了三個性能指標，但是這並不代表這三個性能指標在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值，這里存在一個性能指標的短木板原則。比如在某一個應用系統中，QPS已經達到指標上限，但最大連接數還遠遠沒有達到上限，這時不論怎樣加大客戶端數量，最大連接數都會因為QPS達到上限，而無法達到最大值。

對於規格的選擇而言，需要通過之前提到的業務監控系統來獲取相關指標。如果用戶十分了解自己業務的相關指標，也就是對於高峰期的並發連接數會達到多少以及QPS會達到多少都有非常清晰的了解，也可以直接在控制台上選購。但是如果用戶並不清楚自己的相關業務指標，可以在初期選購按量付費的較高規格的實例，並且在一個業務周期內監控流量的峰值，在峰值確定好之後再通過變配的方式改變到比較合適的實例規格。目前性能保障型實例還處於公測階段，所以現在還沒有對於實例收取規格費用，也就是說在這個階段無論用戶選擇最小規格還是最大規格，實際上都只需要花費IP配置費和帶寬費就可以了，這樣也比較便於用戶去熟悉和使用阿里雲的性能保障型實例。

監控和告警

前面也有所提及，在負載均衡的控制台上面能夠直接地顯示出相應的一些性能指標，但是在這里只能夠實現對於性能指標的監控，卻無法進行告警。如果用戶需要進行監控告警，可以在阿里雲所提供的雲監控控制台進行操作。雲監控平台可以監控阿里雲中的所有產品並且實現業務告警的定製，並且可以選擇包括簡訊郵件、電話、企業釘釘群等方式進行業務的實時告警。

四、為什麼健康檢查異常

健康檢查機制

接下來分享在負載均衡的日常使用中出現的問題，特別是很多用戶都存在疑問的健康檢查部分的問題。

阿里雲的負載均衡一共可以支持四種協議，四層的負載均衡系統主要包括了TCP、HTTP以及UDP協議，而七層的系統則包括了HTTP和HTTPS，而由於目前HTTP和HTTPS都是使用的普通的HTTP方式，所以其實也可以歸結為三類協議。對於TCP而言，健康檢查的過程是通過發送ACK這種TCP的探測報文去探測埠是否仍然存活；對於HTTP而言，則主要使用的是HEAD的請求方式來檢查目標的頁面是否正常；UDP部分則主要借鑒了SMP協議的原理。

健康檢查部分主要會涉及到幾個指標，這些指標需要用戶在控制台上進行設置，上圖中給出了一些默認的建議值，比如響應的超時時間，也就是在每一次進行健康檢查的時候，如果超過一定時間健康檢查還沒有回應就認為這次的健康檢查是失敗的；還有健康檢查間隔，也就是兩次健康檢查之間通常需要間隔2秒鍾；而所謂的不健康閥值和健康閥值就是在網路環境中往往會由於網路的抖動以及其他的因素導致偶爾的一次健康檢查失敗了，但是這時候並不能認為服務是真的失敗了，所以需要設置一個閥值，比如3次就指的是當3次健康檢查都失敗的時候才會認為後端的服務是存在問題的，然後將其從轉發路徑中摘除掉。同樣的，當服務從不健康變為健康的時候，也需要進行連續的幾次探測，當確定處於穩定的健康狀態之後再將其加入到SLB的後端中去。

為啥會失敗(TCP)

TCP的健康檢查也經常會出現一些失敗的情況，這里也為大家提供了簡單的故障排查順序供參考。當出現健康檢查失敗的時候，首先可以檢查一下後端的伺服器是否已經啟動。如果後端伺服器的負載是比較高的，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導致健康檢查失敗。除此之外，因為對於阿里雲的負載均衡而言，健康檢查使用的都是私網地址實現的，所以如果根本沒有監聽到私網地址或者私網地址本身存在故障也會導致健康檢查的失敗。還有伺服器上可能存在防火牆，將監聽埠屏蔽掉了，導致健康檢查並未通過。此外還可能存在一些配置方面的問題，比如提供服務的埠和做健康檢查的埠不一致也可能存在健康檢查失敗。

針對於TCP的健康檢查而言，很多用戶會經常看到自己的後端伺服器上日誌上面有很多10或者16這些網段的訪問，並且訪問流量還比較大，這是因為之前所提到的健康檢查具有一定的間隔時間，比如2秒或者3秒一次。這時候一些用戶可能就會認為健康檢查會影響伺服器的性能，佔了很多的伺服器的連接數。其實可以從上圖中左側的報文交互情況看到，當SLB對於雲伺服器發起健康檢查的時候首先會發一個SYN的請求，如果伺服器埠是存活的，那麼它會回應一個ACK，這個時候SLB端就會緊接著發送RST報文。也就是說實際上連接是並沒有建立的，所以也不會佔用後端伺服器的連接數的資源，並且對於性能的影響也是極為有限的。

為啥會失敗(HTTP)

HTTP常見的健康檢查失敗原因大概會有這樣的三點：最常見的情況就是有些用戶把伺服器的HEAD請求方式禁掉了，因為默認在使用瀏覽器或者手機等請求一個頁面的時候使用的都是GET方式，有時候可能需要上傳數據則會使用POST方式，雖然很多伺服器都支持HEAD請求方式，但是有些伺服器可能會處於安全或者其他復雜因素的考慮將HEAD請求禁掉。所以在這里建議客戶將伺服器的HEAD請求方式打開，因為阿里雲負載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見情況就是頁面訪問本身上就存在問題，這樣的情況下健康檢查也是無法通過的。最後一種常見情況就是期望結果配置錯誤，針對於七層的健康檢查是通過使用HEAD請求方式去請求頁面，頁面返回碼可能會是200、300或者400以及500等，用戶可以在健康檢查的配置中設定預期的正常情況下的返回碼值，當健康檢查返回碼值與預期值不一致就會判定健康檢查是失敗的。

為啥會失敗(UDP)

這里介紹一下UDP健康檢查的原理。首先，健康檢查通過SLB向後端發送UDP報文探測來獲取狀態信息。SLB會周期性地給後端ECS發送UDP報文，如果UDP埠的業務處於正常情況，則沒有任何回應。而當服務出現問題，比如指定的UDP服務埠處於不可達的情況或者無服務的狀態的時候，會回復ICMP的不可達報文。這里也會存在一個問題就是如果後端伺服器已經變成了網路中的孤島，比如出現了整個伺服器的掉電、關機情況這樣完全不能工作的狀態，這時候的ICMP不可達報文是永遠不可能收到的，因為後端的伺服器無法收到SLB發來的UDP探測報文，那麼在這種情況下，可能會出現誤認為後端健康的情況，但是實際上這個服務可能已經宕掉了。為了應對這種情況，健康檢查還提供用戶自定義UDP應答報文來實現精確的UDP健康檢查，也就是由用戶自定義指定一個字元串，當後端的雲伺服器收到UDP健康檢查的探測的時候，也回應指定的字元串，之後SLB對於這個字元串進行對比和校驗，如果匹配成功則認為服務一定是健康的，這樣就可以實現非常精確的健康檢查。

而UDP的健康檢查失敗也有很多原因，比如在協議棧裡面有可能會有ICMP限速保護。當頻率達到一定速率的時候，ICMP會被協議棧限制，後端無法回應ICMP不可達報文，進而導致SLB收不到ICMP的報文，出現健康檢查的失敗情況。所以這部分是需要注意的，如果可能盡量將速率限制放大一些。

其他問題

健康檢查時好時壞的可能原因如下：

HTTP類型健康檢查目標URI響應慢。比如本身是動態頁面，會涉及到大量的計算才能夠渲染完成並返回到前端，這樣肯定就會導致健康檢查響應比較慢。如果伺服器負載過高同樣也會出現這樣的問題。

未全部放開對SLB健康檢查源地址的限制導致分布式健康檢查失敗。因為阿里雲的伺服器都是分布式的部署，健康檢查也會是分布式的探測，LVS等機器在後端有不同的源去針對某一個雲伺服器進行探測的，所以如果沒有將這些源地址都放開，實際上也會影響健康檢查的效率，因為對於這么多機器而言，只要有一台機器檢測到是正常的那麼就是正常的。

還可能出現直接訪問正常，但是健康檢查失敗的情況。造成這樣情況的可能原因如下：

防火牆限制。

目的埠不一致。

檢查方法不同，可能使用瀏覽器看頁面是沒問題的，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟。或者七層的健康檢查配置了URL按照域名轉發，但是在瀏覽器上直接訪問則是使用域名去做的，而健康檢查是使用IP地址做的，這樣也可能出現轉發和預期結果的不同。

檢查頻率不同，ICMP限速。

五、為什麼負載不均衡

調度演算法與會話保持

首先介紹一下負載均衡的調度演算法。阿里雲的負載均衡支持三種演算法，第一種演算法是單純的輪詢(RR)，也就是將業務的請求依次地分發到後端的伺服器。第二種演算法是加權輪詢(WRR)，也就是在處理調度的時候會根據針對於每一台後端伺服器設置權重來進行轉發。這里之所以設置權重是因為後端伺服器的處理能力可能是不同的，如果使用相同的權重進行輪詢可能就會把後端處理能力比較弱的伺服器擠爆，所以需要針對於伺服器的處理能力設置一些權重。第三種演算法是針對於加權最小連接數的輪詢(WLC)，也就是除了根據每台後端伺服器設定的權重值來進行輪詢，同時還考慮後端伺服器的實際負載，也就是連接數。當權重值相同時，當前連接數越小的後端伺服器被輪詢到的次數也越高，這樣就能夠保證負載盡量地均衡。如果不考慮這一點就會造成某些伺服器連接數已經很高了但是流量依然還往上面分發，而另外一些伺服器卻一直處於空閑狀態。

會話保持指的是來自同一用戶請求始終保持分發到同一台後端的雲伺服器上。對於同一用戶而言，使用的是四層的負載均衡和使用七層的負載均衡在理解上是不一樣的。如果是四層負載均衡，則會使用源IP地址標識同一用戶，所以如果在可能會有很多辦公電腦的大型企業中，這些電腦在企業內部是通過區域網的IP進行通信的，在訪問公網的時候都是通過NAT網關處理的，所以在走到Internet的時候，源地址通常會是一個或者很有限的幾個。在這種情況下，如果是四層的負載均衡就會把裡面所有的請求都視為來自同一個用戶的，這種情況下如果開啟了會話保持，就會發生問題。而七層的負載均衡是根據用戶瀏覽器中的Cookie來進行唯一識別的，對於剛才的案例在大型企業裡面因為內網訪問公網的源地址都是一樣的，導致沒有辦法識別到底是不是同一個用戶，此時建議使用七層的負載均衡方案解決，因為Cookie是每個瀏覽器都唯一的。會話的保持時間是可以在控制台上配置的，四層的負載均衡方案最大可達1小時，而七層的方案最大可達24小時。

為何不均衡

最後分享一下不均衡的常見情況。有時候會需要新加一個伺服器進來，這時候往往到新加進來的伺服器上的連接會很少，這是因為可能會存在以下原因：

存在會話保持的情況下，會話保持會讓請求停留在原有的伺服器上，這樣到新加進來的伺服器上的連接自然會少一些。

權重設置不一致，如果在權重的設置上存在區別，而新加進來的伺服器的權重如果很低，連接也過不去。

應用屬於長連接類型，因為需要在TCP上復用，如果客戶端不主動斷開連接，後續所有的請求都會繼續復用當前伺服器上的連接，只有新建連接才有可能到新的伺服器上。

而有時候在業務量或者新建連接較少時，也會出現負載不均衡的問題。這是因為每個Core都是獨立的調度單元，因此可能存在將某個Client的多條業務經過不同core的調度後全部轉發到一台ECS上的情況，同時由於業務量較少，因此出現了不均衡。建議使用輪詢演算法解決，在RR輪詢演算法中加入了擾亂因子，可以更加有效的打散SLB到後端的轉發路徑。

原文鏈接