本發(fā)明涉及計算機網(wǎng)絡(luò)通信領(lǐng)域，特別涉及一種NGINX服務(wù)器負載均衡的實現(xiàn)方法及系統(tǒng)。

背景技術(shù)：

服務(wù)器集群的出現(xiàn)解決了海量Web并發(fā)訪問問題。然而現(xiàn)實應(yīng)用中，服務(wù)器集群往往出現(xiàn)負載不均衡的問題：一部分服務(wù)器高負載運行，而另一部分服務(wù)器卻處于空閑。

NINGX服務(wù)器作為一種高性能的負載均衡服務(wù)器在服務(wù)器集群中有著廣泛的應(yīng)用。其實現(xiàn)負載均衡的主要方法是輪詢法，即均勻地選擇后端服務(wù)器處理請求。而對于服務(wù)器性能有差異的情況，則可采用加權(quán)輪詢的方法，使得分配服務(wù)器的比率與其權(quán)值成正比。由于請求的業(yè)務(wù)內(nèi)容不同，對服務(wù)器資源的需求也不一樣，考慮請求的業(yè)務(wù)類型，現(xiàn)有的負載均衡方法是一組服務(wù)器處理對應(yīng)的一類業(yè)務(wù)。但是，當(dāng)某類業(yè)務(wù)請求較多時，會造成對應(yīng)的一組服務(wù)器處于高負載，而其他組的服務(wù)器則處于空閑狀態(tài)。

技術(shù)實現(xiàn)要素：

有鑒于此，本發(fā)明的目的在于提供一種NGINX服務(wù)器負載均衡的實現(xiàn)方法及系統(tǒng)，通過觸發(fā)式的機制動態(tài)地監(jiān)測后端服務(wù)器的負載狀態(tài)，結(jié)合業(yè)務(wù)類型來判斷服務(wù)器處理各類業(yè)務(wù)的能力，根據(jù)服務(wù)器當(dāng)前的負載狀態(tài)和業(yè)務(wù)處理能力，合理地選擇后端服務(wù)器處理請求，以到達負載均衡的目的。

為達到上述目的，本發(fā)明提供如下技術(shù)方案：

一種NGINX服務(wù)器負載均衡的實現(xiàn)方法，該方法包括以下步驟：

NGINX服務(wù)器通過觸發(fā)式機制更新后端服務(wù)器集群的資源信息；所述資源信息包括服務(wù)器的CPU利用率、內(nèi)存利用率、磁盤I/O利用率及網(wǎng)絡(luò)帶寬利用率；

所述NGINX服務(wù)器接收到客戶端的HTTP請求后，采用負載均衡算法選擇后端服務(wù)器處理該HTTP請求，并將服務(wù)器處理結(jié)果返回給客戶端；

所述負載均衡算法為根據(jù)不同的業(yè)務(wù)類型及后端服務(wù)器集群的資源信息，計算后端服務(wù)器在各種業(yè)務(wù)類型下的負載值，選擇該HTTP請求所屬的業(yè)務(wù)類型中負載值最小的后端服務(wù)器處理該HTTP請求。

進一步，所述負載均衡算法具體包括以下步驟：

根據(jù)各種業(yè)務(wù)類型對后端服務(wù)器的CPU利用率、內(nèi)存利用率、磁盤I/O利用率及網(wǎng)絡(luò)帶寬利用率等資源信息配置不同的權(quán)值；

計算所述后端服務(wù)器在各種業(yè)務(wù)類型中的負載均衡因子，所述負載均衡因子用于反映后端服務(wù)器S_i在業(yè)務(wù)類型_j中負載情況；

選擇HTTP請求所屬的業(yè)務(wù)類型中負載均衡因子最小的后端服務(wù)器處理該HTTP請求。

進一步，所述NGINX服務(wù)器通過觸發(fā)式機制更新后端服務(wù)器集群的資源信息，通過以下方式實現(xiàn)：

所述NGINX服務(wù)器向后端服務(wù)器分配請求任務(wù)后，所述NGINX服務(wù)器主動發(fā)送獲取資源信息的請求，后端服務(wù)器響應(yīng)該請求，NGINX服務(wù)器更新該后端服務(wù)器的資源信息和負載狀況。

進一步，所述NGINX服務(wù)器通過觸發(fā)式機制更新后端服務(wù)器集群的資源信息，通過以下方式實現(xiàn)：

所述后端服務(wù)器完成某請求任務(wù)后，向NGINX服務(wù)器發(fā)送當(dāng)前的后端服務(wù)器的資源信息，NGINX服務(wù)器更新該后端服務(wù)器的資源信息和負載狀況。

進一步，所述業(yè)務(wù)類型包括計算密集型、多媒體處理型、內(nèi)容傳輸型和數(shù)據(jù)庫訪問型。

一種NGINX服務(wù)器負載均衡系統(tǒng)，包括客戶端、NGINX服務(wù)器、后端服務(wù)器集群；

所述客戶端用于向服務(wù)器發(fā)出HTTP請求，所述HTTP請求經(jīng)過負責(zé)負載均衡的NGINX服務(wù)器，再轉(zhuǎn)發(fā)到后端的服務(wù)器集群；

所述NGINX服務(wù)器用于接收客戶端的HTTP請求，分析請求URL的業(yè)務(wù)類型，然后根據(jù)業(yè)務(wù)類型和后端服務(wù)器集群資源信息，采用負載均衡算法選擇后端服務(wù)器處理該HTTP請求，并將后端服務(wù)器處理結(jié)果返回給客戶端；

所述后端服務(wù)器集群為性能各異的服務(wù)器，用于處理NGINX服務(wù)器分配的請求，并將處理結(jié)果返回給NGINX服務(wù)器；同時，動態(tài)地向NGINX服務(wù)器反饋自身資源信息。

進一步，所述NGINX服務(wù)器包括URL分析模塊、資源信息采集模塊、調(diào)度算法模塊；

所述URL分析模塊用于根據(jù)請求URL，分析HTTP請求的業(yè)務(wù)類型，：所述業(yè)務(wù)類型包括計算密集型、多媒體處理型、內(nèi)容傳輸型和數(shù)據(jù)庫訪問型；

所述資源信息采集模塊用于動態(tài)地獲取后端服務(wù)器集群的資源信息并予以保存；

所述調(diào)度算法模塊用于根據(jù)當(dāng)前HTTP請求的業(yè)務(wù)類型及后端服務(wù)器集群的資源信息，選擇后端服務(wù)器處理該HTTP請求。

進一步，所述資源信息采集模塊采用權(quán)利要求3或4所述的方法獲取后端服務(wù)器集群的資源信息并予以保存。

進一步，所述調(diào)度算法模塊采用負載均衡算法選擇后端服務(wù)器處理該HTTP請求，然后將服務(wù)器處理結(jié)果返回給客戶端；

所述負載均衡算法為根據(jù)不同的業(yè)務(wù)類型及后端服務(wù)器集群的資源信息，計算后端服務(wù)器在各種業(yè)務(wù)類型下的負載值，選擇該HTTP請求所屬的業(yè)務(wù)類型中負載值最小的后端服務(wù)器處理該HTTP請求。

本發(fā)明的有益效果在于：本發(fā)明提供的一種NGINX服務(wù)器負載均衡的實現(xiàn)方法及系統(tǒng)，通過觸發(fā)式的機制動態(tài)地監(jiān)測后端服務(wù)器的實時資源信息，并采用負載均衡算法結(jié)合業(yè)務(wù)類型及后端服務(wù)器的負載狀態(tài)合理地選擇后端服務(wù)器處理請求，以到達負載均衡的目的。與現(xiàn)有技術(shù)相比具有以下優(yōu)勢：

1.采用負載均衡算法合理地選擇后端服務(wù)器，適用于后端服務(wù)器性能不同的業(yè)務(wù)系統(tǒng)，而無須事先給各服務(wù)器分配權(quán)值。

2.后端服務(wù)器無須為按業(yè)務(wù)類型分類，避免了服務(wù)器只處理某類型業(yè)務(wù)造成的負載不均衡。

3.通過觸發(fā)式機制更新各后端服務(wù)器資源信息，避免了周期性收集時，周期過長信息更新不及時和周期過短增加負荷等問題。

附圖說明

為了使本發(fā)明的目的、技術(shù)方案和有益效果更加清楚，本發(fā)明提供如下附圖進行說明：

圖1為本發(fā)明所述服務(wù)器負載均衡系統(tǒng)組織結(jié)構(gòu)圖；

圖2為本發(fā)明所述方法的流程圖。

具體實施方式

下面將結(jié)合附圖，對本發(fā)明的優(yōu)選實施例進行詳細的描述。

本發(fā)明提供的一種NGINX服務(wù)器負載均衡系統(tǒng)，如圖1所示，主要包括客戶端、NGINX服務(wù)器和后端服務(wù)器集群。

客戶端：用戶通過終端設(shè)備，向服務(wù)器發(fā)出各種HTTP請求，該請求會先經(jīng)過負責(zé)負載均衡的NGINX服務(wù)器，再轉(zhuǎn)發(fā)到后端的服務(wù)器集群。

NGINX服務(wù)器：負責(zé)接收客戶端的HTTP請求，首先分析請求URL的業(yè)務(wù)類型，然后根據(jù)業(yè)務(wù)類型和動態(tài)收集的后端服務(wù)器集群資源信息，采用負載均衡算法選擇合理的后端服務(wù)器處理該HTTP請求，最后將服務(wù)器處理結(jié)果返回給客戶端。

后端服務(wù)器集群：由性能各異的服務(wù)器組成，負責(zé)處理NGINX服務(wù)器分配的請求，并將處理結(jié)果返回給NGINX服務(wù)器。同時，動態(tài)地向NGINX服務(wù)器反饋自身負載情況。

其中，NGINX服務(wù)器為負載均衡系統(tǒng)最核心的部分，NGINX服務(wù)器主要包括URL分析模塊、資源信息采集模塊、調(diào)度算法模塊。

URL分析模塊：該模塊用于根據(jù)請求URL，分析HTTP請求的業(yè)務(wù)類型。常見的業(yè)務(wù)類型包括計算密集型、多媒體處理型、內(nèi)容傳輸型和數(shù)據(jù)庫訪問型；不同類型的業(yè)務(wù)對服務(wù)器資源信息的需求也不一樣。

計算密集型：如電子商務(wù)類的Web業(yè)務(wù)請求，由于安全通信的需求，涉及大量的加解密操作，需要消耗大量的CPU。

多媒體處理型：如需要服務(wù)器提高音頻和視頻的流媒體服務(wù)，需要占用服務(wù)器大量的內(nèi)存和CPU資源。

內(nèi)容傳輸型：如大文件的傳輸請求，對服務(wù)器的帶寬要求較高。

數(shù)據(jù)庫訪問型：該類型的業(yè)務(wù)來自用戶的數(shù)據(jù)庫動態(tài)查詢，需要服務(wù)器密集的磁盤訪問，對磁盤I/O資源要求比較高。

資源信息采集模塊：主要用于通過觸發(fā)式機制動態(tài)地采集后端服務(wù)器集群的資源信息，以及對服務(wù)器處理能力的動態(tài)預(yù)測。資源信息包括服務(wù)器的CPU利用率、內(nèi)存利用率、磁盤I/O利用率及網(wǎng)絡(luò)帶寬利用率。

區(qū)別于現(xiàn)有技術(shù)中的周期性采集方法，本模塊采用了動態(tài)觸發(fā)式的資源信息采集方法。該方法包括了兩種資源信息更新機制：

主動更新：當(dāng)NGINX服務(wù)器向后端服務(wù)器分配請求任務(wù)后，NGINX服務(wù)器發(fā)送獲取資源信息的請求，后端服務(wù)器響應(yīng)該請求，NGINX服務(wù)器主動更新該后端服務(wù)器的資源信息和負載狀況，并據(jù)此更新該后端服務(wù)器處理能力。

被動更新：當(dāng)后端服務(wù)器完成某請求任務(wù)后，向NGINX服務(wù)器發(fā)送當(dāng)前的服務(wù)器資源信息，NGINX服務(wù)器接收到該信息后，資源信息采集模塊更新該后端服務(wù)器的資源信息和負載狀況，并據(jù)此更新該后端服務(wù)器處理能力。

具體而言，資源信息采集模塊的主要工作如下：

服務(wù)器負載均衡系統(tǒng)中包括N臺服務(wù)器，用符號i(1≤i≤N)標(biāo)記，則該NGINX服務(wù)器的后端服務(wù)器集群可表示為S＝[S₁,S₂,…,S_N]。

請求的業(yè)務(wù)類型總數(shù)為n,可表示j,1≤j≤n。

資源信息分別表示t時刻，服務(wù)器S_i的CPU，內(nèi)存，磁盤I/O以及網(wǎng)絡(luò)帶寬的利用率，且時，表示t時刻,服務(wù)器S_i的某項資源利用率達到100％，已無可用資源；時，表示t時刻,服務(wù)器S_i的某項資源利用率為0，該項資源完全可用。

表示第j類業(yè)務(wù)對服務(wù)器S_i各項資源的平均需求，用該服務(wù)器的資源利用率刻畫，如表示該項業(yè)務(wù)平均需占用服務(wù)器S_i內(nèi)存50％的資源。

假設(shè)t時刻，服務(wù)器S_i的資源信息為R_i(t),

(1)主動更新后，即服務(wù)器S_i的資源信息為R_i(t+Δt)，則該服務(wù)器的資源利用率變化為

根據(jù)分配的業(yè)務(wù)類型，按如下方式更新

如果(初始值)，

否則，

(2)被動更新后，服務(wù)器S_i的資源信息為R_i(t+Δt)，則該服務(wù)器的資源利用率變化為

類似地，根據(jù)主動更新時的規(guī)則更新

調(diào)度算法模塊：該模塊負責(zé)根據(jù)當(dāng)前的HTTP請求的業(yè)務(wù)類型和后端服務(wù)器資源信息，采用負載均衡算法選擇后端服務(wù)器處理該HTTP請求。

用戶可根據(jù)各種業(yè)務(wù)類型對系統(tǒng)的CPU，內(nèi)存，磁盤I/O以及網(wǎng)絡(luò)帶寬等資源配置不同的權(quán)值

在本方法中，對于給定的服務(wù)器S_i，業(yè)務(wù)類型j和當(dāng)前的定義如下負載均衡因子：

則對于服務(wù)器集群S，從小到大構(gòu)成如下隊列：

對于n種業(yè)務(wù)類型的系統(tǒng)，該模塊則需要負責(zé)維持Q₁,Q₂,…,Q_n，n個隊列。由于n的值比較小，因此不會給NGINX服務(wù)器帶來很大的負擔(dān)。

當(dāng)新的請求到來時，NGINX服務(wù)器根據(jù)請求的業(yè)務(wù)類型，選擇位于對應(yīng)的隊列最前端的服務(wù)器處理該請求。

當(dāng)NGINX服務(wù)器分配給服務(wù)器S_i一個j類型的業(yè)務(wù)請求或者后端服務(wù)器S_i處理完一個j類型的業(yè)務(wù)請求后，調(diào)度算法模塊將最新的資源信息，更新值，并采用插值法更新其在隊列Q_j中的位置。

在具體實施例中，如圖2所示，本發(fā)明所提供的一種NGINX服務(wù)器負載均衡的實現(xiàn)方法，具體包括以下步驟：

S1：客戶端發(fā)送HTTP請求；

S2：NIGINX服務(wù)器接收該請求，并通過URL分析模塊分析該HTTP請請求的業(yè)務(wù)類型；

S3：調(diào)度算法模塊選擇對應(yīng)業(yè)務(wù)類型隊列的最前端服務(wù)器，即處理對應(yīng)業(yè)務(wù)類型中負載最小的后端服務(wù)器，并將該請求發(fā)送給該服務(wù)器。

S4：服務(wù)器處理該請求。

S5：觸發(fā)資源信息主動更新機制，資源信息采集模塊向該服務(wù)器發(fā)送獲取資源信息的請求。

S6：服務(wù)器接收到獲取資源信息的請求后，在規(guī)定時間內(nèi)，調(diào)用操作系統(tǒng)的接口，獲取本機的CPU、內(nèi)存、磁盤I/O和網(wǎng)絡(luò)帶寬的利用率情況，并將結(jié)果反饋給NGINX的資源信息采集模塊。

S7：資源信息采集模塊更新服務(wù)器的負載信息及該項業(yè)務(wù)對該服務(wù)器性能需求，并將更新后的信息發(fā)送給調(diào)度算法模塊。

S8：調(diào)度算法模塊重新計算該服務(wù)器的負載因子，并更新所有隊列，等待下一請求。

S9：服務(wù)器完成該請求，將處理的結(jié)果返回NGINX服務(wù)器。

S10：服務(wù)器獲取完成請求后本機的CPU、內(nèi)存、磁盤I/O和網(wǎng)絡(luò)帶寬的利用率情況，并將結(jié)果發(fā)送給NGINX的資源信息采集模塊。

S11：NGINX服務(wù)器將處理結(jié)果返回給客戶端。

S12：資源信息采集模塊更新服務(wù)器的負載信息及該項業(yè)務(wù)對該服務(wù)器性能需求，并將更新后的信息發(fā)送給調(diào)度算法模塊。

S13：調(diào)度算法模塊重新計算該服務(wù)器的負載因子，并更新所有隊列，等待下一請求。

最后說明的是，以上優(yōu)選實施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管通過上述優(yōu)選實施例已經(jīng)對本發(fā)明進行了詳細的描述，但本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解，可以在形式上和細節(jié)上對其作出各種各樣的改變，而不偏離本發(fā)明權(quán)利要求書所限定的范圍。