談談大型網站架構系列：負載均衡詳解

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

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

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

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

本次分享大綱

1. 負載均衡原理
2. DNS負載均衡
3. HTTP負載均衡
4. IP負載均衡
5. 鏈路層負載均衡
6. 混合型P負載均衡

1、負載均衡原理

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

• 應用集羣：將同一應用部署到多臺機器上，組成處理集羣，接收負載均衡設備分發的請求，進行處理，並返回相應數據。
• 負載均衡設備：將用戶訪問的請求，根據負載均衡算法，分發到集羣中的一臺處理服務器。（一種把網絡請求分散到一個服務器集羣中的可用服務器上去的設備）

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

1.解決併發壓力，提升應用處理性能（增長吞吐量，增強網絡處理能力）；

2.提供故障轉移，實現高可用；

3.經過添加或減小服務器數量，提供網站伸縮性（擴展性）；

4.安全防禦；（負載均衡設備上作一些過濾，黑白名單等處理）

2、負載均衡分類

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

2.1DNS負載均衡

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

優勢

1. 使用簡單：負載均衡工做，交給DNS服務器處理，省掉了負載均衡服務器維護的麻煩
2. 提升性能：能夠支持基於地址的域名解析，解析成距離用戶最近的服務器地址，能夠加快訪問速度，改善性能；

缺點

1. 可用性差：DNS解析是多級解析，新增/修改DNS後，解析時間較長；解析過程當中，用戶訪問網站將失敗；
2. 擴展性低：DNS負載均衡的控制權在域名商那裏，沒法對其作更多的改善和擴展；
3. 維護性差：也不能反映服務器的當前運行狀態；支持的算法少；不能區分服務器的差別（不能根據系統與服務的狀態來判斷負載）

 實踐建議

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

1.3  IP負載均衡

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

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

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

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

 優勢：

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

缺點：

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

2.4鏈路層負載均衡

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

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

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

優勢：性能好；

缺點：配置複雜；

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

2.5混合型負載均衡

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

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

方式一，以下圖：

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

方式二，以下圖：

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

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

分享是快樂的，也是我的成長的過程。文章通常是本身的學習總結，工做經驗，不足之處在所不免，請你們指正，共同進步。創建了一個以架構爲中心的KK羣466097527 ，歡迎你們加入。專一大型分佈式網站架構，大數據，架構模式，設計模式。

 

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不等；

缺點

（1）價格昂貴；

（2）擴展能力差；

4.4小結

（1）通常硬件的負載均衡也要作雙機高可用，所以成本會比較高。

（2）互聯網公司通常使用開源軟件，所以大部分應用採用軟件負載均衡；部分採用硬件負載均衡。

好比某互聯網公司，目前是使用幾臺F5作全局負載均衡，內部使用Nginx等軟件負載均衡。

5、本次分享總結

 以上主要從負載均衡原理，分類，算法，硬件負載均衡進行了介紹。下次分享，負載均衡詳解（三），主要介紹：軟件負載均衡（LVS,Nginx，Haproxy，Apache特色，架構），負載均衡軟件技術選型比較，應用負載均衡的問題和解決方案等方面。

分享是快樂的，也是我的成長的過程。文章通常是本身的學習總結，工做經驗，不足之處在所不免，請你們指正，共同進步。創建了一個以架構爲中心的KK羣466097527 ，歡迎你們加入。專一大型分佈式網站架構，大數據，架構模式，設計模式。

 

本次分享大綱

1. 軟件負載均衡概述
2. Ngnix負載均衡
3. Lvs負載均衡
4. Haproxy負載均衡
5. 本次分享總結

1、軟件負載均衡概述

硬件負載均衡性能優越，功能全面，可是價格昂貴，通常適合初期或者土豪級公司長期使用。所以軟件負載均衡在互聯網領域大量使用。經常使用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。本文參考大量文檔，部分爲直接拷貝，參考出處見負載均衡詳解（4）。

2、Ngnix負載均衡

Ngnix是一款輕量級的Web服務器/反向代理服務器，工做在七層Http協議的負載均衡系統。具備高性能、高併發、低內存使用等特色。是一個輕量級的Http和反向代理服務器。Nginx使用epoll and kqueue做爲開發模型。可以支持高達 50,000 個併發鏈接數的響應。

操做系統：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）

開發語言：C

併發性能：官方支持每秒5萬併發，實際國內通常到每秒2萬併發，有優化到每秒10萬併發的。具體性能看應用場景。

2.1.特色

1.模塊化設計：良好的擴展性，能夠經過模塊方式進行功能擴展。

2.高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會馬上啓動另外一個worker。

3.內存消耗低：一萬個長鏈接（keep-alive）,僅消耗2.5MB內存。

4.支持熱部署：不用中止服務器，實現更新配置文件，更換日誌文件、更新服務器程序版本。

5.併發能力強：官方數據每秒支持5萬併發；

6.功能豐富：優秀的反向代理功能和靈活的負載均衡策略

2.2.功能

2.2.1基本功能

• 支持靜態資源的web服務器。
• http,smtp,pop3協議的反向代理服務器、緩存、負載均衡；
• 支持FASTCGI（fpm）
• 支持模塊化，過濾器（讓文本能夠實現壓縮，節約帶寬）,ssl及圖像大小調整。
• 內置的健康檢查功能
• 基於名稱和ip的虛擬主機
• 定製訪問日誌
• 支持平滑升級
• 支持KEEPALIVE
• 支持url rewrite
• 支持路徑別名
• 支持基於IP和用戶名的訪問控制。
• 支持傳輸速率限制，支持併發數限制。

2.2.2擴展功能

2.2.3性能

Nginx的高併發，官方測試支持5萬併發鏈接。實際生產環境能到2-3萬併發鏈接數。10000個非活躍的HTTP keep-alive 鏈接僅佔用約2.5MB內存。三萬併發鏈接下，10個Nginx進程，消耗內存150M。淘寶tengine團隊測試結果是「24G內存機器上，處理併發請求可達200萬」。

2.3架構

2.3.1Nginx的基本工做模式

 

一個master進程，生成一個或者多個worker進程。可是這裏master是使用root身份啓動的，由於nginx要工做在80端口。而只有管理員纔有權限啓動小於低於1023的端口。master主要是負責的做用只是啓動worker，加載配置文件，負責系統的平滑升級。其它的工做是交給worker。那麼當worker被啓動以後，也只是負責一些web最簡單的工做，而其餘的工做都是有worker中調用的模塊來實現的。

模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。好比：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工做。來實現整個工做的完成。

他們是如何實現熱部署的呢？實際上是這樣的，咱們前面說master不負責具體的工做，而是調用worker工做，他只是負責讀取配置文件，所以當一個模塊修改或者配置文件發生變化，是由master進行讀取，所以此時不會影響到worker工做。在master進行讀取配置文件以後，不會當即的把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工做，當worker工做完畢以後，直接當掉這個子進程，更換新的子進程，使用新的規則。

2.3.2Nginx支持的sendfile機制

Sendfile機制，用戶將請求發給內核，內核根據用戶的請求調用相應用戶進程，進程在處理時須要資源。此時再把請求發給內核（進程沒有直接IO的能力），由內核加載數據。內核查找到數據以後，會把數據複製給用戶進程，由用戶進程對數據進行封裝，以後交給內核，內核在進行tcp/ip首部的封裝，最後再發給客戶端。這個功能用戶進程只是發生了一個封裝報文的過程，卻要繞一大圈。所以nginx引入了sendfile機制，使得內核在接受到數據以後，再也不依靠用戶進程給予封裝，而是本身查找本身封裝，減小了一個很長一段時間的浪費，這是一個提高性能的核心點。

 

以上內容摘自網友發佈的文章，簡單一句話是資源的處理，直接經過內核層進行數據傳遞，避免了數據傳遞到應用層，應用層再傳遞到內核層的開銷。

目前高併發的處理，通常都採用sendfile模式。經過直接操做內核層數據，減小應用與內核層數據傳遞。

2.3.3Nginx通訊模型（I/O複用機制）

開發模型：epoll和kqueue。

支持的事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。

支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數據的數量，錯誤代碼.

支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.

以上概念較多，你們自行百度或谷歌，知識領域是網絡通訊（BIO,NIO,AIO）和多線程方面的知識。

2.4均衡策略

nginx的負載均衡策略能夠劃分爲兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認狀況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數便可。擴展策略有不少，如fair、通用hash、consistent hash等，默認不編譯進nginx內核。因爲在nginx版本升級中負載均衡的代碼沒有本質性的變化，所以下面將以nginx1.0.15穩定版爲例，從源碼角度分析各個策略。

2.4.1. 加權輪詢（weighted round robin）

輪詢的原理很簡單，首先咱們介紹一下輪詢的基本流程。以下是處理一次請求的流程圖：

 

圖中有兩點須要注意，第一，若是能夠把加權輪詢算法分爲先深搜索和先廣搜索，那麼nginx採用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其餘機器低，纔開始將請求分給下一個高權重的機器；第二，當全部後端機器都down掉時，nginx會當即將全部機器的標誌位清成初始狀態，以免形成全部的機器都處在timeout的狀態，從而致使整個前端被夯住。

2.4.2. ip hash

ip hash是nginx內置的另外一個負載均衡的策略，流程和輪詢很相似，只是其中的算法和具體的策略有些變化，以下圖所示：

 

2.4.3. fair

fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據後端服務器的響應時間判斷負載狀況，從中選出負載最輕的機器進行分流。這種策略具備很強的自適應性，可是實際的網絡環境每每不是那麼簡單，所以要慎用。

2.4.4 通用hash、一致性hash

這兩種也是擴展策略，在具體的實現上有些差異，通用hash比較簡單，能夠以nginx內置的變量爲key進行hash，一致性hash採用了nginx內置的一致性hash環，能夠支持memcache。

2.5場景

Ngnix通常做爲入口負載均衡或內部負載均衡，結合反向代理服務器使用。如下架構示例，僅供參考，具體使用根據場景而定。

2.5.1入口負載均衡架構

 

Ngnix服務器在用戶訪問的最前端。根據用戶請求再轉發到具體的應用服務器或二級負載均衡服務器（LVS）

2.5.2內部負載均衡架構

 

LVS做爲入口負載均衡，將請求轉發到二級Ngnix服務器，Ngnix再根據請求轉發到具體的應用服務器。

2.5.3Ngnix高可用

 

分佈式系統中，應用只部署一臺服務器會存在單點故障，負載均衡一樣有相似的問題。通常可採用主備或負載均衡設備集羣的方式節約單點故障或高併發請求分流。

Ngnix高可用，至少包含兩個Ngnix服務器，一臺主服務器，一臺備服務器，之間使用Keepalived作健康監控和故障檢測。開放VIP端口，經過防火牆進行外部映射。

DNS解析公網的IP實際爲VIP。

分享是快樂的，也是我的成長的過程。文章通常是本身的學習總結，工做經驗，不足之處在所不免，請你們指正，共同進步。創建了一個以架構爲中心的KK羣466097527 ，歡迎你們加入。專一大型分佈式網站架構，大數據，架構模式，設計模式。