一、什麼是負載均衡？
網際網路早期，業務流量比較小並且業務邏輯比較簡單，單臺伺服器便可以滿足基本的需求；但隨著網際網路的發展，業務流量越來越大並且業務邏輯也越來越複雜，單臺機器的效能問題以及單點問題凸顯了出來，因此需要多臺機器來進行效能的水平擴充套件以及避免單點故障。但是要如何將不同的使用者的流量分發到不同的伺服器上面呢？
早期的方法是使用DNS做負載，透過給客戶端解析不同的IP地址，讓客戶端的流量直接到達各個伺服器。但是這種方法有一個很大的缺點就是延時性問題，在做出排程策略改變以後，由於DNS各級節點的快取並不會及時的在客戶端生效，而且DNS負載的排程策略比較簡單，無法滿足業務需求，因此就出現了負載均衡。
客戶端的流量首先會到達負載均衡伺服器，由負載均衡伺服器透過一定的排程演算法將流量分發到不同的應用伺服器上面，同時負載均衡伺服器也會對應用伺服器做週期性的健康檢查，當發現故障節點時便動態的將節點從應用伺服器叢集中剔除，以此來保證應用的高可用。
負載均衡又分為四層負載均衡和七層負載均衡。四層負載均衡工作在OSI模型的傳輸層，主要工作是轉發，它在接收到客戶端的流量以後透過修改資料包的地址資訊將流量轉發到應用伺服器。
七層負載均衡工作在OSI模型的應用層，因為它需要解析應用層流量，所以七層負載均衡在接到客戶端的流量以後，還需要一個完整的TCP/IP協議棧。七層負載均衡會與客戶端建立一條完整的連線並將應用層的請求流量解析出來，再按照排程演算法選擇一個應用伺服器，並與應用伺服器建立另外一條連線將請求傳送過去，因此七層負載均衡的主要工作就是代理。
二、四層和七層負載均衡的區別？
2.1 - 技術原理上的區別。
所謂四層負載均衡，也就是主要透過報文中的目標地址和埠，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡裝置在接收到第一個來自客戶端的SYN 請求時，即透過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連線建立，即三次握手是客戶端和伺服器直接建立的，負載均衡裝置只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡裝置，在轉發報文的同時可能還會對報文原來的源地址進行修改。
所謂七層負載均衡，也稱為“內容交換”，也就是主要透過報文中的真正有意義的應用層內容，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡裝置如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連線(三次握手)後，才可能接受到客戶端傳送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。
負載均衡裝置在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連線。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡裝置的要求更高，處理七層的能力也必然會低於四層模式的部署方式。那麼，為什麼還需要七層負載均衡呢？
2.2 - 應用場景的需求。
七層應用負載的好處，是使得整個網路更"智慧化", 參考我們之前的另外一篇專門針對HTTP應用的最佳化的介紹，就可以基本上了解這種方式的優勢所在。例如訪問一個網站的使用者流量，可以透過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用快取技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。
當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。很多在後臺，(例如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等系統。
2.3 - 七層應用需要考慮的問題。
-
是否真的必要，七層應用的確可以提高流量智慧化，同時必不可免的帶來裝置配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
-
是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從伺服器遮蔽，但負載均衡裝置本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞排程的負載均衡裝置故障也會導致整個應用的崩潰。
-
是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智慧化，但是負載均衡裝置需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的排程。最簡單的一個考核就是能否取代後臺Nginx或者Apache等伺服器上的排程功能。能夠提供一個七層應用開發介面的負載均衡裝置，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智慧性。
三、負載均衡的演算法？
1. 隨機演算法
- Random隨機，按權重設定隨機機率。在一個截面上碰撞的機率高，但呼叫量越大分佈越均勻，而且按機率使用權重後也比較均勻，有利於動態調整提供者權重。
2. 輪詢及加權輪詢
- 輪詢(Round Robbin)當伺服器群中各伺服器的處理能力相同時，且每筆業務處理量差異不大時，最適合使用這種演算法。 輪循，按公約後的權重設定輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
- 加權輪詢(Weighted Round Robbin)為輪詢中的每臺伺服器附加一定權重的演算法。比如伺服器1權重1，伺服器2權重2，伺服器3權重3，則順序為1-2-2-3-3-3-1-2-2-3-3-3- ......
3. 最小連線及加權最小連線
- 最少連線(Least Connections)在多個伺服器中，與處理連線數(會話數)最少的伺服器進行通訊的演算法。即使在每臺伺服器處理能力各不相同，每筆業務處理量也不相同的情況下，也能夠在一定程度上降低伺服器的負載。
- 加權最少連線(Weighted Least Connection)為最少連線演算法中的每臺伺服器附加權重的演算法，該演算法事先為每臺伺服器分配處理連線的數量，並將客戶端請求轉至連線數最少的伺服器上。
4. 雜湊演算法
- 普通雜湊
- 一致性雜湊一致性Hash，相同引數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
5. IP地址雜湊
- 透過管理傳送方IP和目的地IP地址的雜湊，將來自同一傳送方的分組(或傳送至同一目的地的分組)統一轉發到相同伺服器的演算法。當客戶端有一系列業務需要處理而必須和一個伺服器反覆通訊時，該演算法能夠以流(會話)為單位，保證來自相同客戶端的通訊能夠一直在同一伺服器中進行處理。
6.URL雜湊
- 透過管理客戶端請求URL資訊的雜湊，將傳送至相同URL的請求轉發至同一伺服器的演算法。
四、負載均衡的實現（DNS > 資料鏈路層 > IP層 > Http層）？
1 - DNS域名解析負載均衡（延遲）
利用DNS處理域名解析請求的同時進行負載均衡是另一種常用的方案。在DNS伺服器中配置多個A記錄，如：www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.
每次域名解析請求都會根據負載均衡演算法計算一個不同的IP地址返回，這樣A記錄中配置的多個伺服器就構成一個叢集，並可以實現負載均衡。
DNS域名解析負載均衡的優點是將負載均衡工作交給DNS，省略掉了網路管理的麻煩，缺點就是DNS可能快取A記錄，不受網站控制。事實上，大型網站總是部分使用DNS域名解析，作為第一級負載均衡手段，然後再在內部做第二級負載均衡。
2 - 資料鏈路層負載均衡(LVS)
資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改mac地址進行負載均衡。
這種資料傳輸方式又稱作三角傳輸模式，負載均衡資料分發過程中不修改IP地址，只修改目的的mac地址，透過配置真實物理伺服器叢集所有機器虛擬IP和負載均衡伺服器IP地址一樣，從而達到負載均衡，這種負載均衡方式又稱為直接路由方式（DR）.
在上圖中，使用者請求到達負載均衡伺服器後，負載均衡伺服器將請求資料的目的mac地址修改為真是WEB伺服器的mac地址，並不修改資料包目標IP地址，因此資料可以正常到達目標WEB伺服器，該伺服器在處理完資料後可以經過網管伺服器而不是負載均衡伺服器直接到達使用者瀏覽器。
使用三角傳輸模式的鏈路層負載均衡是目前大型網站所使用的最廣的一種負載均衡手段。在linux平臺上最好的鏈路層負載均衡開源產品是LVS(linux virtual server)。
3 - IP負載均衡(SNAT)
IP負載均衡：即在網路層透過修改請求目標地址進行負載均衡。
使用者請求資料包到達負載均衡伺服器後，負載均衡伺服器在作業系統核心進行獲取網路資料包，根據負載均衡演算法計算得到一臺真實的WEB伺服器地址，然後將資料包的IP地址修改為真實的WEB伺服器地址，不需要透過使用者程式處理。真實的WEB伺服器處理完畢後，相應資料包回到負載均衡伺服器，負載均衡伺服器再將資料包源地址修改為自身的IP地址傳送給使用者瀏覽器。
這裡的關鍵在於真實WEB伺服器相應資料包如何返回給負載均衡伺服器，一種是負載均衡伺服器在修改目的IP地址的同時修改源地址，將資料包源地址改為自身的IP，即源地址轉換（SNAT），另一種方案是將負載均衡伺服器同時作為真實物理伺服器的閘道器伺服器，這樣所有的資料都會到達負載均衡伺服器。
IP負載均衡在核心程式完成資料分發，較反向代理均衡有更好的處理效能。但由於所有請求響應的資料包都需要經過負載均衡伺服器，因此負載均衡的網路卡頻寬成為系統的瓶頸。
4 - HTTP重定向負載均衡(少見)
HTTP重定向伺服器是一臺普通的應用伺服器，其唯一的功能就是根據使用者的HTTP請求計算一臺真實的伺服器地址，並將真實的伺服器地址寫入HTTP重定向響應中（響應狀態嗎302）返回給瀏覽器，然後瀏覽器再自動請求真實的伺服器。
這種負載均衡方案的優點是比較簡單，缺點是瀏覽器需要每次請求兩次伺服器才能拿完成一次訪問，效能較差；使用HTTP302響應碼重定向，可能是搜尋引擎判斷為SEO作弊，降低搜尋排名。重定向伺服器自身的處理能力有可能成為瓶頸。因此這種方案在實際使用中並不見多。
5 - 反向代理負載均衡(nginx)
傳統代理伺服器位於瀏覽器一端，代理瀏覽器將HTTP請求傳送到網際網路上。而反向代理伺服器則位於網站機房一側，代理網站web伺服器接收http請求。
反向代理的作用是保護網站安全，所有網際網路的請求都必須經過代理伺服器，相當於在web伺服器和可能的網路攻擊之間建立了一個屏障。
除此之外，代理伺服器也可以配置快取加速web請求。當使用者第一次訪問靜態內容的時候，靜態記憶體就被快取在反向代理伺服器上，這樣當其他使用者訪問該靜態內容時，就可以直接從反向代理伺服器返回，加速web請求響應速度，減輕web伺服器負載壓力。
另外，反向代理伺服器也可以實現負載均衡的功能。
由於反向代理伺服器轉發請求在HTTP協議層面，因此也叫應用層負載均衡。優點是部署簡單，缺點是可能成為系統的瓶頸。
參考文章
[1 - MGW——美團點評高效能四層負載均衡]
[2 - 四層和七層負載均衡的區別]
[3 - 負載均衡演算法及手段]