本發(fā)明涉及服務(wù)器處理技術(shù)領(lǐng)域，尤其涉及一種基于nginx服務(wù)器的動態(tài)配置管理方法及系統(tǒng)。

背景技術(shù)：

nginx是一種高性能的http(hypertexttransferprotocol，超文本傳輸協(xié)議)和反向代理服務(wù)器，是業(yè)界常用的負載均衡軟件，通過負載均衡策略給后端服務(wù)器分發(fā)請求。

當(dāng)有不同nginx集群，業(yè)務(wù)增多和時常的變動，nginx配置文件也日益龐大，對nginx的管理顯得日益復(fù)雜。因此，如何對不同的nginx集群進行統(tǒng)一的管理是一項亟待解決的問題。

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

本發(fā)明提供了一種基于nginx服務(wù)器的動態(tài)配置管理方法，能夠有效的對不同的nginx集群進行統(tǒng)一的管理。

本發(fā)明提供了一種基于nginx服務(wù)器的動態(tài)配置管理方法，包括：

通過web交互界面加入上游服務(wù)器信息，并將所述上游服務(wù)器信息存放至數(shù)據(jù)中心；

nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；

對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；

基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；

基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；

基于所述nginx服務(wù)器將日志寫入消息隊列進行管理。

優(yōu)選地，所述基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理包括：

通過查詢實時獲取上游服務(wù)器的狀態(tài)信息；

根據(jù)業(yè)務(wù)需要動態(tài)的調(diào)整服務(wù)器狀態(tài)；

根據(jù)具體業(yè)務(wù)動態(tài)的添加和/或刪減服務(wù)器。

優(yōu)選地，所述基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理還包括：

每間隔n分鐘，通過從開源的非關(guān)系型分布式數(shù)據(jù)庫中獲取預(yù)設(shè)時間段的歷史數(shù)據(jù)；

基于所述歷史數(shù)據(jù)增加服務(wù)器、刪減服務(wù)器或替換服務(wù)器。

優(yōu)選地，所述基于所述歷史數(shù)據(jù)增加服務(wù)器包括：

判斷所述預(yù)設(shè)時間段的平均每秒查詢率是否超過預(yù)設(shè)閾值；

當(dāng)所述預(yù)設(shè)時間段的平均每秒查詢率超過預(yù)設(shè)閾值時，添加n個服務(wù)器。

優(yōu)選地，所述基于所述歷史數(shù)據(jù)刪減服務(wù)器包括：

判斷上游服務(wù)器是否增加過服務(wù)器；

當(dāng)上游服務(wù)器增加過服務(wù)器時，判斷所述預(yù)設(shè)時間段的平均每秒查詢率是否小于所述預(yù)設(shè)閾值；

當(dāng)述預(yù)設(shè)時間段的平均每秒查詢率小于所述預(yù)設(shè)閾值時，將所述上游服務(wù)器中新添加的n個服務(wù)器刪除。

優(yōu)選地，所述基于所述歷史數(shù)據(jù)替換服務(wù)器包括：

判斷所述上游服務(wù)器中的健康狀態(tài)是否為up，若否，則采用備用服務(wù)器替換該服務(wù)器，若是，則：

根據(jù)所述預(yù)設(shè)時間段的平均響應(yīng)時間、超文本傳輸協(xié)議狀態(tài)信息判斷是否替換該服務(wù)器。

一種基于nginx服務(wù)器的動態(tài)配置管理系統(tǒng)，包括：

信息管理模塊，用于通過web交互界面加入上游服務(wù)器信息，并將所述上游服務(wù)器信息存放至數(shù)據(jù)中心；

路由管理模塊，用于nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；

流量監(jiān)控模塊，用于對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；

動態(tài)管理模塊，用于基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；

健康監(jiān)測模塊，用于基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；

日志管理模塊，用于基于所述nginx服務(wù)器將日志寫入消息隊列進行管理。

優(yōu)選地，所述動態(tài)管理模塊具體用于：

通過查詢實時獲取上游服務(wù)器的狀態(tài)信息；

根據(jù)業(yè)務(wù)需要動態(tài)的調(diào)整服務(wù)器狀態(tài)；

根據(jù)具體業(yè)務(wù)動態(tài)的添加和/或刪減服務(wù)器。

優(yōu)選地，所述動態(tài)管理模塊具體用于：

每間隔n分鐘，通過從開源的非關(guān)系型分布式數(shù)據(jù)庫中獲取預(yù)設(shè)時間段的歷史數(shù)據(jù)；

基于所述歷史數(shù)據(jù)增加服務(wù)器、刪減服務(wù)器或替換服務(wù)器。

優(yōu)選地，所述動態(tài)管理模塊具體用于：

判斷所述預(yù)設(shè)時間段的平均每秒查詢率是否超過預(yù)設(shè)閾值；

當(dāng)所述預(yù)設(shè)時間段的平均每秒查詢率超過預(yù)設(shè)閾值時，添加n個服務(wù)器。

優(yōu)選地，所述動態(tài)管理模塊具體用于：

判斷上游服務(wù)器是否增加過服務(wù)器；

當(dāng)上游服務(wù)器增加過服務(wù)器時，判斷所述預(yù)設(shè)時間段的平均每秒查詢率是否小于所述預(yù)設(shè)閾值；

當(dāng)述預(yù)設(shè)時間段的平均每秒查詢率小于所述預(yù)設(shè)閾值時，將所述上游服務(wù)器中新添加的n個服務(wù)器刪除。

優(yōu)選地，所述動態(tài)管理模塊具體用于：

判斷所述上游服務(wù)器中的健康狀態(tài)是否為up，若否，則采用備用服務(wù)器替換該服務(wù)器，若是，則：

根據(jù)所述預(yù)設(shè)時間段的平均響應(yīng)時間、超文本傳輸協(xié)議狀態(tài)信息判斷是否替換該服務(wù)器。

由上述方案可知，本發(fā)明提供的一種基于nginx服務(wù)器的動態(tài)配置管理方法，包括：通過web交互界面加入上游服務(wù)器信息，并將所述上游服務(wù)器信息存放至數(shù)據(jù)中心；nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；基于所述nginx服務(wù)器將日志寫入消息隊列進行管理，能夠有效的對不同的nginx集群進行統(tǒng)一的管理。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明公開的一種基于nginx服務(wù)器的動態(tài)配置管理方法實施例1的方法流程圖；

圖2為本發(fā)明公開的一種基于nginx服務(wù)器的動態(tài)配置管理系統(tǒng)實施例1的結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

為了更加特定地強調(diào)實施的獨立性，本說明書涉及許多模塊或單元。舉例而言，模塊或單元可由硬件電路實現(xiàn)，該硬件電路包括特制vlsi電路或門陣列，比如邏輯芯片、晶體管，或其它組件。模塊或單元也可在可編程的硬設(shè)備中實現(xiàn)，比如場效可編程門陣列、可編程陣列邏輯、可編程邏輯設(shè)備等等。

模塊或單元也可在藉由各種形式的處理器所執(zhí)行的軟件中實現(xiàn)。比如說，一可執(zhí)行碼模塊可包括一個或多個實體的或邏輯的計算機指令區(qū)塊，該區(qū)塊可能形成為，比如說，對象、程序或函數(shù)。然而，鑒別模塊或單元的可執(zhí)行部分不需要物理上放置在一起，但可由存于不同位置的不同指令所組成，當(dāng)邏輯上組合在一起時，形成模塊或單元且達到該模塊或單元所要求的目的。

實際上，可執(zhí)行碼模塊或單元可以是一單一指令或多個指令，甚至可以分布在位于不同的程序中的數(shù)個不同的碼區(qū)段，并且橫跨數(shù)個存儲設(shè)備。同樣地，操作數(shù)據(jù)可被辨識及顯示于此模塊或單元中，并且可以以任何合適的形式實施且在任何合適的數(shù)據(jù)結(jié)構(gòu)形式內(nèi)組織。操作數(shù)據(jù)可以集合成單一數(shù)據(jù)集，或可分布在具有不同的存儲設(shè)備的不同的位置，且至少部分地只以電子信號方式存在于一系統(tǒng)或網(wǎng)絡(luò)。

本說明書所提及的“實施例”或類似用語表示與實施例有關(guān)的特性、結(jié)構(gòu)或特征，包括在本發(fā)明的至少一實施例中。因此，本說明書所出現(xiàn)的用語“在一實施例中”、“在實施例中”以及類似用語可能但不必然都指向相同實施例。

再者，本發(fā)明所述特性、結(jié)構(gòu)或特征可以以任何方式結(jié)合在一個或多個實施例中。以下說明將提供許多特定的細節(jié)，比如編程序、軟件模塊、用戶選擇、網(wǎng)絡(luò)交易、數(shù)據(jù)庫查詢、數(shù)據(jù)庫結(jié)構(gòu)、硬件模塊、硬件電路、硬件芯片等例子，以提供對本發(fā)明實施例的了解。然而相關(guān)領(lǐng)域的普通技術(shù)人員將看出本發(fā)明，即使沒有利用其中一個或多個特定細節(jié)，或利用其它方法、組件、材料等亦可實施。另一方面，為避免混淆本發(fā)明，公知的結(jié)構(gòu)、材料或操作并沒有詳細描述。

如圖1所示，為本發(fā)明公開的一種于nginx服務(wù)器的動態(tài)配置管理方法實施例1的方法流程圖，該方法包括：

s101、通過web交互界面加入上游服務(wù)器信息，并將上游服務(wù)器信息存放至數(shù)據(jù)中心；

上游服務(wù)器信息通過網(wǎng)站服務(wù)器加入，并存放在數(shù)據(jù)中心，例如存放在consul中，其中consul為一個支持多數(shù)據(jù)中心分布式高可用的服務(wù)發(fā)現(xiàn)和配置共享的服務(wù)軟件。

nginx服務(wù)器啟動時，先從consul中加載上游服務(wù)器信息到nginx服務(wù)器內(nèi)存中。在線上環(huán)境中，將超文本傳輸寫請求統(tǒng)一資源標識符設(shè)置為key。

s102、nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；

nginx服務(wù)器通過超文本傳輸協(xié)議請求的統(tǒng)一資源標識符進行路由轉(zhuǎn)發(fā)。nginx服務(wù)器收到請求時，首先獲取該請求的統(tǒng)一資源標識符，根據(jù)統(tǒng)一資源標識符進行找到對應(yīng)的上游服務(wù)器信息，并根據(jù)上游服務(wù)器預(yù)先設(shè)定的負載均衡策略(即上游服務(wù)器信息中mode代表的值)進行轉(zhuǎn)發(fā)，本方案兼容nginx服務(wù)器原有的輪詢、ip_hash、url_hash等負載均衡算法。

s103、對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；

對每一個上游服務(wù)器中的服務(wù)器進行監(jiān)控，被監(jiān)控信息包括：請求的傳輸控制協(xié)議連接的信息：每秒查詢率、處理請求的平均時間、發(fā)送給客戶端的數(shù)據(jù)大小、超文本傳輸協(xié)議狀態(tài)1xx到5xx回應(yīng)報文等信息的監(jiān)控和統(tǒng)計。上游服務(wù)器的每秒查詢率、nginx服務(wù)器和上游服務(wù)器建立連接的時間(connect_time)、上游服務(wù)器響應(yīng)時間；對上游服務(wù)器的狀態(tài)進行實時監(jiān)控。

s104、基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；

為了方便開發(fā)和運維人員對上游服務(wù)器的管理，本方案在nginx服務(wù)器中提供了超文本傳輸協(xié)議接口，以便對上游服務(wù)器進行實時動態(tài)管理。避免手動修改nginx服務(wù)器配置文件、以及重啟nginx服務(wù)器。

所有的操作可以通過web交互界面進行操作，通過web交互界面修改consul中上游服務(wù)器中的信息，利用consul提供的watch機制，將修改的上游服務(wù)器信息發(fā)送給對應(yīng)nginx服務(wù)器集群，nginx服務(wù)器會在syn_interval分鐘生效，避免了重啟nginx服務(wù)器帶來的性能損失。

對上游服務(wù)器的管理主要分為手動操作和基于流量監(jiān)控數(shù)據(jù)的動態(tài)操作。

s105、基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；

在nginx服務(wù)器啟動一個任務(wù)、定時的向后端的服務(wù)器發(fā)送心跳包，根據(jù)返回結(jié)果，例如：狀態(tài)碼，返回內(nèi)容，判斷后端服務(wù)器服務(wù)的健康狀態(tài)，若判斷服務(wù)器處于非健康狀態(tài)，該任務(wù)在nginx服務(wù)器內(nèi)部將該服務(wù)器標記為down。在本方案里，每一個請求，會根據(jù)特定的負載均衡算法選擇后端服務(wù)器，在轉(zhuǎn)發(fā)前，先判斷服務(wù)器的健康狀態(tài)，若服務(wù)器狀態(tài)為up，即服務(wù)器的狀態(tài)為健康則轉(zhuǎn)發(fā)。

s106、基于所述nginx服務(wù)器將日志寫入消息隊列進行管理。

nginx服務(wù)器是將日志直接輸出到本地的磁盤上，然后通過flume、logstash等工具進行采集。flume是cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)；flume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，flume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方(可定制)的能力。本方案利用lua模塊，將日志按照一定的格式拼接后寫入消息隊列，例如開源分布式消息系統(tǒng)，storm、hdfs、es等，(storm是一個分布式的，可靠的，容錯的數(shù)據(jù)流處理系統(tǒng)，hdfs是hadoop分布式文件系統(tǒng)，es即elasticsearch是一個開源的分布式搜索引擎，具備高可靠性，支持非常多的企業(yè)級搜索用例)進行使用，關(guān)閉nginx服務(wù)器本身的日志開關(guān)，減少磁盤消耗。減少對采集組件的運維工作。

綜上所述，在上述實施例中，通過web交互界面加入上游服務(wù)器信息，并將所述上游服務(wù)器信息存放至數(shù)據(jù)中心；nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；基于所述nginx服務(wù)器將日志寫入消息隊列進行管理，能夠有效的對不同的nginx集群進行統(tǒng)一的管理。

具體的，在上述實施例中，步驟s104中基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理的具體實現(xiàn)方式可以為：

第一，對上游服務(wù)器的手動操作，主要有以下幾個方面：

a、查詢，可以實時獲取上游服務(wù)器的狀態(tài)信息；

b、修改狀態(tài)，可以根據(jù)業(yè)務(wù)需要動態(tài)的調(diào)整服務(wù)器的狀態(tài)，例如將服務(wù)器設(shè)置為up或者down，免手動修改配置文件；

c、添加/刪減服務(wù)器，可以根據(jù)具體業(yè)務(wù)動態(tài)的添加和刪減服務(wù)器。

第二，基于流量監(jiān)控數(shù)據(jù)的動態(tài)操作：

每隔n分鐘，通過從開源的非關(guān)系型分布式數(shù)據(jù)庫中獲取[now_ts–interval,now_ts]時間段的歷史數(shù)據(jù)，根據(jù)歷史數(shù)據(jù)做以下幾個方面的操作：

a、增加服務(wù)器

判斷[now_ts–interval,now_ts]時間段的平均每秒查詢率即qps_mean是否超過該upstream的閾值qps_threshold，(qps_threshold＝qps_singal_server*upstream_n)其中qps_singal為單個se服務(wù)器承受的每秒查詢率，upstream_n為上游服務(wù)器預(yù)設(shè)的服務(wù)器個數(shù))，若超過，則添加add_n個服務(wù)器，其中

b、刪減服務(wù)器

判斷上游服務(wù)器是否增加過服務(wù)器，若是，則計算[now_ts–interval,now_ts]時間段的平均每秒查詢率即qps_mean，

若qps_mean＜qps_threahold,則將上游服務(wù)器中新添加的add_n個服務(wù)器刪除；

若qps_threshold<qps_mean<qps_singal*(upstream_n+add_n),刪減del_n個服務(wù)器，其中

c、替換服務(wù)器

第一步：判斷上游服務(wù)器中服務(wù)器的健康狀態(tài)是否為up，若是轉(zhuǎn)第二步，否則將該服務(wù)器用其他備用服務(wù)器進行替換；

第二步：根據(jù)[now_ts–interval,now_ts]時間段的平均響應(yīng)時間、超文本傳輸協(xié)議狀態(tài)等信息判斷是否將服務(wù)器進行替換，具體的判斷依據(jù)需要和具體的業(yè)務(wù)進行定制。

如圖2所示，為本發(fā)明公開的一種于nginx服務(wù)器的動態(tài)配置管理系統(tǒng)實施例1的結(jié)構(gòu)示意圖，該系統(tǒng)包括：

信息管理模塊201，用于通過web交互界面加入上游服務(wù)器信息，并將上游服務(wù)器信息存放至數(shù)據(jù)中心；

上游服務(wù)器信息通過web交互界面加入，并存放在數(shù)據(jù)中心，例如存放在consul中，其中consul為一個支持多數(shù)據(jù)中心分布式高可用的服務(wù)發(fā)現(xiàn)和配置共享的服務(wù)軟件。

nginx服務(wù)器啟動時，先從consul中加載上游服務(wù)器信息到nginx服務(wù)器內(nèi)存中。在線上環(huán)境中，將超文本傳輸寫請求統(tǒng)一資源標識符設(shè)置為key。

路由管理模塊202，用于nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；

nginx服務(wù)器通過超文本傳輸協(xié)議請求的統(tǒng)一資源標識符進行路由轉(zhuǎn)發(fā)。nginx服務(wù)器收到請求時，首先獲取該請求的統(tǒng)一資源標識符，根據(jù)統(tǒng)一資源標識符進行找到對應(yīng)的上游服務(wù)器信息，并根據(jù)上游服務(wù)器預(yù)先設(shè)定的負載均衡策略(即上游服務(wù)器信息中mode代表的值)進行轉(zhuǎn)發(fā)，本方案兼容nginx服務(wù)器原有的輪詢、ip_hash、url_hash等負載均衡算法。

流量監(jiān)控模塊203，用于對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；

對每一個上游服務(wù)器中的服務(wù)器進行監(jiān)控，被監(jiān)控信息包括：請求的傳輸控制協(xié)議連接的信息：每秒查詢率、處理請求的平均時間、發(fā)送給客戶端的數(shù)據(jù)大小、超文本傳輸協(xié)議狀態(tài)1xx到5xx回應(yīng)報文等信息的監(jiān)控和統(tǒng)計。上游服務(wù)器的每秒查詢率、nginx服務(wù)器和上游服務(wù)器建立連接的時間(connect_time)、上游服務(wù)器響應(yīng)時間；對上游服務(wù)器的狀態(tài)進行實時監(jiān)控。

動態(tài)管理模塊204，用于基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；

為了方便開發(fā)和運維人員對上游服務(wù)器的管理，本方案在nginx服務(wù)器中提供了超文本傳輸協(xié)議接口，以便對上游服務(wù)器進行實時動態(tài)管理。避免手動修改nginx服務(wù)器配置文件、以及重啟nginx服務(wù)器。

所有的操作可以通過web交互界面進行操作，通過web交互界面修改consul中上游服務(wù)器中的信息，利用consul提供的watch機制，將修改的上游服務(wù)器信息發(fā)送給對應(yīng)nginx服務(wù)器集群，nginx服務(wù)器會在syn_interval分鐘生效，避免了重啟nginx服務(wù)器帶來的性能損失。

對上游服務(wù)器的管理主要分為手動操作和基于流量監(jiān)控數(shù)據(jù)的動態(tài)操作。

健康監(jiān)測模塊205，用于基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；

在nginx服務(wù)器啟動一個任務(wù)、定時的向后端的服務(wù)器發(fā)送心跳包，根據(jù)返回結(jié)果，例如：狀態(tài)碼，返回內(nèi)容，判斷后端服務(wù)器服務(wù)的健康狀態(tài)，若判斷服務(wù)器處于非健康狀態(tài)，該任務(wù)在nginx服務(wù)器內(nèi)部將該服務(wù)器標記為down。在本方案里，每一個請求，會根據(jù)特定的負載均衡算法選擇后端服務(wù)器，在轉(zhuǎn)發(fā)前，先判斷服務(wù)器的健康狀態(tài)，若服務(wù)器狀態(tài)為up，即服務(wù)器的狀態(tài)為健康則轉(zhuǎn)發(fā)。

日志管理模塊206，用于基于所述nginx服務(wù)器將日志寫入消息隊列進行管理。

nginx服務(wù)器是將日志直接輸出到本地的磁盤上，然后通過flume、logstash等工具進行采集。flume是cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)；flume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，flume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方(可定制)的能力。本方案利用lua模塊，將日志按照一定的格式拼接后寫入消息隊列，例如開源分布式消息系統(tǒng)，storm、hdfs、es等，(storm是一個分布式的，可靠的，容錯的數(shù)據(jù)流處理系統(tǒng)，hdfs是hadoop分布式文件系統(tǒng)，es即elasticsearch是一個開源的分布式搜索引擎，具備高可靠性，支持非常多的企業(yè)級搜索用例)進行使用，關(guān)閉nginx服務(wù)器本身的日志開關(guān)，減少磁盤消耗。減少對采集組件的運維工作。

綜上所述，在上述實施例中，通過web交互界面加入上游服務(wù)器信息，并將所述上游服務(wù)器信息存放至數(shù)據(jù)中心；nginx服務(wù)器接收到請求時，獲取所述請求的統(tǒng)一資源標識符，基于所述統(tǒng)一資源標識符查找對應(yīng)的上游服務(wù)器信息，并根據(jù)所述上游服務(wù)器預(yù)先設(shè)定的負載均衡策略對所述上游服務(wù)器信息進行轉(zhuǎn)發(fā)；對上游服務(wù)器進行實時流量監(jiān)控，并將獲取到的流量監(jiān)控信息發(fā)送至數(shù)據(jù)庫；基于所述nginx服務(wù)器中的超文本傳輸協(xié)議接口對上游服務(wù)器進行動態(tài)管理；基于所述nginx服務(wù)器檢測后端服務(wù)器的健康狀態(tài)；基于所述nginx服務(wù)器將日志寫入消息隊列進行管理，能夠有效的對不同的nginx集群進行統(tǒng)一的管理。

具體的，在上述實施例中，動態(tài)管理模塊具體實現(xiàn)方式可以為：

第一，對上游服務(wù)器的手動操作，主要有以下幾個方面：

a、查詢，可以實時獲取上游服務(wù)器的狀態(tài)信息；

b、修改狀態(tài)，可以根據(jù)業(yè)務(wù)需要動態(tài)的調(diào)整服務(wù)器的狀態(tài)，例如將服務(wù)器設(shè)置為up或者down，免手動修改配置文件；

c、添加/刪減服務(wù)器，可以根據(jù)具體業(yè)務(wù)動態(tài)的添加和刪減服務(wù)器。

第二，基于流量監(jiān)控數(shù)據(jù)的動態(tài)操作：

每隔n分鐘，通過從開源的非關(guān)系型分布式數(shù)據(jù)庫中獲取[now_ts–interval,now_ts]時間段的歷史數(shù)據(jù)，根據(jù)歷史數(shù)據(jù)做以下幾個方面的操作：

a、增加服務(wù)器

判斷[now_ts–interval,now_ts]時間段的平均每秒查詢率即qps_mean是否超過該upstream的閾值qps_threshold，(qps_threshold＝qps_singal_server*upstream_n)其中qps_singal為單個se服務(wù)器承受的每秒查詢率，upstream_n為上游服務(wù)器預(yù)設(shè)的服務(wù)器個數(shù))，若超過，則添加add_n個服務(wù)器，其中

b、刪減服務(wù)器

判斷上游服務(wù)器是否增加過服務(wù)器，若是，則計算[now_ts–interval,now_ts]時間段的平均每秒查詢率即qps_mean，

若qps_mean＜qps_threahold,則將上游服務(wù)器中新添加的add_n個服務(wù)器刪除；

若qps_threshold<qps_mean<qps_singal*(upstream_n+add_n),刪減del_n個服務(wù)器，其中

c、替換服務(wù)器

第一步：判斷上游服務(wù)器中服務(wù)器的健康狀態(tài)是否為up，若是轉(zhuǎn)第二步，否則將該服務(wù)器用其他備用服務(wù)器進行替換；

第二步：根據(jù)[now_ts–interval,now_ts]時間段的平均響應(yīng)時間、超文本傳輸協(xié)議狀態(tài)等信息判斷是否將服務(wù)器進行替換，具體的判斷依據(jù)需要和具體的業(yè)務(wù)進行定制。

綜上所述，本方案中提出的一種nginx服務(wù)器動態(tài)配置管理方案，簡化了nginx服務(wù)器的配置，將配置信息存放在數(shù)據(jù)中心consul中，通過web交互界面對nginx服務(wù)器按照集群進行統(tǒng)一管理，實現(xiàn)了信息管理、路由管理、流量監(jiān)控、動態(tài)管理、健康監(jiān)測和日志管理，減少運維人員的工作量。

本實施例方法所述的功能如果以軟件功能單元的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算設(shè)備可讀取存儲介質(zhì)中。基于這樣的理解，本發(fā)明實施例對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算設(shè)備(可以是個人計算機，服務(wù)器，移動計算設(shè)備或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：u盤、移動硬盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其它實施例的不同之處，各個實施例之間相同或相似部分互相參見即可。

對所公開的實施例的上述說明，使本領(lǐng)域?qū)I(yè)技術(shù)人員能夠?qū)崿F(xiàn)或使用本發(fā)明。對這些實施例的多種修改對本領(lǐng)域的專業(yè)技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。