基于Nginx服務器負載均衡技術的研究與改進

張云 許江淳 李玉惠 王志偉 史鵬坤

摘要：為了減輕快速增長的網絡負載壓力，本文為web后端服務器集群搭建了基于Nginx的負載均衡服務器，將其作為集群的反向代理服務器，使集群具備了負載均衡的功能，對負載均衡算法進行了分析。并針對Ngmx自帶負載均衡策略的缺陷提出了一種動態自適應負載均衡算法，改進型加權最小連接數算法，同時對其算法進行了設計。測試的實驗結果驗證了改進型加權最小連接數算法的可行性。

關鍵詞：Nginx；服務器集群；均衡策略；動態自適應負載均衡算法

中圖分類號：TP3-05 文獻標識碼：A DOI：10.3969/j.issn.1003-6970.2017.08.002

本文著錄格式：張云，許江淳，李玉惠，等.基于服務器負載均衡技術的研究與改進[J].軟件，2017，38（7）：06-12

隨著移動互聯網的蓬勃發展，傳統運營商的主要利潤點如短信及話費的利潤受到前所未有的沖擊。為適應新時代的新形勢，各大運營商均已在網絡支撐方面傳統的運維體系已出現在面對大量網絡負荷時請求處理緩慢，服務器負載過重導致頁面無響應等使用戶使用體驗較差等狀況。因此各大運營商均將建立新一代集中運維體系作為一個重要緩解網絡壓力手段。

本文針對Nginx自帶的算法不能考慮服務器集群中各個具體服務器的實時負載情況單純按照初始設定來經行網絡請求分配的問題，對Linux操作系統和Nginx服務器源碼進行分析和研究，著重對負載均衡算法進行了優化從而達到減少服務器響應時間的同時提高服務器性能的穩定性，進而使用戶獲得更好的網絡服務體驗。

1 Nginx服務器

1.1 Nginx的模塊體系

Nginx的內部結構是由核心部分和一系列功能檢塊組成的，這樣使得每個模塊的功能相對簡單，便于對系統進行功能擴展，各模塊之間的關系如圖1所示：

標準的Nginx模塊一般可分為五大類：核心模塊，郵件服務模塊，可選Http模塊，標準Http模塊和第三方模塊。

http模塊和mail模塊分別處理http相關協議與郵件相關協議（如SMTP/IMAP/POP3等）的各類事件，同時確保這些事件能以正確的順序來調用其它相關功能模塊。

（1）事件模塊（event module），用于搭建獨立的事件處理框架包括獨立的事件處理機制和事物響應機制，為nginx處理各種不同事物提供保障。

（2）handler模塊（phase handler），用來處理具體的用戶請求并同時生成待響應內容。

（3）filter模塊（out putfilter），用來處理像客戶端發送的響應，通過該模塊可以對服務器向客戶端的輸出經行修改。

（4）反向代理模塊（upstream），Nginx可作為反向代理服務器，用戶先將請求發送到反向代理服務器，反向代理服務器再根據請求類型或路由參數將具體請求在提交給真正處理請求的后端服務器，讀取響應數據并將該數據在傳回客戶端。

（5）負載均衡模塊（load-balancer），該模塊內含多種負載均衡算法，與upstream模塊同時使用，當upstream配置文件中使用不同標記時調用該模塊中不同算法來實現不同的負載均衡策略。

（6）第三方模塊（extend module），具體使用時如Nginx自帶模塊并不能很好解決實際問題時，用戶需可自行添加一些模塊。

1.2 Nginx的服務器架構

Nginx在運行時會產生一個主進程和多個工作進程，同時也會產生一些cache相關進程。工作時，客戶端發出新的網絡請求時，Ngmx服務器會與后端服務器進行通信，根據具體的負載均衡策略Ngmx會將請求提交給不同的服務器，服務器接到這些請求時會進行數據的處理以及相關頁面的渲染，然后將這些處理后的內容提交給Nginx服務器，Nginx服務器再將接收到的處理結果反饋給客戶端。

當客戶端訪問的是一些常用數據時，Ngmx服務器會根據客戶端發送的請求來確定客戶端所需要的具體內容同時根據該請求來訪問不同的緩存服務器，緩存服務器給Nginx返回具體數據后，Nginx將緩存服務返回的數據直接反饋給客戶端以此來降低服務器的負荷，從而減少網絡服務的響應時間。該模型中Nginx的主進程，工作進程，緩存服務器，后端服務器之間關系架構如圖2所示：

1.3 Nginx的反向代理

反向代理是通過一種反向代理的手段將請求發送給反向代理服務器，反向代理服務器再將請求發送給后端服務器，同時后端服務器也將數據的處理結果發送給反向代理服務器，接收到這些數據后反向代理服務器再將數據返回給客戶端。通過這種方法使服務器集群在客戶端看來只需訪問反向代理服務器，減輕了客戶端發送請求的網絡資源開銷。反向代理服務器基本原理示意圖3所示：

1.4 Nginx的負載均衡

按照OSI網絡模型，Nginx所實現的負載均衡是處于第七層的Web負載均衡，適用于Web服務器集群。負載均衡策略的劃分有很多種，在此按照最常用的分類方式將Nginx的負載均衡策略劃分為兩種：內置負載均衡策略和擴展負載均衡策略。其中，內置策略包括加權輪詢（Round Robin）策略，ip_hash策略和最小連接數（Least Connected）策略，默認情況下，Nginx使用輪詢策略將網絡請求傳送到應用服務器，不需要任何精確配置，只使用基本設置就可以進行工作，一個精簡的Nginx負載均衡配置可以如下所示：

該段配置利用upstream模塊，將本地三個端口（3000，3001，3002）中對應的服務器程序當作三個負載均衡資源并按照輪詢策略將這些資源自動寫人一張輪詢列表中，當服務器接收到客戶端請求時會將請求按照（3000，3001，3002）的順序依次分配給這三個端口對應的服務器程序。

2 動態自適應負載均衡算法的設計

2.1 負載均衡算法的基本思路

當服務器負載較小時服務器的處理能力相似，則請求分配到任意服務器對與用戶的體驗差距都不大，而為了一定程度上減輕負載均衡處理器的工作量，當存在服務器內存及CPU使用率低于20%時，帶寬占用率相近的情況下采取Nginx自帶的最小連接數策略。

當全部服務器的內存或CPU使用率高于20%時：將后端服務器的CPU占用傘，內存占用率以及帶寬占用率作為影響因子，根據每個因子的權值向量，amem，anet計算平均負載冗余（其中n為服務器數量）：

同時計算具體每臺服務器的負載冗余值：

將計算得出的負載冗余值小于平均負載冗余的服務器列為備選服務器，使之列人備選服務器表，然后再對列入備選服務器表的服務器采取最小接數負載均衡算法進行負載均衡。直到備選服務器列表中所有服務器負載都大于該平均值時重新計算負載冗余。

其算法示意圖為圖4所示：

2.2 改進型加權最小連接數算法

加權最小連接數調度算法是一種動態的負載均衡算法，其思想如下：假設服務器集群用服務器集合S={S1，S2，…，Sn}（n>l）來表示，每個服務器的權值用W（Si）（l

當服務器節點Si又滿足公式（4）：

根據加權最小連接數調度算法的思想，此時，只要滿足式子（4），就優先給服務器Si分配負載。

由于服務器的當前連接數并不能準確代表服務器的實際負載量，隨著系統的運行，各個服務器的處理能力和狀態會不斷地發生變化。因此，提出一種改進型加權最小連接數算法來重新計算權值。

改進型加權最小連接數算法是在將新的連接請求分配到具體服務器之前會進行服務器負載冗余值計算，具體的計算需要提取服務器的運行參數作為負載因子，與所對應的權值相乘作為具體的負載冗余度。下面將介紹具體負載因子的提取方法和與之對應的權值計算方法。

對于云平臺服務器而言，為了達到滿足負載均衡的效果，選取如下動態負載因子作為判決條件：CPU使用率內存使用率t/wew/，網絡帶寬使用率以及最小連接數算法所關注的服務器當前請求中請求的數量num。

加權最小連接數的各個因子的權值計算：

該算法中因權值向量的選擇會直接影響到最終服務器負載冗余計算的結果，且因為有多個權值，人為確定的值產生的計算結果會與實際情況產生偏差。

因此本文選擇模擬退火算法來確定具體的權值向量。模擬退火算法來源于固體退火原理，是一種基于概率的算法，其過程分為：先將待加熱體加至充分高溫，隨后使其緩慢冷卻，加溫過程中，加熱體內部粒子內能隨溫度升高逐漸增大，冷卻過程中其內部粒子內能逐漸趨向有序，在不同溫度時加熱體本身都處在相應的平衡態，最后降至常溫時達到基態，內能在基態時達到最小值。

模擬退火算法是一種可以較好解決組合優化問題的算法，并且最終結果與初始態無關，其結果更傾向于全局最優解。

本文選用的模擬退火算法模型如圖5所示：

具體過程為先在服務器集群中隨機抽取一臺機器作為測試機器，暫時屏蔽其他機器，使用模擬工具模擬發送請求并提交給該測試服務器，同時記錄本文所選擇的三個負載因子，和服務器響應時間。根據公式：

計算權值向量，并將結果記錄于權值向量組

三元方程組表示該負載均衡模型，表示具體服務器的負載情況，R表示具體網絡請求，S為選擇函數表示該服務器負載情況與分配至該服務器請求的映射關系。T表示集群對于請求的響應時間，定義G 所以具體服務器負載為：

目標函數可以定義為：

若服務器達到最佳負載狀態則該服務器性能與其對應的負載得到較完美匹配，服務器集群也同時處在一個較為理想的運行狀態。根據所定義的目標函數我們可以分析出，目標函數值越小則越接近理想狀態。對于模擬退火算法：s= 收斂時，目標函數得到最小值。

根據模擬退火算法原理，該模型的迭代過程為：

產生新解：即為解集，中的某一列即為某個權值向量的解，對現有解中元素進行部分或全部的替換，產生新解所使用的方式確定了解的結構。同時避免了了陷人局部最優解。

計算新解的目標函數：將新解帶入目標函數中，使用監測工具獲取服務器集群的平均響應時間，并計算目標函數。

接受新解：計算目標函數值與前一個目標函數值的差值，并以此確定新解是否可以被接受，根據Metropolis原則，新解的接受概率可以表示為：

其中，t表示當前溫度，也就是說集群的平均響應時間比之前更小則接受新解，反之根據公式t越高接受新解概率越大，隨著算法持續進行，t將會越來越低，所產生的解也隨之逐步收斂。

降溫：該算法每執行一次t都會逐漸減小，算法的解逐步收斂。本文所建立的模型在進行第n次迭代時，t根據公式：

確定，在此我們選擇初始溫度&=10000。

停止：為使算法在合理時間內輸出結果，根據模型的收斂速度，定義該算法在t<0.1時停止，根據我們的實驗該算法在大約迭代227次后停止，本文將算法結束后最后輸出的權值向量作為最終負載因子的權值向量。

3 測試結果分析

3.1 服務器性能測試

在進行測試時，先將需要監測的服務器ip加入sP0tlight的監聽服務器列表中，并將服務器須監測的進程列入spotlight的進程監控器中。下文將列出并發測試及負載測試時服務器資源的實時監控如圖6所示：

圖6中第二幅曲線圖即為后端服務器的cpu性能曲線，其中深藍色為配置本文所研究改進型加權最小連接數策略時后端服務器cpu性能曲線，橙色為配置最小連接數策略時后端服務器cpu性能曲線，黃色為配置加權輪循策略時cpu性能曲線，淺藍色為Nginx服務器本身cpu性能曲線。可以看出本文所研究的負載均衡策略對于后端服務器cpu資源占用情況與Nginx自帶最小連接數策略相比，曲線走勢基本一致，但cpu負載明顯降低。與加權輪

詢策略相比，雖然有時加權輪詢具有一定優勢，但大部分時間cpu使用率高于本文所研究的改進型加權最小連接數策略，且采用加權輪詢策略時cpu的性能震蕩明顯比本文所研究算法劇烈。由于加權輪詢策略算法簡潔，并不需要采集具體服務器參數，因此對cpu的壓力在部分情況下優于最小連接數以及本文所采用的改進型加權最小連接數策略，所以從cpu性能來看本文所研究算法基本達到預期結果。

以上三圖（圖7，圖8，圖9）分別為配置加權輪詢，最小連接數和本文所研究改進型加權最小連接數策略時服務器集群的帶寬及內存使用率。通過對比可以得出帶寬使用率在使用加權輪循策略時服務器內存及網絡帶寬使用率震蕩最為劇烈[17]，其次為最小連接數，本文所采用的改進算法雖然在帶寬及內存負載較小時使用率略高，但總體性能震蕩最小集群性能也最穩定。

3.2 網絡請求響應時間測試

本文選用httping作為請求響應時間的測試X具，通過事先錄制好的腳本在服務器不同負載狀況下向服務器發送請求并記錄服務器響應時間。以下三圖（圖10，圖11，圖12）分別是有五萬，十萬，十五萬工單時服務器對模擬請求的的平均響應時間。

通過服務器響應時間曲線圖可以看出，當并發連接數較少時改進型加權最小連接數算法與最小連接數算法基本相同，服務器響應時間大于加權輪詢算法，這主要是因為加權輪循算法并不涉及后端服務器日志文件的讀取，也不需要權值的計算，因此網絡開銷較小。但隨著并發連接數的增大加權輪詢與最小連接數算法的服務器響應時間趨于一致，而改進型加權最小連接數算法的服務器響應時間逐漸體現出優勢。因此可以看出改進型加權最小連接數算法隨著負載的逐漸增大服務器響應時間方面對于加權輪循與最小連接數算法的優勢也越來越明顯。

4 結束語

本文介紹了Nginx服務器架構，在加權最小連接數調度算法的基礎上提出改進型加權最小連接數算法，選擇用模擬退火算法來重新確定權值向量。利用性能檢測工具spotlight對改進型加權最小連接數，加權輪循，最小連接數三種算法從服務器資源利用率與網絡請求響應時間兩方面進行了系統的測試，詳細分析了三種算法應用在服務器集群中對于集群系統性能的影響。通過實驗對比驗證了改進型加權最小連接數算法的優勢。