基于Nginx服務(wù)器負(fù)載均衡技術(shù)的研究與改進(jìn)

張?jiān)? 許江淳 李玉惠 王志偉 史鵬坤

摘要：為了減輕快速增長(zhǎng)的網(wǎng)絡(luò)負(fù)載壓力，本文為web后端服務(wù)器集群搭建了基于Nginx的負(fù)載均衡服務(wù)器，將其作為集群的反向代理服務(wù)器，使集群具備了負(fù)載均衡的功能，對(duì)負(fù)載均衡算法進(jìn)行了分析。并針對(duì)Ngmx自帶負(fù)載均衡策略的缺陷提出了一種動(dòng)態(tài)自適應(yīng)負(fù)載均衡算法，改進(jìn)型加權(quán)最小連接數(shù)算法，同時(shí)對(duì)其算法進(jìn)行了設(shè)計(jì)。測(cè)試的實(shí)驗(yàn)結(jié)果驗(yàn)證了改進(jìn)型加權(quán)最小連接數(shù)算法的可行性。

關(guān)鍵詞：Nginx；服務(wù)器集群；均衡策略；動(dòng)態(tài)自適應(yīng)負(fù)載均衡算法

中圖分類號(hào)：TP3-05 文獻(xiàn)標(biāo)識(shí)碼：A DOI：10.3969/j.issn.1003-6970.2017.08.002

本文著錄格式：張?jiān)?，許江淳，李玉惠，等.基于服務(wù)器負(fù)載均衡技術(shù)的研究與改進(jìn)[J].軟件，2017，38（7）：06-12

隨著移動(dòng)互聯(lián)網(wǎng)的蓬勃發(fā)展，傳統(tǒng)運(yùn)營(yíng)商的主要利潤(rùn)點(diǎn)如短信及話費(fèi)的利潤(rùn)受到前所未有的沖擊。為適應(yīng)新時(shí)代的新形勢(shì)，各大運(yùn)營(yíng)商均已在網(wǎng)絡(luò)支撐方面?zhèn)鹘y(tǒng)的運(yùn)維體系已出現(xiàn)在面對(duì)大量網(wǎng)絡(luò)負(fù)荷時(shí)請(qǐng)求處理緩慢，服務(wù)器負(fù)載過重導(dǎo)致頁(yè)面無響應(yīng)等使用戶使用體驗(yàn)較差等狀況。因此各大運(yùn)營(yíng)商均將建立新一代集中運(yùn)維體系作為一個(gè)重要緩解網(wǎng)絡(luò)壓力手段。

本文針對(duì)Nginx自帶的算法不能考慮服務(wù)器集群中各個(gè)具體服務(wù)器的實(shí)時(shí)負(fù)載情況單純按照初始設(shè)定來經(jīng)行網(wǎng)絡(luò)請(qǐng)求分配的問題，對(duì)Linux操作系統(tǒng)和Nginx服務(wù)器源碼進(jìn)行分析和研究，著重對(duì)負(fù)載均衡算法進(jìn)行了優(yōu)化從而達(dá)到減少服務(wù)器響應(yīng)時(shí)間的同時(shí)提高服務(wù)器性能的穩(wěn)定性，進(jìn)而使用戶獲得更好的網(wǎng)絡(luò)服務(wù)體驗(yàn)。

1 Nginx服務(wù)器

1.1 Nginx的模塊體系

Nginx的內(nèi)部結(jié)構(gòu)是由核心部分和一系列功能檢塊組成的，這樣使得每個(gè)模塊的功能相對(duì)簡(jiǎn)單，便于對(duì)系統(tǒng)進(jìn)行功能擴(kuò)展，各模塊之間的關(guān)系如圖1所示：

標(biāo)準(zhǔn)的Nginx模塊一般可分為五大類：核心模塊，郵件服務(wù)模塊，可選Http模塊，標(biāo)準(zhǔn)Http模塊和第三方模塊。

http模塊和mail模塊分別處理http相關(guān)協(xié)議與郵件相關(guān)協(xié)議（如SMTP/IMAP/POP3等）的各類事件，同時(shí)確保這些事件能以正確的順序來調(diào)用其它相關(guān)功能模塊。

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

（2）handler模塊（phase handler），用來處理具體的用戶請(qǐng)求并同時(shí)生成待響應(yīng)內(nèi)容。

（3）filter模塊（out putfilter），用來處理像客戶端發(fā)送的響應(yīng)，通過該模塊可以對(duì)服務(wù)器向客戶端的輸出經(jīng)行修改。

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

（5）負(fù)載均衡模塊（load-balancer），該模塊內(nèi)含多種負(fù)載均衡算法，與upstream模塊同時(shí)使用，當(dāng)upstream配置文件中使用不同標(biāo)記時(shí)調(diào)用該模塊中不同算法來實(shí)現(xiàn)不同的負(fù)載均衡策略。

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

1.2 Nginx的服務(wù)器架構(gòu)

Nginx在運(yùn)行時(shí)會(huì)產(chǎn)生一個(gè)主進(jìn)程和多個(gè)工作進(jìn)程，同時(shí)也會(huì)產(chǎn)生一些cache相關(guān)進(jìn)程。工作時(shí)，客戶端發(fā)出新的網(wǎng)絡(luò)請(qǐng)求時(shí)，Ngmx服務(wù)器會(huì)與后端服務(wù)器進(jìn)行通信，根據(jù)具體的負(fù)載均衡策略Ngmx會(huì)將請(qǐng)求提交給不同的服務(wù)器，服務(wù)器接到這些請(qǐng)求時(shí)會(huì)進(jìn)行數(shù)據(jù)的處理以及相關(guān)頁(yè)面的渲染，然后將這些處理后的內(nèi)容提交給Nginx服務(wù)器，Nginx服務(wù)器再將接收到的處理結(jié)果反饋給客戶端。

當(dāng)客戶端訪問的是一些常用數(shù)據(jù)時(shí)，Ngmx服務(wù)器會(huì)根據(jù)客戶端發(fā)送的請(qǐng)求來確定客戶端所需要的具體內(nèi)容同時(shí)根據(jù)該請(qǐng)求來訪問不同的緩存服務(wù)器，緩存服務(wù)器給Nginx返回具體數(shù)據(jù)后，Nginx將緩存服務(wù)返回的數(shù)據(jù)直接反饋給客戶端以此來降低服務(wù)器的負(fù)荷，從而減少網(wǎng)絡(luò)服務(wù)的響應(yīng)時(shí)間。該模型中Nginx的主進(jìn)程，工作進(jìn)程，緩存服務(wù)器，后端服務(wù)器之間關(guān)系架構(gòu)如圖2所示：

1.3 Nginx的反向代理

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

1.4 Nginx的負(fù)載均衡

按照OSI網(wǎng)絡(luò)模型，Nginx所實(shí)現(xiàn)的負(fù)載均衡是處于第七層的Web負(fù)載均衡，適用于Web服務(wù)器集群。負(fù)載均衡策略的劃分有很多種，在此按照最常用的分類方式將Nginx的負(fù)載均衡策略劃分為兩種：內(nèi)置負(fù)載均衡策略和擴(kuò)展負(fù)載均衡策略。其中，內(nèi)置策略包括加權(quán)輪詢（Round Robin）策略，ip_hash策略和最小連接數(shù)（Least Connected）策略，默認(rèn)情況下，Nginx使用輪詢策略將網(wǎng)絡(luò)請(qǐng)求傳送到應(yīng)用服務(wù)器，不需要任何精確配置，只使用基本設(shè)置就可以進(jìn)行工作，一個(gè)精簡(jiǎn)的Nginx負(fù)載均衡配置可以如下所示：

該段配置利用upstream模塊，將本地三個(gè)端口（3000，3001，3002）中對(duì)應(yīng)的服務(wù)器程序當(dāng)作三個(gè)負(fù)載均衡資源并按照輪詢策略將這些資源自動(dòng)寫人一張輪詢列表中，當(dāng)服務(wù)器接收到客戶端請(qǐng)求時(shí)會(huì)將請(qǐng)求按照（3000，3001，3002）的順序依次分配給這三個(gè)端口對(duì)應(yīng)的服務(wù)器程序。

2 動(dòng)態(tài)自適應(yīng)負(fù)載均衡算法的設(shè)計(jì)

2.1 負(fù)載均衡算法的基本思路

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

當(dāng)全部服務(wù)器的內(nèi)存或CPU使用率高于20%時(shí)：將后端服務(wù)器的CPU占用傘，內(nèi)存占用率以及帶寬占用率作為影響因子，根據(jù)每個(gè)因子的權(quán)值向量，amem，anet計(jì)算平均負(fù)載冗余（其中n為服務(wù)器數(shù)量）：

同時(shí)計(jì)算具體每臺(tái)服務(wù)器的負(fù)載冗余值：

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

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

2.2 改進(jìn)型加權(quán)最小連接數(shù)算法

加權(quán)最小連接數(shù)調(diào)度算法是一種動(dòng)態(tài)的負(fù)載均衡算法，其思想如下：假設(shè)服務(wù)器集群用服務(wù)器集合S={S1，S2，…，Sn}（n>l）來表示，每個(gè)服務(wù)器的權(quán)值用W（Si）（l

當(dāng)服務(wù)器節(jié)點(diǎn)Si又滿足公式（4）：

根據(jù)加權(quán)最小連接數(shù)調(diào)度算法的思想，此時(shí)，只要滿足式子（4），就優(yōu)先給服務(wù)器Si分配負(fù)載。

由于服務(wù)器的當(dāng)前連接數(shù)并不能準(zhǔn)確代表服務(wù)器的實(shí)際負(fù)載量，隨著系統(tǒng)的運(yùn)行，各個(gè)服務(wù)器的處理能力和狀態(tài)會(huì)不斷地發(fā)生變化。因此，提出一種改進(jìn)型加權(quán)最小連接數(shù)算法來重新計(jì)算權(quán)值。

改進(jìn)型加權(quán)最小連接數(shù)算法是在將新的連接請(qǐng)求分配到具體服務(wù)器之前會(huì)進(jìn)行服務(wù)器負(fù)載冗余值計(jì)算，具體的計(jì)算需要提取服務(wù)器的運(yùn)行參數(shù)作為負(fù)載因子，與所對(duì)應(yīng)的權(quán)值相乘作為具體的負(fù)載冗余度。下面將介紹具體負(fù)載因子的提取方法和與之對(duì)應(yīng)的權(quán)值計(jì)算方法。

對(duì)于云平臺(tái)服務(wù)器而言，為了達(dá)到滿足負(fù)載均衡的效果，選取如下動(dòng)態(tài)負(fù)載因子作為判決條件：CPU使用率內(nèi)存使用率t/wew/，網(wǎng)絡(luò)帶寬使用率以及最小連接數(shù)算法所關(guān)注的服務(wù)器當(dāng)前請(qǐng)求中請(qǐng)求的數(shù)量num。

加權(quán)最小連接數(shù)的各個(gè)因子的權(quán)值計(jì)算：

該算法中因權(quán)值向量的選擇會(huì)直接影響到最終服務(wù)器負(fù)載冗余計(jì)算的結(jié)果，且因?yàn)橛卸鄠€(gè)權(quán)值，人為確定的值產(chǎn)生的計(jì)算結(jié)果會(huì)與實(shí)際情況產(chǎn)生偏差。

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

模擬退火算法是一種可以較好解決組合優(yōu)化問題的算法，并且最終結(jié)果與初始態(tài)無關(guān)，其結(jié)果更傾向于全局最優(yōu)解。

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

具體過程為先在服務(wù)器集群中隨機(jī)抽取一臺(tái)機(jī)器作為測(cè)試機(jī)器，暫時(shí)屏蔽其他機(jī)器，使用模擬工具模擬發(fā)送請(qǐng)求并提交給該測(cè)試服務(wù)器，同時(shí)記錄本文所選擇的三個(gè)負(fù)載因子，和服務(wù)器響應(yīng)時(shí)間。根據(jù)公式：

計(jì)算權(quán)值向量，并將結(jié)果記錄于權(quán)值向量組

三元方程組表示該負(fù)載均衡模型，表示具體服務(wù)器的負(fù)載情況，R表示具體網(wǎng)絡(luò)請(qǐng)求，S為選擇函數(shù)表示該服務(wù)器負(fù)載情況與分配至該服務(wù)器請(qǐng)求的映射關(guān)系。T表示集群對(duì)于請(qǐng)求的響應(yīng)時(shí)間，定義G 所以具體服務(wù)器負(fù)載為：

目標(biāo)函數(shù)可以定義為：

若服務(wù)器達(dá)到最佳負(fù)載狀態(tài)則該服務(wù)器性能與其對(duì)應(yīng)的負(fù)載得到較完美匹配，服務(wù)器集群也同時(shí)處在一個(gè)較為理想的運(yùn)行狀態(tài)。根據(jù)所定義的目標(biāo)函數(shù)我們可以分析出，目標(biāo)函數(shù)值越小則越接近理想狀態(tài)。對(duì)于模擬退火算法：s= 收斂時(shí)，目標(biāo)函數(shù)得到最小值。

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

產(chǎn)生新解：即為解集，中的某一列即為某個(gè)權(quán)值向量的解，對(duì)現(xiàn)有解中元素進(jìn)行部分或全部的替換，產(chǎn)生新解所使用的方式確定了解的結(jié)構(gòu)。同時(shí)避免了了陷人局部最優(yōu)解。

計(jì)算新解的目標(biāo)函數(shù)：將新解帶入目標(biāo)函數(shù)中，使用監(jiān)測(cè)工具獲取服務(wù)器集群的平均響應(yīng)時(shí)間，并計(jì)算目標(biāo)函數(shù)。

接受新解：計(jì)算目標(biāo)函數(shù)值與前一個(gè)目標(biāo)函數(shù)值的差值，并以此確定新解是否可以被接受，根據(jù)Metropolis原則，新解的接受概率可以表示為：

其中，t表示當(dāng)前溫度，也就是說集群的平均響應(yīng)時(shí)間比之前更小則接受新解，反之根據(jù)公式t越高接受新解概率越大，隨著算法持續(xù)進(jìn)行，t將會(huì)越來越低，所產(chǎn)生的解也隨之逐步收斂。

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

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

停止：為使算法在合理時(shí)間內(nèi)輸出結(jié)果，根據(jù)模型的收斂速度，定義該算法在t<0.1時(shí)停止，根據(jù)我們的實(shí)驗(yàn)該算法在大約迭代227次后停止，本文將算法結(jié)束后最后輸出的權(quán)值向量作為最終負(fù)載因子的權(quán)值向量。

3 測(cè)試結(jié)果分析

3.1 服務(wù)器性能測(cè)試

在進(jìn)行測(cè)試時(shí)，先將需要監(jiān)測(cè)的服務(wù)器ip加入sP0tlight的監(jiān)聽服務(wù)器列表中，并將服務(wù)器須監(jiān)測(cè)的進(jìn)程列入spotlight的進(jìn)程監(jiān)控器中。下文將列出并發(fā)測(cè)試及負(fù)載測(cè)試時(shí)服務(wù)器資源的實(shí)時(shí)監(jiān)控如圖6所示：

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

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

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

3.2 網(wǎng)絡(luò)請(qǐng)求響應(yīng)時(shí)間測(cè)試

本文選用httping作為請(qǐng)求響應(yīng)時(shí)間的測(cè)試X具，通過事先錄制好的腳本在服務(wù)器不同負(fù)載狀況下向服務(wù)器發(fā)送請(qǐng)求并記錄服務(wù)器響應(yīng)時(shí)間。以下三圖（圖10，圖11，圖12）分別是有五萬，十萬，十五萬工單時(shí)服務(wù)器對(duì)模擬請(qǐng)求的的平均響應(yīng)時(shí)間。

通過服務(wù)器響應(yīng)時(shí)間曲線圖可以看出，當(dāng)并發(fā)連接數(shù)較少時(shí)改進(jìn)型加權(quán)最小連接數(shù)算法與最小連接數(shù)算法基本相同，服務(wù)器響應(yīng)時(shí)間大于加權(quán)輪詢算法，這主要是因?yàn)榧訖?quán)輪循算法并不涉及后端服務(wù)器日志文件的讀取，也不需要權(quán)值的計(jì)算，因此網(wǎng)絡(luò)開銷較小。但隨著并發(fā)連接數(shù)的增大加權(quán)輪詢與最小連接數(shù)算法的服務(wù)器響應(yīng)時(shí)間趨于一致，而改進(jìn)型加權(quán)最小連接數(shù)算法的服務(wù)器響應(yīng)時(shí)間逐漸體現(xiàn)出優(yōu)勢(shì)。因此可以看出改進(jìn)型加權(quán)最小連接數(shù)算法隨著負(fù)載的逐漸增大服務(wù)器響應(yīng)時(shí)間方面對(duì)于加權(quán)輪循與最小連接數(shù)算法的優(yōu)勢(shì)也越來越明顯。

4 結(jié)束語(yǔ)

本文介紹了Nginx服務(wù)器架構(gòu)，在加權(quán)最小連接數(shù)調(diào)度算法的基礎(chǔ)上提出改進(jìn)型加權(quán)最小連接數(shù)算法，選擇用模擬退火算法來重新確定權(quán)值向量。利用性能檢測(cè)工具spotlight對(duì)改進(jìn)型加權(quán)最小連接數(shù)，加權(quán)輪循，最小連接數(shù)三種算法從服務(wù)器資源利用率與網(wǎng)絡(luò)請(qǐng)求響應(yīng)時(shí)間兩方面進(jìn)行了系統(tǒng)的測(cè)試，詳細(xì)分析了三種算法應(yīng)用在服務(wù)器集群中對(duì)于集群系統(tǒng)性能的影響。通過實(shí)驗(yàn)對(duì)比驗(yàn)證了改進(jìn)型加權(quán)最小連接數(shù)算法的優(yōu)勢(shì)。