詳解負載均衡技術及分佈式架構

前言

面對大量用戶訪問、高併發請求，海量數據，可使用高性能的服務器、大型數據庫，存儲設備，高性能Web服務器，採用高效率的編程語言好比(Go，Scala)等，當單機容量達到極限時，咱們須要考慮業務拆分和分佈式部署，來解決大型網站訪問量大，併發量高，海量數據的問題。

從單機網站到分佈式網站，很重要的區別是業務拆分和分佈式部署，將應用拆分後，部署到不一樣的機器上，實現大規模分佈式系統。分佈式和業務拆分解決了，從集中到分佈的問題，可是每一個部署的獨立業務還存在單點的問題和訪問統一入口問題，爲解決單點故障，咱們能夠採起冗餘的方式。將相同的應用部署到多臺機器上。解決訪問統一入口問題，咱們能夠在集羣前面增長負載均衡設備，實現流量分發。

負載均衡（Load Balance），意思是將負載（工做任務，訪問請求）進行平衡、分攤到多個操做單元（服務器，組件）上進行執行。是解決高性能，單點故障（高可用），擴展性（水平伸縮）的終極解決方案。

本文是負載均衡詳解的第一篇文章，介紹負載均衡的原理，負載均衡分類（DNS負載均衡,HTTP負載均衡，IP負載均衡，鏈路層負載均衡,混合型P負載均衡）。部份內容摘自讀書筆記。

1、負載均衡原理

系統的擴展可分爲縱向（垂直）擴展和橫向（水平）擴展。縱向擴展，是從單機的角度經過增長硬件處理能力，好比CPU處理能力，內存容量，磁盤等方面，實現服務器處理能力的提高，不能知足大型分佈式系統（網站），大流量，高併發，海量數據的問題。所以須要採用橫向擴展的方式，經過添加機器來知足大型網站服務的處理能力。好比：一臺機器不能知足，則增長兩臺或者多臺機器，共同承擔訪問壓力。這就是典型的集羣和負載均衡架構：以下圖：

• 應用集羣：將同一應用部署到多臺機器上，組成處理集羣，接收負載均衡設備分發的請求，進行處理，並返回相應數據。

• 負載均衡設備：將用戶訪問的請求，根據負載均衡算法，分發到集羣中的一臺處理服務器。（一種把網絡請求分散到一個服務器集羣中的可用服務器上去的設備）

負載均衡的做用（解決的問題）：

1. 解決併發壓力，提升應用處理性能（增長吞吐量，增強網絡處理能力）；
2. 提供故障轉移，實現高可用；
3. 經過添加或減小服務器數量，提供網站伸縮性（擴展性）；
4. 安全防禦；（負載均衡設備上作一些過濾，黑白名單等處理）

2、負載均衡分類

根據實現技術不一樣，可分爲DNS負載均衡，HTTP負載均衡，IP負載均衡，鏈路層負載均衡等。

2.1 DNS負載均衡

最先的負載均衡技術，利用域名解析實現負載均衡，在DNS服務器，配置多個A記錄，這些A記錄對應的服務器構成集羣。大型網站老是部分使用DNS解析，做爲第一級負載均衡。以下圖：

優勢

1. 使用簡單：負載均衡工做，交給DNS服務器處理，省掉了負載均衡服務器維護的麻煩

2. 提升性能：能夠支持基於地址的域名解析，解析成距離用戶最近的服務器地址，能夠加快訪問速度，改善性能；

缺點

1. 可用性差：DNS解析是多級解析，新增/修改DNS後，解析時間較長；解析過程當中，用戶訪問網站將失敗；

2. 擴展性低：DNS負載均衡的控制權在域名商那裏，沒法對其作更多的改善和擴展；

3. 維護性差：也不能反映服務器的當前運行狀態；支持的算法少；不能區分服務器的差別（不能根據系統與服務的狀態來判斷負載）

實踐建議

將DNS做爲第一級負載均衡，A記錄對應着內部負載均衡的IP地址，經過內部負載均衡將請求分發到真實的Web服務器上。通常用於互聯網公司，複雜的業務系統不合適使用。以下圖：

2.2 IP負載均衡

在網絡層經過修改請求目標地址進行負載均衡。

用戶請求數據包，到達負載均衡服務器後，負載均衡服務器在操做系統內核進程獲取網絡數據包，根據負載均衡算法獲得一臺真實服務器地址，而後將請求目的地址修改成，得到的真實ip地址，不須要通過用戶進程處理。

真實服務器處理完成後，響應數據包回到負載均衡服務器，負載均衡服務器，再將數據包源地址修改成自身的ip地址，發送給用戶瀏覽器。以下圖：

IP負載均衡，真實物理服務器返回給負載均衡服務器，存在兩種方式：

1. 負載均衡服務器在修改目的ip地址的同時修改源地址。將數據包源地址設爲自身盤，即源地址轉換（snat）。
2. 將負載均衡服務器同時做爲真實物理服務器集羣的網關服務器。

優勢：

（1）在內核進程完成數據分發，比在應用層分發性能更好；

缺點：

（2）全部請求響應都須要通過負載均衡服務器，集羣最大吞吐量受限於負載均衡服務器網卡帶寬；

2.3 鏈路層負載均衡

在通訊協議的數據鏈路層修改mac地址，進行負載均衡。

數據分發時，不修改ip地址，指修改目標mac地址，配置真實物理服務器集羣全部機器虛擬ip和負載均衡服務器ip地址一致，達到不修改數據包的源地址和目標地址，進行數據分發的目的。

實際處理服務器ip和數據請求目的ip一致，不須要通過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成爲瓶頸。也稱爲直接路由模式（DR模式）。以下圖：

優勢：性能好；

缺點：配置複雜；

實踐建議：DR模式是目前使用最普遍的一種負載均衡方式。

2.4 混合型負載均衡

因爲多個服務器羣內硬件設備、各自的規模、提供的服務等的差別，能夠考慮給每一個服務器羣採用最合適的負載均衡方式，而後又在這多個服務器羣間再一次負載均衡或羣集起來以一個總體向外界提供服務（即把這多個服務器羣當作一個新的服務器羣），從而達到最佳的性能。將這種方式稱之爲混合型負載均衡。

此種方式有時也用於單臺均衡設備的性能不能知足大量鏈接請求的狀況下。是目前大型互聯網公司，廣泛使用的方式。

方式一，以下圖：

以上模式適合有動靜分離的場景，反向代理服務器（集羣）能夠起到緩存和動態請求分發的做用，當時靜態資源緩存在代理服務器時，則直接返回到瀏覽器。若是動態頁面則請求後面的應用負載均衡（應用集羣）。

方式二，以下圖：

以上模式，適合動態請求場景。

因混合模式，能夠根據具體場景，靈活搭配各類方式，以上兩種方式僅供參考。

3、負載均衡算法

經常使用的負載均衡算法有，輪詢，隨機，最少連接，源地址散列，加權等方式；

3.1 輪詢

將全部請求，依次分發到每臺服務器上，適合服務器硬件同相同的場景。

優勢：服務器請求數目相同；

缺點：服務器壓力不同，不適合服務器配置不一樣的狀況；

3.2 隨機

請求隨機分配到各個服務器。

優勢：使用簡單；

缺點：不適合機器配置不一樣的場景；

3.3 最少連接

將請求分配到鏈接數最少的服務器（目前處理請求最少的服務器）。

優勢：根據服務器當前的請求處理狀況，動態分配；

缺點：算法實現相對複雜，須要監控服務器請求鏈接數；

3.4 Hash（源地址散列）

根據IP地址進行Hash計算，獲得IP地址。

優勢：未來自同一IP地址的請求，同一會話期內，轉發到相同的服務器；實現會話粘滯。

缺點：目標服務器宕機後，會話會丟失；

3.5 加權

在輪詢，隨機，最少連接，Hash’等算法的基礎上，經過加權的方式，進行負載服務器分配。

優勢：根據權重，調節轉發服務器的請求數目；

缺點：使用相對複雜；

4、硬件負載均衡

採用硬件的方式實現負載均衡，通常是單獨的負載均衡服務器，價格昂貴，通常土豪級公司能夠考慮，業界領先的有兩款，F5和A10。

使用硬件負載均衡，主要考慮一下幾個方面：

1. 功能考慮：功能全面支持各層級的負載均衡，支持全面的負載均衡算法，支持全局負載均衡；
2. 性能考慮：通常軟件負載均衡支持到5萬級併發已經很困難了，硬件負載均衡能夠支持
3. 穩定性：商用硬件負載均衡，通過了良好的嚴格的測試，從通過大規模使用，在穩定性方面高；
4. 安全防禦：硬件均衡設備除具有負載均衡功能外，還具有防火牆，防DDOS攻擊等安全功能；
5. 維護角度：提供良好的維護管理界面，售後服務和技術支持；
6. 土豪公司：F5 Big Ip 價格：15w~55w不等；A10 價格：55w-100w不等；

缺點

• 價格昂貴；
• 擴展能力差；

5、小結

• 通常硬件的負載均衡也要作雙機高可用，所以成本會比較高。
• 互聯網公司通常使用開源軟件，所以大部分應用採用軟件負載均衡；部分採用硬件負載均衡。
• 好比某互聯網公司，目前是使用幾臺F5作全局負載均衡，內部使用Nginx等軟件負載均衡。