本發(fā)明涉及計算機網(wǎng)絡(luò)及計算機軟件技術(shù)領(lǐng)域，特別地涉及一種配置管理系統(tǒng)及配置管理方法。

背景技術(shù)：

在集中大規(guī)模部署的互聯(lián)網(wǎng)應(yīng)用系統(tǒng)環(huán)境中，在業(yè)務(wù)進(jìn)行生產(chǎn)的過程中，遇到因業(yè)務(wù)需求變更而需要修改業(yè)務(wù)配置信息；或者因為用戶訪問驟然增加，以及其它運行環(huán)境的變化而需要立即修改應(yīng)用系統(tǒng)的技術(shù)參數(shù)等，這些情況往往對時效性要求非常高，往往要求可以實時修改配置值并且推送給集群部署的各個應(yīng)用實例，以讓配置信息的修改可以立即生效，以滿足業(yè)務(wù)的正常運轉(zhuǎn)或其它的服務(wù)降級以保障核心業(yè)務(wù)的正常運轉(zhuǎn)。

為了解決自動部署和配置管理的問題，目前通常是采用如圖1所示的統(tǒng)一自動化部署系統(tǒng)。該自動化部署系統(tǒng)是統(tǒng)一的應(yīng)用系統(tǒng)部署平臺，開發(fā)和運維人員通過該平臺管理各環(huán)境的配置信息，該平臺在管理配置信息的工作流程如下：首先開發(fā)運維人員訪問自動化部署系統(tǒng)，在系統(tǒng)里維護(hù)好對應(yīng)環(huán)境中配置文件的內(nèi)容，這些配置文件的目錄和文件名和應(yīng)用程序中的結(jié)構(gòu)一一對應(yīng)。然后開發(fā)運維人員開始部署應(yīng)用程序到對應(yīng)的應(yīng)用程序集群中，部署過程中的具體實現(xiàn)方式是將打好的應(yīng)用程序包從倉庫中下載下來，解壓程序包，用上一步維護(hù)好的對應(yīng)的配置文件內(nèi)容替換原來的內(nèi)容。第三步將替換后的文件壓縮遠(yuǎn)程發(fā)送到各客戶端實例服務(wù)器上。第四步啟動服務(wù)器，執(zhí)行服務(wù)器啟動腳本啟動應(yīng)用服務(wù)器，整個部署過程結(jié)束。上述方案是在部署階段同步配置信息，但是在運行階段若對配置進(jìn)行維護(hù)則無法同步到客戶端實例中，這無法滿足生產(chǎn)環(huán)境立即修改配置的需求，因此技術(shù) 人員研發(fā)了如圖2所示的定時頻繁拉取配置管理器技術(shù)來解決該問題。

定時頻繁拉取配置管理器技術(shù)的實現(xiàn)流程如下：運維人員通過訪問該配置管理器web應(yīng)用對配置進(jìn)行修改，配置修改完畢后會存儲到數(shù)據(jù)庫中，并且標(biāo)記為已修改。在客戶端應(yīng)用程序中會部署定時頻繁拉取配置管理器的客戶端包，該客戶端包會每隔一段時間(具體時間可以進(jìn)行配置，根據(jù)具體的業(yè)務(wù)的時效性要求進(jìn)行配置)會調(diào)用定時頻繁拉取配置管理器的接口拉取配置的變化信息，若查詢到變化則會將配置信息的變化同步到客戶端應(yīng)用實例中。

但是無論自動化部署系統(tǒng)還是定時頻繁拉取配置管理器，都具有缺點。具體分析如下：

(1)自動部署系統(tǒng)在運行階段無法更新配置。該方案同步配置信息是在應(yīng)用程序的部署階段進(jìn)行的，在系統(tǒng)的運行階段無法進(jìn)行配置變更，因此配置信息變更之后，若要讓變更生效，則需要重新發(fā)布應(yīng)用程序到應(yīng)用集群的各個實例中，這往往是一個比較耗時的過程，并且在生產(chǎn)環(huán)境中若重新發(fā)布應(yīng)用程序會影響用戶的使用，這對于大型互聯(lián)網(wǎng)應(yīng)用往往是不允許的，因此該技術(shù)方案的局限性給互聯(lián)網(wǎng)應(yīng)用的運維和生產(chǎn)帶來了極大的不便。

(2)定時頻繁拉取配置管理器產(chǎn)生了較大系統(tǒng)資源浪費。由于定時頻繁拉取配置的技術(shù)方案需要頻繁的定時的調(diào)用接口去拉取配置信息的變更，若頻率太低則達(dá)不到應(yīng)用系統(tǒng)配置變更實時性要求，因此往往頻繁都會設(shè)置得比較高，比如每5秒鐘一次。但是應(yīng)用配置的變更操作頻繁在生產(chǎn)環(huán)境往往是比較低的。這種頻繁的調(diào)用接口產(chǎn)生了大量的內(nèi)部網(wǎng)絡(luò)io和服務(wù)器資源的浪費，如果應(yīng)用集群規(guī)模非常大，則產(chǎn)生的資源浪費是比較巨大的。

(3)兩種方案配置生效的時效性都較低。我們假設(shè)各方案針對的都是互聯(lián)網(wǎng)大型應(yīng)用程序，一個應(yīng)用程序由1000個服務(wù)實例組成。由 于技術(shù)方案的局限性，兩種技術(shù)方案的時效性都非常差，第一種方案需要重新發(fā)布應(yīng)用程序，那么配置信息全部生效至少需要1個小時。第二種方案需要頻繁拉取配置信息，若拉取的間隔是5秒鐘，則單個實例的生效時間至少是5秒鐘。

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

有鑒于此，本發(fā)明提供一種輕量級的、可實時推送的配置管理系統(tǒng)及配置管理方法，以解決現(xiàn)有技術(shù)中的問題。

本發(fā)明第一方面提出一種配置管理系統(tǒng)，包括：多個客戶端、配置管理服務(wù)器、以及配置存儲服務(wù)器，其中：所述多個客戶端與所述配置管理服務(wù)器之間采用netty框架；所述配置管理服務(wù)器與所述多個客戶端對應(yīng)；所述配置管理服務(wù)器用于在接收到所述客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將所述目標(biāo)配置信息發(fā)送給所述客戶端；以及用于在接收到外部操作輸入的配置變更信息的情況下，將所述配置變更信息發(fā)送到所述配置存儲服務(wù)器中并且將所述配置變更信息推送給所述客戶端。

可選地，所述配置管理服務(wù)器包括：配置服務(wù)模塊，用于啟動以及初始化所述配置管理服務(wù)器；配置服務(wù)處理模塊，用于接收所述客戶端發(fā)送的所述配置信息請求，根據(jù)所述配置信息請求查詢所述配置存儲服務(wù)器，將查詢結(jié)果反饋所述客戶端；還用于接收外部操作輸入的配置變更信息，將所述配置變更信息保存到所述配置存儲服務(wù)器中并且將所述配置變更信息推送給所述客戶端；客戶端管理服務(wù)模塊，用于保存所述客戶端的注冊信息。

可選地，所述客戶端與所述配置管理服務(wù)器之間建立有tcp長連接并且采用重連機制。

可選地，所述客戶端還用于加載來自客戶端的配置信息、遠(yuǎn)程文 件臨時配置信息、本地配置信息這三種配置信息之一，其中，所述加載來自客戶端的配置信息的優(yōu)先級高于加載所述遠(yuǎn)程文件臨時配置信息，加載所述遠(yuǎn)程文件臨時配置信息的優(yōu)先級高于加載所述本地配置信息的優(yōu)先級。

本發(fā)明第二方面提出一種配置管理方法，應(yīng)用于本發(fā)明的配置管理系統(tǒng)，該配置管理方法包括：所述配置管理服務(wù)器在接收到所述客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將所述目標(biāo)配置信息發(fā)送給所述客戶端；所述配置管理服務(wù)器在接收到外部操作輸入的配置變更信息的情況下，將所述配置變更信息發(fā)送到所述配置存儲服務(wù)器中并且將所述配置變更信息推送給所述客戶端。

可選地，所述配置管理服務(wù)器在接收到所述客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將所述目標(biāo)配置信息發(fā)送給所述客戶端的步驟包括：所述配置管理服務(wù)器中的配置服務(wù)模塊啟動以及初始化所述配置管理服務(wù)器；所述配置管理服務(wù)器中的客戶端管理服務(wù)模塊接收并保存所述客戶端的注冊信息；所述配置管理服務(wù)器中的配置服務(wù)處理模塊在接收到所述客戶端發(fā)送的所述配置信息請求的情況下，根據(jù)所述配置信息請求查詢所述配置存儲服務(wù)器，將查詢結(jié)果反饋所述客戶端。

可選地，所述客戶端與所述配置管理服務(wù)器之間建立有tcp長連接并且采用重連機制。

可選地，還包括：所述客戶端在接收到來自客戶端的配置信息的情況下，加載所述來自客戶端的配置信息；所述客戶端在未接收到所述來自客戶端的配置信息并且接收到遠(yuǎn)程文件臨時配置信息的情況下，加載所述遠(yuǎn)程文件臨時配置信息；所述客戶端在未接收到所述來自客戶端的配置信息并且未接收到遠(yuǎn)程文件臨時配置信息的情況下，加載本地配置信息。

根據(jù)本發(fā)明的技術(shù)方案采用了netty技術(shù)實現(xiàn)客戶端與服務(wù)端的長連接，由于netty是一個高性能的、異步事件驅(qū)動的非阻塞輸入輸出流框架，因此用戶端可以方便地主動獲取輸入輸出操作結(jié)果或者通過通知機制獲取輸入輸出操作結(jié)果，從而實現(xiàn)了配置信息的實時推送同時節(jié)約了網(wǎng)絡(luò)開銷。

附圖說明

附圖用于更好地理解本發(fā)明，不構(gòu)成對本發(fā)明的不當(dāng)限定。其中：

圖1是現(xiàn)有技術(shù)的自動部署系統(tǒng)技術(shù)的示意圖；

圖2是現(xiàn)有技術(shù)的的定時頻繁拉取配置管理技術(shù)的示意圖；

圖3是根據(jù)本發(fā)明實施方式的配置管理系統(tǒng)的主要模塊的示意圖；

圖4是根據(jù)本發(fā)明實施方式的配置管理方法的主要步驟的示意圖；

圖5是根據(jù)本發(fā)明實施方式的配置管理系統(tǒng)和方法的原理示意圖；

圖6是根據(jù)本發(fā)明實施方式的關(guān)于配置管理服務(wù)器的時序圖；

圖7是根據(jù)本發(fā)明實施方式的關(guān)于客戶端的時序圖。

具體實施方式

以下結(jié)合附圖對本發(fā)明的示范性實施方式做出說明，其中包括本發(fā)明實施方式的各種細(xì)節(jié)以助于理解，應(yīng)當(dāng)將它們認(rèn)為僅僅是示范性的。因此，本領(lǐng)域普通技術(shù)人員應(yīng)當(dāng)認(rèn)識到，可以對這里描述的實施方式做出各種改變和修改，而不會背離本發(fā)明的范圍和精神。同樣，為了清楚和簡明，以下的描述中省略了對公知功能和結(jié)構(gòu)的描述。

從背景介紹中兩種現(xiàn)有技術(shù)存在的問題來看，它們都是非實時的配置管理，配置生效都有時間延遲，這對于對實時性要求較高的電子商務(wù)及互聯(lián)網(wǎng)行業(yè)來說存在局限性，給生產(chǎn)和業(yè)務(wù)帶來了極大的不便，因此本發(fā)明的一個目標(biāo)是實現(xiàn)實時配置管理，希望可以在配置信息發(fā)生變化的時候立即將變更推送給服務(wù)實例。

本發(fā)明的另一個目標(biāo)是降低配置管理服務(wù)的開發(fā)和運營成本。從定時頻繁拉取配置管理技術(shù)的介紹來看，該方案存在較大的網(wǎng)絡(luò)資源浪費，因為頻繁的拉取配置信息，則會導(dǎo)致服務(wù)器內(nèi)網(wǎng)的網(wǎng)絡(luò)資源產(chǎn)生浪費。因此本發(fā)明采用推送的解決方案，只在配置信息發(fā)生變化的時候才會推送配置變更信息，平時絕大多數(shù)時候只會有非常小的保持連接的ping包的發(fā)送，從而節(jié)省大量的網(wǎng)絡(luò)資源。

圖3是根據(jù)本發(fā)明實施方式的配置管理系統(tǒng)的主要模塊的示意圖。如圖3所示，該實施方式的配置管理系統(tǒng)包括：多個客戶端311、……31n、配置管理服務(wù)器32(可以簡稱服務(wù)器或者服務(wù)端)以及配置存儲服務(wù)器33(可以簡稱存儲服務(wù)器或者數(shù)據(jù)庫)。多個客戶端311、……30n與配置管理服務(wù)器32之間采用netty框架。配置管理服務(wù)器32與多個客戶端311……31n對應(yīng)。配置管理服務(wù)器32用于在接收到客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將目標(biāo)配置信息發(fā)送給客戶端；以及用于在接收到外部操作輸入的配置變更信息的情況下，將配置變更信息發(fā)送到配置存儲服務(wù)器33中并且將配置變更信息推送給客戶端。

需要解釋的是，服務(wù)端與客戶端通訊使用java最新開源的網(wǎng)絡(luò)框架netty技術(shù)實現(xiàn)。netty是一個高性能、異步事件驅(qū)動的非阻塞輸入輸出流框架，它提供了對tcp、udp協(xié)議和文件傳輸?shù)闹С?，作為一個異步非阻塞輸入輸出流框架框架，netty的所有io操作都是異步非阻塞的，通過消息監(jiān)聽機制，用戶可以方便的主動獲取或者通過通知機制獲得io操作結(jié)果。

根據(jù)本發(fā)明實施方式的配置管理系統(tǒng)采用了netty技術(shù)實現(xiàn)客戶端與服務(wù)端的長連接，由于netty是一個高性能的、異步事件驅(qū)動的非阻塞輸入輸出流框架，因此用戶端可以方便地主動獲取輸入輸出操作結(jié)果或者通過通知機制獲取輸入輸出操作結(jié)果，從而實現(xiàn)了配置信息的實時推送同時節(jié)約了網(wǎng)絡(luò)開銷。

可選地，配置管理服務(wù)器32包括：配置服務(wù)模塊、配置服務(wù)處理模塊和客戶端管理服務(wù)模塊。其中：配置服務(wù)模塊用于啟動以及初始化配置管理服務(wù)器32。配置服務(wù)處理模塊用于接收客戶端311、……31n發(fā)送的配置信息請求，根據(jù)配置信息請求查詢配置存儲服務(wù)器33，將查詢結(jié)果反饋客戶端；還用于接收外部操作輸入的配置變更信息，將配置變更信息發(fā)送到配置存儲服務(wù)器33中并且將配置變更信息推送給客戶端311、……31n?？蛻舳斯芾矸?wù)模塊，用于保存客戶端311、……31n的注冊信息。

可選地，客戶端311、……31n與配置管理服務(wù)器32之間建立有tcp長連接并且采用重連機制。設(shè)置客戶端重連機制是為了確保客戶端與服務(wù)端之間保持持久的tcp連接，避免因為網(wǎng)絡(luò)不穩(wěn)定而讓客戶端與服務(wù)端之間失去連接。另外，為了防止在服務(wù)端故障的情況下，客戶端頻繁重連引起的內(nèi)網(wǎng)網(wǎng)絡(luò)風(fēng)暴問題，可以設(shè)置客戶端在重試3次仍未連接上則會暫時睡眠10分鐘，以免過高的網(wǎng)絡(luò)開銷。

可選地，客戶端311、……31n還用于加載來自客戶端的配置信息、遠(yuǎn)程文件臨時配置信息、本地配置信息這三種配置信息之一，其中，加載來自客戶端的配置信息的優(yōu)先級高于加載遠(yuǎn)程文件臨時配置信息，加載遠(yuǎn)程文件臨時配置信息的優(yōu)先級高于加載本地配置信息的優(yōu)先級?？蛻舳伺渲玫娜壖虞d機制保障了客戶端應(yīng)用系統(tǒng)的高可用性。

圖4是根據(jù)本發(fā)明實施方式的配置管理方法的主要步驟的示意圖。如圖4所示，該實施方式的配置管理方法，應(yīng)用于上文的配置管理系統(tǒng)。該配置管理方法可以包括步驟a和步驟b。

步驟a：配置管理服務(wù)器在接收到客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將目標(biāo)配置信息發(fā)送給客戶端。

步驟b：配置管理服務(wù)器在接收到外部操作輸入的配置變更信息的情況下，將配置變更信息發(fā)送到配置存儲服務(wù)器中并且將配置變更信 息推送給客戶端。

根據(jù)本發(fā)明實施方式的配置管理方法采用了netty技術(shù)實現(xiàn)客戶端與服務(wù)端的長連接，由于netty是一個高性能的、異步事件驅(qū)動的非阻塞輸入輸出流框架，因此用戶端可以方便地主動獲取輸入輸出操作結(jié)果或者通過通知機制獲取輸入輸出操作結(jié)果，從而實現(xiàn)了配置信息的實時推送同時節(jié)約了網(wǎng)絡(luò)開銷。

可選地，配置管理服務(wù)器在接收到客戶端發(fā)送的配置信息請求的情況下，查詢目標(biāo)配置信息并且將目標(biāo)配置信息發(fā)送給客戶端的步驟包括：配置管理服務(wù)器中的配置服務(wù)模塊啟動以及初始化配置管理服務(wù)器；配置管理服務(wù)器中的客戶端管理服務(wù)模塊接收并保存客戶端的注冊信息；配置管理服務(wù)器中的配置服務(wù)處理模塊在接收到客戶端發(fā)送的配置信息請求的情況下，根據(jù)配置信息請求查詢配置存儲服務(wù)器，將查詢結(jié)果反饋客戶端。

可選地，客戶端與配置管理服務(wù)器之間建立有tcp長連接并且采用重連機制。

可選地，本發(fā)明實施方式的配置管理方法還包括如下步驟：客戶端在接收到來自客戶端的配置信息的情況下，加載來自客戶端的配置信息；客戶端在未接收到來自客戶端的配置信息并且接收到遠(yuǎn)程文件臨時配置信息的情況下，加載遠(yuǎn)程文件臨時配置信息；客戶端在未接收到來自客戶端的配置信息并且未接收到遠(yuǎn)程文件臨時配置信息的情況下，加載本地配置信息。換言之，加載來自客戶端的配置信息的優(yōu)先級高于加載遠(yuǎn)程文件臨時配置信息，加載遠(yuǎn)程文件臨時配置信息的優(yōu)先級高于加載本地配置信息的優(yōu)先級。

為使本領(lǐng)域技術(shù)人員更好地理解本發(fā)明的技術(shù)方案，下面結(jié)合圖5至圖7作進(jìn)一步介紹。

圖5是根據(jù)本發(fā)明實施方式的配置管理系統(tǒng)和方法的原理示意圖。如圖5所示，實時可推送配置管理服務(wù)器在運維人員修改了配置信息之后，會保存到mysql數(shù)據(jù)庫服務(wù)器中，運維人員可以手工選擇配置變更推送的客戶端實例，客戶端實例與服務(wù)器之間建立的是tcp長連接，兩者的連接會持續(xù)保持，若出現(xiàn)網(wǎng)絡(luò)中斷，則客戶端會自動進(jìn)行重連。該方案是非常輕量級的，實時可推送配置管理服務(wù)器只需要部署一個war包和一個mysql服務(wù)器即可，而客戶端只需要引入一個jar包。由于對于客戶端應(yīng)用系統(tǒng)的影響非常小，僅做一個簡單的配置即可，因此本發(fā)明的技術(shù)方案具有易于部署和維護(hù)的優(yōu)點，并且易于客戶端接入使用。

圖6是根據(jù)本發(fā)明實施方式的關(guān)于配置管理服務(wù)器的時序圖。如圖6所示，實時可推送的配置服務(wù)端的相關(guān)時序設(shè)計，詳細(xì)步驟如下。

a.初始化和啟動服務(wù)端，監(jiān)聽端口，等待客戶端連接。

b.客戶端與服務(wù)端之間建立一個tcp長連接，初始化連接信息。

c.客戶端發(fā)送信息包。信息報包括客戶端信息和配置請求信息。其中：客戶端信息包括客戶端進(jìn)程號、客戶端ip和連接端口等信息。配置請求信息包括請求的項目編號、環(huán)境編號和配置模塊等信息。

d.注冊客戶端。服務(wù)端將客戶端信息存儲下來以備后續(xù)查詢。

e.服務(wù)端處理客戶端請求，即根據(jù)配置請求信息并且查詢請求參數(shù)對應(yīng)的配置參數(shù)信息。

f.服務(wù)端將配置信息通過網(wǎng)絡(luò)發(fā)回給客戶端。

g.運維人員修改配置并推送。運維人員通過配置管理器更新配置信息的版本，并且通過網(wǎng)絡(luò)發(fā)回給推送的客戶端列表。

由上可知，通過netty技術(shù)實現(xiàn)客戶端與服務(wù)端之間的雙向通訊。當(dāng)服務(wù)端有配置信息的變更時服務(wù)端可以主動推送給客戶端。當(dāng)客戶端向服務(wù)端發(fā)出查詢請求時服務(wù)端可以響應(yīng)客戶端。

圖7是根據(jù)本發(fā)明實施方式的關(guān)于客戶端的時序圖?；ヂ?lián)網(wǎng)應(yīng)用對于服務(wù)的高可用有著極高的要求，因此客戶端應(yīng)該盡可能不依賴服務(wù)的可靠性，因此客戶端的設(shè)計要點是降低對服務(wù)端的依賴。客戶端應(yīng)用在啟動的時候加載配置信息，會實現(xiàn)三級加載，具體過程如下。

a.首先加載本地應(yīng)用程序中的配置文件內(nèi)容。

b.再次加載本地遠(yuǎn)程文件的臨時文件。每次讀取遠(yuǎn)程配置信息都會先保存在臨時文件中。臨時文件位于用戶目錄下，確保一定有權(quán)限可寫。

c.最后加載遠(yuǎn)程讀取過來的配置信息。

由上可知，客戶端后面的加載都會覆蓋前面加載的屬性值，因此最后讀取配置的優(yōu)先級是遠(yuǎn)程配置高于本地遠(yuǎn)程配置臨時文件，本地遠(yuǎn)程配置臨時文件高于本地文件。所以該設(shè)計保障了在服務(wù)端不可用的情況下，依舊對于客戶端應(yīng)用無任何影響。

上述具體實施方式，并不構(gòu)成對本發(fā)明保護(hù)范圍的限制。本領(lǐng)域技術(shù)人員應(yīng)該明白的是，取決于設(shè)計要求和其他因素，可以發(fā)生各種各樣的修改、組合、子組合和替代。任何在本發(fā)明的精神和原則之內(nèi)所作的修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明保護(hù)范圍之內(nèi)。