本申請涉及互聯(lián)網(wǎng)云計算技術領域，特別是涉及一種云集群能自識別的分布配置管理方法和裝置。

背景技術：

在運維管理中，重要的一個環(huán)節(jié)是配置文件的管理，尤其在云集群中配置文件定義了各云服務器應該使用什么地方的資源、使用相應功能時能夠調用何種服務、從哪兒調用，有什么限制等。配置文件如果出現(xiàn)問題，會對影響系統(tǒng)的穩(wěn)定性。其中，運維可以理解為運營維護。

在先技術中，運維中對配置文件的管理經(jīng)歷了一系列的發(fā)展，其各種方案的配置文件的創(chuàng)建都需要運維人員與研發(fā)人員進行大量溝通，創(chuàng)建后再由運維人員將相應的配置文件存儲至一個統(tǒng)一的第三方系統(tǒng)中，由運維人員對其進行管理。每次修改都需要研發(fā)人員跟運維人員溝通如何對配置文件進行修改，然后讓運維人員對配置文件進行維護。

因此，在先技術的運維管理方案中，運維人員與研發(fā)人員對配置文件的創(chuàng)建過程耦合度高；配置文件的管理集中在一個第三方系統(tǒng)中，第三方系統(tǒng)如一個單獨的配置服務器、svn(subversion是一個開放源代碼的版本控制系統(tǒng))或者git(git是一款免費、開源的分布式版本控制系統(tǒng))、cmdb(configurationmanagementdatabase，配置管理數(shù)據(jù)庫)，導致運維的容災效果差；配置文件的管理過程人工參與度高，系統(tǒng)的自我識別能力差，配置文件的管理效率低。

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

鑒于上述問題，提出了本申請實施例以便提供一種克服上述問題或者至少部分地解決上述問題的一種配置管理方法和相應的一種配置管理裝置。

為了解決上述問題，本申請公開了一種配置管理方法，包括：

接收配置模板；

根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)；

以所述配置文件為基礎，在各錨點位置代入相應配置參數(shù)生成完全狀態(tài)的第一配置文件。

本申請還公開了一種配置管理方法，包括：

模板接收模塊，用于接收配置模板；

配置參數(shù)獲取模塊，用于根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)；所述功能配置文件對應的配置參數(shù)控制當前服務器需求的各個功能；

配置文件生成模塊，用于以所述配置文件為基礎，在各錨點位置代入相應配置參數(shù)生成完全狀態(tài)的第一配置文件。

本申請實施例包括以下優(yōu)點：

本申請實施例，可以將集群的配置文件的創(chuàng)建按運維與開發(fā)兩方的參與度，分為了由運維人員管理的定位配置文件和功能配置文件、由開發(fā)人員管理的資源配置文件和配置模板。該定位配置文件提供了該服務器所處位置的配置參數(shù)，功能配置文件提供了指示服務器是否需要某項功能的配置參數(shù)，對于每項功能本申請為其設置了相應的資源配置文件，該資源配置文件中提供了各種服務器在所處位置所需求的資源的配置參數(shù)；該配置模板以完整的配置文件為基礎，將其中與所有變量相關的部分采用錨點進行標記。因此本申請對于配置模板，可以分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)，然后基于獲取到的配置參數(shù)生成完全狀態(tài)的第一配置文件。服務器在使用時則可以直接讀取該第一配置文件執(zhí)行相應的功能。

因此，首先：本申請將配置文件的創(chuàng)建所需內容按照運維人員與研發(fā)人員分離，運維人員和研發(fā)人員的溝通代價大大減少，在定位配置文件和功能配置文件不需要變更的情況下，研發(fā)人員甚至不需要和運維人員溝通即可通 過更新配置模板實現(xiàn)系統(tǒng)的升級。

其次，本申請可以由集群中的服務器自身實現(xiàn)完全狀態(tài)的第一配置文件的生成過程，因此，可以實現(xiàn)各個服務器管理自身的配置文件，不依賴第三方系統(tǒng)去創(chuàng)建完整的配置文件，配置文件實現(xiàn)了分布式管理，集群中的一個服務器崩潰，并不影響其他服務器的配置文件的管理，提高了容災能力。

再次，本申請只需要定位配置文件、功能配置文件和資源配置文件三者分發(fā)到該服務器中，就可以根據(jù)配置模板自動生成配置文件。因此，本申請的配置文件的生成過程，降低了人工參與度，服務器具備自我識別能力，可以自動生成配置文件。

附圖說明

圖1是本申請的一種云集群能自識別的分布配置管理方法實施例的步驟流程圖；

圖2是本申請的另一種云集群能自識別的分布配置管理方法實施例的步驟流程圖；

圖3是本申請的一種云集群能自識別的分布配置管理裝置實施例的結構框圖；

圖4是本申請的另一種云集群能自識別的分布配置管理裝置實施例的結構框圖。

具體實施方式

為使本申請的上述目的、特征和優(yōu)點能夠更加明顯易懂，下面結合附圖和具體實施方式對本申請作進一步詳細的說明。

本申請實施例的核心構思之一在于，可以將集群的配置文件的創(chuàng)建按運維與開發(fā)兩方的參與度，分為了由運維人員管理的定位配置文件和功能配置文件、由開發(fā)人員管理的資源配置文件和配置模板。該定位配置文件提供了該服務器所處位置的配置參數(shù)，功能配置文件提供了指示服務器是否需要某項功能的配置參數(shù)，對于每項功能本申請為其設置了相應的資源配置文件， 該資源配置文件中提供了各種服務器在所處位置所需求的資源的配置參數(shù)；該配置模板以完整的配置文件為基礎，將其中與所有變量相關的部分采用錨點進行標記。因此本申請對于配置模板，可以分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)，然后基于獲取到的配置參數(shù)生成完全狀態(tài)的第一配置文件。服務器在使用時則可以直接讀取該第一配置文件執(zhí)行相應的功能。由此，可以大大降低運維人員和研發(fā)人員的溝通代價；并且集群中的各個服務器自動生成自己的配置文件，可以實現(xiàn)分布式文件管理，從而提高了容災能力；還降低了管理配置文件的人工參與度，使服務器對配置文件具備了自我識別能力。

實施例一

參照圖1，示出了本申請的一種云集群能自識別的分布配置管理方法實施例的步驟流程圖，具體可以包括如下步驟：

步驟110，接收配置模板；

本申請接收配置模板的可以為集群中的各臺服務器。當然服務器可以從調度服務器接收配置模板，集群研發(fā)人員將配置文件發(fā)送至調度服務器，然后調度服務器將該配置模板分發(fā)至集群中的各臺服務器。當然，還可以有其他方式將配置模板發(fā)送至集群的各臺服務器，本申請不對其加以限制。

需要說明的是，在各臺服務器接收配置模板之前還包括：

步驟a1，獲取定位配置文件、功能配置文件以及各資源配置文件，并將其存儲至指定存儲位置。在本申請實施例中，可以對于一個云集群，預先根據(jù)該集群的需求配置定位配置文件、功能配置文件，以及為各個云集群設定全局的資源配置文件，每個功能對應一個資源配置文件。然后將上述三個配置文件發(fā)送至集群中的各個服務器中。

在本申請實施例中，可以在集群服務器的系統(tǒng)環(huán)境初始化時，創(chuàng)建該定位配置文件、功能配置文件，因為定位配置文件、功能配置文件屬于該集群的個性化的配置文件，其一般不會變化。然后對于開發(fā)人員創(chuàng)建的各種資源配置文件，則分發(fā)到各個集群的各服務器中。

然后，本申請實施例的各個服務器則可以進入配置文件自動管理過 程，該過程包括步驟110-130。

在本申請實施例中，可以預先統(tǒng)一規(guī)范化各功能下各資源的命名，運維人員和研發(fā)人員則基于該統(tǒng)一的資源的命名，編輯自己負責的文件。比如對于一個集群，該集群需要的各功能下的資源的資源地址的名稱，根據(jù)該集群的定位標識命名。比如一個集群的定位標識為“hangzhou”，該集群需求的各功能的資源的資源地址統(tǒng)一根據(jù)“hangzhou”命名。進一步的，“hangzhou”集群需要eat功能的“.com”資源，則可以將eat功能下該集群需要的資源的資源地址命名為“hangzhou_eat.com”。

然后將定位配置文件的名稱和其中的固定字段、功能配置文件的名稱和其中固定字段通知給各方，各方即可獨立的編輯自己負責的文件。互相之間不需要再次溝通如何配置，溝通內容少，溝通代價低。

優(yōu)選的，在本申請另一優(yōu)選的實施例中步驟110之前，還包括：

步驟100，獲取各資源配置文件，以及屬于當前云服務器所在集群的定位配置文件、功能配置文件；其中，每個資源配置文件中的各資源地址與各集群的定位配置文件中的定位標識作為關鍵字段；所述功能配置文件中的功能關鍵字段采用各資源配置文件的名稱。

基于上述規(guī)范化的命名，本申請的配置文件可以如下述例子：

(1)定位配置文件

本申請實施例統(tǒng)一定位配置文件的命名，各個集群該配置文件的命名可以相同。比如都用who命名，然后在其中設置關鍵字段和關鍵值，關鍵字段是固定的字段，比如cluster_name，關鍵值是該服務器所在集群的定位標識，不同集群定位標識不同。然后即可基于上述規(guī)定生成配置文件who.config，其配置文件的偽代碼示例如下：

其中，who和cluster_name可以根據(jù)需要或者說習慣命名，運維和研發(fā)側統(tǒng)一即可。定位配置文件存儲集群名稱，使多個集群在功能、定位和資 源上通過集群名加以區(qū)分。

(2)功能配置文件，

本申請實施例統(tǒng)一功能配置文件的命名，各個集群該功能配置文件的命名可以相同。比如都用switch命名，然后在該功能配置文件中對各功能設置多個關鍵字段以及相應的關鍵值，其關鍵字段為功能開關字段，關鍵值為功能開關標識。如eat功能，其功能開關字段為is_eat，功能開關標識為yes或no，yes表示該服務器可以使用該功能，no表該服務器不能使用該功能。然后即可基于上述規(guī)定生成配置文件switch.conf，其配置文件的偽代碼示例如下：

上述配置文件中設置了四個功能eat、sleep的功能開關字段，以及相應的功能開關標識。

(3)資源配置文件

本申請實施例統(tǒng)一資源配置文件的命名，資源配置文件是全局的，各個集群的服務器均使用相同的資源配置文件。每個資源配置文件對應一個功能。在實際應用中，基于功能名構建資源配置文件，即可以結合額外字符與功能名組合成資源配置文件的名稱，避免字段過少導致名稱沖突。比如在功能名前添加統(tǒng)一的功能名前綴“res_”,對于eat功能，其資源配置文件的名稱可以為res_eat，其他功能配置文件的名稱類似，其結構都為res_*，其中“*”用功能名稱替代即可。然后在該功能配置文件中設置多個關鍵字段和關鍵值，其關鍵字段為各個集群的定位標識，關鍵值為資源地址。其資源地址則可以根據(jù)相應集群的定位標識命名，比如一該集群的定位標識為區(qū)別量，其他字段使用該資源的固有字符。然后即可基于上述規(guī)定生成配置文件res_eat.config，其配置文件的偽代碼示例如下：

其中，存在集群“beijing”需要的資源地址“beijing_eat.com”，和“hangzhou”需要的資源地址“hangzhou:hangzhou_eat.com”。

類似上述例子，對于sleep功能，其配置文件的偽代碼示例如下：

如上，每個資源配置文件中的各資源地址與各集群的定位配置文件中的定位標識作為關鍵字段；上述功能配置文件中的功能關鍵字段采用各資源配置文件的名稱。

可以理解的是，在混合云集群中，上述功能為云集群執(zhí)行各種操作所需的各種服務，如身份驗證服務。其中的資源可以理解為為該集群提供的服務調用位置接口，比如對于身份驗證服務來說，資源某個區(qū)域的身份驗證服務接口。

在本申請實施例中，各服務器獲取所在集群自己的定位配置文件、功能配置文件存儲在指定位置。同時可以獲取所有集群公用的資源配置文件存儲在指定位置。

需要說明的是，在本申請實施例中，在接收配置模板后，實際上可以從各配置文件的指定存儲位置加載配置文件到內存中，然后執(zhí)行步驟120。

當然，本申請實施例的服務器在接收到配置模板之后，可以將其導入到預先設置的模板解析引擎中，然后由模板解析引擎去加載上述幾個配置文件，然后執(zhí)行步驟120。

步驟120，根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)；

在本申請實施例中，接收到配置模板之后，可以由預置的模板解析引擎解析該配置模板，解析時，查找配置模板中的錨點，然后根據(jù)錨點位置的提 取參數(shù)，從分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)。

在本申請實施例中，由于前述命名的統(tǒng)一化，因此定位配置文件以及功能配置文件與各資源配置文件實際上是關聯(lián)的。而配置模板需要的配置參數(shù)可以從上述三個配置文件中讀取。當然，可以如上述在配置模板中針對需求的各配置文件中的配置參數(shù)設置錨點，從而可以讀取相應的錨點。

在本申請實施例中，配置模板可以采用.tpl格式文件構建，tpl是template的縮寫，是一種文件格式。本申請實施例中，研發(fā)人員可以基于完全狀態(tài)的第一配置文件中的關鍵字段，將關鍵字段中需要上述幾個配置文件的配置參數(shù)的關鍵值設置錨點，然后即可根據(jù)錨點從上述幾個配置文件中讀取配置參數(shù)。

在本申請一優(yōu)選的實施例中，所述配置模板包括：

各功能的功能開關關鍵字段、功能名稱關鍵字段、功能資源關鍵字段；其中，所述定位錨點在功能名稱關鍵字段的關鍵值中以及資源錨點中，所述功能錨點在所述功能開關字段的關鍵值中，所述資源錨點在所述功能資源關鍵字段的關鍵值中。

錨點是一種迅速定位器一樣的標記，通過錨點標識的指向和定位一個新的對象，導入或讀取所需要的對象。在本申請中，錨點指向的對象是各配置文件相關的參數(shù)。

其中，配置模板的偽代碼示例如下：

module.tpl

{

is_eat:${switch:is_eat},

eat_name:${who:cluster_name}_eat,

eat_cpu:1,

eat_res:${res_eat:${who:cluster_name}},

is_sleep:${switch:is_sleep},

sleep_name:${who:cluster_name}_sleep,

sleep_res:${res_sleep:${who:cluster_name}},

sleep_cpu:1,

}

如上，配置模板統(tǒng)一設置了eat功能和sleep功能，其實際的配置文件中藥使用這幾個功能需要包括相應的關鍵字段，如is_eat、eat_name、eat_cpu、eat_res、is_sleep、sleep_name、sleep_res、sleep_cpu。其中，is_eat和is_sleep為功能開關字段。其中eat_name、sleep_name為功能名稱關鍵字段。其中，eat_res和sleep_res功能資源關鍵字段。其中，eat_cpu和sleep_cpu是由研發(fā)自己負責規(guī)定，與前述配置文件沒有關系，而剩余的關鍵字段的關鍵值都可以分別從前述三個配置文件中獲取。因此可以設置相應的錨點。

在本申請實施例中，錨點分為定位錨點、功能錨點和資源錨點。其中定位錨點在功能名稱關鍵字段的關鍵值中，如上述例子中定位錨點${who:cluster_name}在功能名稱字段eat_name的關鍵值中和資源錨點${res_eat:${who:cluster_name}}中。功能錨點${switch:is_eat}在功能開關字段is_eat中。資源錨點${res_eat:${who:cluster_name}}在功能資源關鍵字段eat_res中。

上述示例中$標識的是錨點標識，錨點標識后的范圍標識{}標示要讀取的對應配置文件名稱和配置文件中對應的關鍵字段名。$、{}及其中的字符組合成了錨點，其表示從{}中對應的配置文件中提取關鍵值為配置參數(shù)。

可以理解的是錨點標識、范圍標識不限于上述示例中的情況，本申請不對其加以限制。

在本申請一優(yōu)選的實施例中，所述步驟120，包括子步驟121-123：

子步驟121，根據(jù)所述配置模板中的定位錨點從定位配置文件獲取定位標識；

在模板中定位錨點語句${who:cluster_name}_eat,對應的是定位配置文件：

who.conf

{

cluster_name:hangzhou

}

其首先根據(jù)who查找到who.conf文件，然后根據(jù)cluster_name從該配置文件中匹配，讀取cluster_name下的關鍵值，得到定位標識“hanghzhou”。

其他定位錨點類似。

子步驟122，根據(jù)所述配置模板中的功能錨點從功能配置文件中獲取功能開關標識；

在模板中的功能開關錨點語句${switch:is_eat},對應的是功能開關配置文件：

其首先根據(jù)switch查找到switch.conf文件，然后根據(jù)is_eat讀取該關鍵字段下的關鍵值，得到功能開關標識為“yes”。類似的，${switch:is_sleep}讀取得到的功能開關標識為“no”。

子步驟123，根據(jù)所述配置模板中的資源錨點以及定位標識從資源配置文件中獲取資源地址；所述資源錨點中包括定位錨點。

模板中的資源錨點語句${res_eat:${who:cluster_name}}和${res_sleep:${who:cluster_name}},其首先將${who:cluster_name}替換為子步驟121中得到的定位標識“hanghzhou”，從而得到${res_eat:hanghzhou}和${res_sleep:hanghzhou}。

然后對于${res_eat:hanghzhou}對于的資源配置文件：

首先根據(jù)res_eat查找到res_eat.conf文件，然后根據(jù)hangzhou讀取相應字段 下的關鍵值得到資源地址hangzhou_eat.com。

類似的，{res_sleep:hanghzhou}從配置文件

中讀取到資源地址hangzhou_sleep.com。

步驟130，以所述配置文件為基礎，在各錨點位置代入相應配置參數(shù)生成完全狀態(tài)的第一配置文件。

因為由配置模板中的錨點分別從上述定位配置文件、功能配置文件以及各資源配置文件中讀取了相應的配置參數(shù)，那么本申請實施例中將相應的配置參數(shù)替換相應的錨點，然后調用配置文件生成邏輯，即可有上述.tpl格式的文件生成.config格式的第一配置文件。

在本申請另一優(yōu)選的實施例中，步驟130包括子步驟131：

子步驟131，以所述配置文件為基礎，在定位錨點代入定位標識、在功能錨點代入功能開關標識、在資源錨點代入資源地址，以生成完全狀態(tài)的第一配置文件。

根據(jù)步驟120中得到的配置文件，配置模版中在錨點位置讀取相應配置文件中的參數(shù)值，如下例所示：

module.tpl

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

}

然后基于上述替換完錨點的模板生成第一配置文件如下示例

module.config

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1

}

該配置文件則為一個完全狀態(tài)的配置文件，服務器可以根據(jù)該配置文件運行相應的程序。

本申請實施例，可以將集群的配置文件的創(chuàng)建按運維與開發(fā)兩方的參與度，分為了由運維人員管理的定位配置文件和功能配置文件、由開發(fā)人員管理的資源配置文件和配置模板。該定位配置文件提供了該服務器所處位置的配置參數(shù)，功能配置文件提供了指示服務器是否需要某項功能的配置參數(shù)，對于每項功能本申請為其設置了相應的資源配置文件，該資源配置文件中提供了各種服務器在所處位置所需求的資源的配置參數(shù)；該配置模板以完整的配置文件為基礎，將其中與所有變量相關的部分采用錨點進行標記。因此本申請對于配置模板，可以分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)，然后基于獲取到的配置參數(shù)生成完全狀態(tài)的第一配置文件。服務器在使用時則可以直接讀取該第一配置文件執(zhí)行相應的功能。

因此，首先：本申請將配置文件的創(chuàng)建所需內容按照運維人員與研發(fā)人員分離，運維人員和研發(fā)人員的溝通代價大大減少，在定位配置文件和功能配置文件不需要變更的情況下，研發(fā)人員甚至不需要和運維人員溝通即可通過更新配置模板實現(xiàn)系統(tǒng)的升級。

其次，本申請可以由集群中的服務器自身實現(xiàn)完全狀態(tài)的第一配置文件的生成過程，因此，可以實現(xiàn)各個服務器管理自身的配置文件，不依賴第三方系統(tǒng)去創(chuàng)建完整的配置文件，配置文件實現(xiàn)了分布式管理，集群中的一個 服務器崩潰，并不影響其他服務器的配置文件的管理，提高了容災能力。

再次，本申請只需要定位配置文件、功能配置文件和資源配置文件三者分發(fā)到該服務器中，就可以根據(jù)配置模板自動生成配置文件。因此，本申請的配置文件的生成過程，降低了人工參與度，服務器具備自我識別能力，可以自動生成配置文件。

實施例二

參照圖2，示出了本申請的一種配置管理方法實施例的步驟流程圖，具體可以包括如下步驟：

步驟210，獲取各資源配置文件，以及屬于當前云服務器所在集群的定位配置文件、功能配置文件；其中，每個資源配置文件中的各資源地址與各集群的定位配置文件中的定位標識作為關鍵字段；所述功能配置文件中的功能關鍵字段采用各資源配置文件的名稱；

本申請實施例可以應用于混合云集群的環(huán)境下。該種情況下，由于存在多個集群，而實際上每個集群都有自己的定位標識，個性化的功能需求，而在新建集群時，定位標識和個性化功能需求都已經(jīng)確定，那么運維只需要設定該集群的定位配置文件和功能配置文件，然后分發(fā)到該集群即可。

在實際應用中，運維人員可以對定位配置文件和功能配置文件與集群地址綁定，然后將其上傳至調度服務器。調度服務器則根據(jù)該地址，將該定位配置文件和功能配置文件傳輸至該地址相應的集群的各臺服務器中。

當然，實際應用中，功能配置文件中可以將混合云集群的所有功能的關鍵字段進行配置，然后對于當前集群，需要的功能則將其關鍵值設置為yes，不需要的功能關鍵值設置為no。

另外，對于混合云集群，其功能是對所有集群開放的。因此對于資源配置文件，可以全局發(fā)送到各個集群的服務器中。

其中資源配置文件，定位配置文件、功能配置文件的具體原理類似前述實施例一的步驟100中的描述，在此不再贅敘。

步驟220，接收由調度服務器向各集群分發(fā)的配置模板；其中，分發(fā)給各集群的配置模板相同；

對于研發(fā)人員來說，由于運維在功能配置文件中設置了各個各集群自身需要的功能的功能開關，因此研發(fā)人員的配置模板可以使用同一個配置模板，將其上傳至調度服務器。各集群的服務器接收調度服務器分發(fā)的配置模板后，各服務器根據(jù)功能配置文件中的配置打開或者關閉相應功能。

步驟220是實施例一的步驟110的優(yōu)選的步驟。

步驟230，根據(jù)所述配置模板中的定位錨點從定位配置文件獲取定位標識；

步驟240，根據(jù)所述配置模板中的功能錨點從功能配置文件中獲取功能開關標識；

步驟250，根據(jù)所述配置模板中的資源錨點以及定位標識從資源配置文件中獲取資源地址；所述資源錨點中包括定位錨點；

步驟220-步驟250是實施例一的步驟120的優(yōu)選的步驟。

步驟260，以所述配置文件為基礎，在定位錨點代入定位標識、在功能錨點代入功能開關標識、在資源錨點代入資源地址，以生成完全狀態(tài)的第一配置文件。

步驟260是實施例一的步驟130的優(yōu)選的步驟。

步驟270，調用所述第一配置文件時，若檢查到第一配置文件中的任一功能的功能開關字段的功能開關標識表示禁止使用，則停止執(zhí)行所述功能的相關邏輯。

如實施例一中最后得到的第一配置文件：

module.config

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1,

}

服務器啟用程序后，加載第一配置文件后解析，如果某個功能的功能開關字段的關鍵值為yes，則該服務器可以調用該功能，從相應的資源地址調用相應的資源執(zhí)行。而如果某個功能的功能開關字段的關鍵值為no，則禁止該服務器使用該功能，則與該功能相關的代碼，服務器可以忽略。

比如上述示例中，eat功能的is_eat為yes，那么服務器可以執(zhí)行eat的后續(xù)代碼：

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com，

而sleep功能的is_sleep為no，那么服務器則不再執(zhí)行sleep相關的代碼：

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1

在本申請一優(yōu)選的實施例中，在步驟260之后，還包括步驟s11-s12：

步驟s11，判斷功能配置文件是否更新；

步驟s12，如果功能配置文件更新，則進入根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)的步驟。

在本申請實施例中，如果某個集群需要在原功能不變的情況下，也即各資源文件名不變的情況下，增加新的功能，那么可以由運維對功能配置文件進行修改，將相應功能的功能開關關鍵字段修改為yes。或者在原功能不變的情況下，刪減某些功能，那么可以由運維對功能配置文件進行修改，將相應功能的功能開關關鍵字段修改為no。

然后本申請實施例的運維人員則可以通知該集群進行升級，那么該集群中的服務器則判斷功能配置文件是否更新，如果功能配置文件更新，則進入步驟230，可以重新執(zhí)行第一配置文件的生成的步驟。

當然，在實施例一中，如果功能配置文件更新則進入步驟120。

在本申請一優(yōu)選的實施例，在步驟260之后，還包括步驟s21-步驟s22；

步驟s21，判斷所述配置模板是否更新；

步驟s22，如果所述配置模板更新，則進入根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)的步驟。

在本申請實施例中，一般情況下，各個集群的定位配置文件不會改變，功能配置文件也基本不變。而如果研發(fā)人員對原有的某些功能進行升級，比如對于身份驗證服務的功能，研發(fā)人員要添加驗證次數(shù)、時限等對該功能更豐富的執(zhí)行條件。由于其調用的該功能的資源地址不變。因此研發(fā)人員只需要修改配置模板，然后將配置模板上傳至調度服務器，由調度服務器分發(fā)至各集群?；蛘咧苯訉⑴渲媚０鍐为毶蟼髦疗渲付ǖ募海缓笱邪l(fā)人員可以通知集群升級。

相應集群的服務器在判斷配置模板被更新后，則可以進入步驟230，可以重新執(zhí)行第一配置文件的生成的步驟。

當然，在實施例一中，如果配置模板被更新，則進入步驟120。

在本申請一優(yōu)選的實施例，在在步驟260之后之后，還包括步驟s31-s32：

步驟s31，判斷所述功能配置文件記錄的各功能所對應資源配置文件是否更新；

步驟s32，如果所述功能配置文件記錄的各功能所對應資源配置文件更新，則進入根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)的步驟。

對于一種功能，如果其名稱不變，而其對應的資源地址變更，研發(fā)人員則可以修改相應的資源配置文件。然后將修改后的資源配置文件全局覆蓋所有集群服務器中原來的資源配置文件。

那么服務器判斷該資源配置文件被更新，則可以進入步驟230，可以重新執(zhí)行第一配置文件的生成的步驟。當然，在實施例一中，如果配置模板被更新，則進入步驟120。

當然，上述功能配置文件、配置模板、資源配置文件可以根據(jù)需要同時 更新、或者更新任意一個或幾個，如果判斷其中任意一個更新，則可以進入步驟230，可以重新執(zhí)行第一配置文件的生成的步驟。當然，在實施例一中，如果配置模板被更新，則進入步驟120。如果判斷全部未更新，則不進行任何操作。

當然，在本申請實施例中，各個服務器可以在本地記錄各種版本的定位配置文件、功能配置文件以及各資源配置文件、以及配置模板，方便出現(xiàn)錯誤時核查。

在大規(guī)?；旌显七\維中，最復雜的就是配置文件管理，其復雜在于，每一個集群都有自己的特殊標志，比如其需求的功能和定位標識，使用的資源也是各不相同，所以如果有n個集群，每個集群最多有m種特殊標志，然后每個集群特殊標志的組合可以有c(m，2)種。而所有的這些信息都存儲在配置文件里面，也就是配置文件的復雜度為n*m*c(m,2)，而其中任何一個出問題都會導致致命的故障，所以無論新建集群還是升級做方案的時候，都要考慮到這種復雜度。除了配置本身復雜，還有一個問題就是運維和研發(fā)的溝通成本問題，配置混合在一起，復雜度又高，造成了極大的運維研發(fā)溝通成本，所以降低復雜度就成為迫在眉睫的問題了。

而在先技術中使用的三種第三方系統(tǒng)：一個單獨的配置服務器、svn(subversion是一個開放源代碼的版本控制系統(tǒng))或者git(git是一款免費、開源的分布式版本控制系統(tǒng))、cmdb(configurationmanagementdatabase，配置管理數(shù)據(jù)庫)，其都存在運維人員與研發(fā)人員對配置文件的創(chuàng)建過程耦合度高；配置文件的管理集中在一個第三方系統(tǒng)中、導致運維的容災效果差；配置文件的管理過程人工參與度高，系統(tǒng)的自我識別能力差，配置文件的管理效率低等問題。

而本申請實施例首先：本申請將配置文件的創(chuàng)建所需內容按照運維人員與研發(fā)人員分離，運維人員和研發(fā)人員的溝通代價大大減少，在定位配置文件和功能配置文件不需要變更的情況下，研發(fā)人員甚至不需要和運維人員溝通即可通過更新配置模板實現(xiàn)系統(tǒng)的升級。

比如對于某個功能的資源開發(fā)者，其開發(fā)了新的資源，則只需要將新的 資源寫入相應功能的資源配置文件即可，無需運維的參與。

如果研發(fā)人員想要升級某個功能，只需要修改配置模板module.tpl、和/或者和res_*.conf即可，其中res_*.conf表示各種功能的資源配置文件，也無需運維的參與。

其次，本申請可以由集群中的服務器自身實現(xiàn)完全狀態(tài)的第一配置文件的生成過程，因此，可以實現(xiàn)各個服務器管理自身的配置文件，不依賴第三方系統(tǒng)去創(chuàng)建完整的配置文件，配置文件實現(xiàn)了分布式管理，集群中的一個服務器崩潰，并不影響其他服務器的配置文件的管理，提高了容災能力。

再次，本申請只需要定位配置文件、功能配置文件和資源配置文件三者分發(fā)到該服務器中，就可以根據(jù)配置模板自動生成配置文件。因此，本申請的配置文件的生成過程，降低了人工參與度，服務器具備自我識別能力，可以自動生成配置文件。

比如前述如果研發(fā)人員想要升級某個功能，其修改配置模板module.tpl、和/或者和res_*.conf即可，那么服務器會自動抓取其中的who.conf和switch.conf的信息，然后結合module.tpl和res_*.conf，自動生成真正的第一配置文件，實現(xiàn)了在低人工參與度的情況下，集群自動升級過程。

最后，由于使用了功能配置文件switch.config，新增了功能開關，通過功能使各個集群可以配置不同的功能，從而使用同一份配置模板，可以供各個集群使用，降低了配置模板的數(shù)量，無需為每個集群創(chuàng)建一份模板。

需要說明的是，對于方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本申請實施例并不受所描述的動作順序的限制，因為依據(jù)本申請實施例，某些步驟可以采用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬于優(yōu)選實施例，所涉及的動作并不一定是本申請實施例所必須的。

實施例三

參照圖3，示出了本申請的一種云集群能自識別的分布配置管理裝置實施例的結構框圖，具體可以包括如下模塊：

模板接收模塊310，用于接收配置模板；

配置參數(shù)獲取模塊320，用于根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)；

配置文件生成模塊330，用于以所述配置文件為基礎，在各錨點位置代入相應配置參數(shù)生成完全狀態(tài)的第一配置文件。

在本申請一優(yōu)選的實施例中，所述配置參數(shù)獲取模塊320，包括：

定位標識獲取子模塊，用于根據(jù)所述配置模板中的定位錨點從定位配置文件獲取定位標識；

開關標識獲取子模塊，用于根據(jù)所述配置模板中的功能錨點從功能配置文件中獲取功能開關標識；

資源地址獲取子模塊，用于根據(jù)所述配置模板中的資源錨點以及定位標識從資源配置文件中獲取資源地址；所述資源錨點中包括定位錨點。

在本申請一優(yōu)選的實施例中，所述配置文件生成模塊330，包括：

第一配置文件生成子模塊，用于以所述配置文件為基礎，在定位錨點代入定位標識、在功能錨點代入功能開關標識、在資源錨點代入資源地址，以生成完全狀態(tài)的第一配置文件。

在本申請一優(yōu)選的實施例中，所述配置模板包括：

各功能的功能開關關鍵字段、功能名稱關鍵字段、功能資源關鍵字段；其中，所述定位錨點在功能名稱關鍵字段的關鍵值中以及資源錨點中，所述功能錨點在所述功能開關字段的關鍵值中，所述資源錨點在所述功能資源關鍵字段的關鍵值中。

在本申請一優(yōu)選的實施例中，在模板接收模塊310之前，還包括：

配置文件獲取模塊，用于獲取各資源配置文件，以及屬于當前云服務器所在集群的定位配置文件、功能配置文件；其中，每個資源配置文件中的各資源地址與各集群的定位配置文件中的定位標識作為關鍵字段；所述功能配置文件中的功能關鍵字段采用各資源配置文件的名稱。

本申請實施例，可以將集群的配置文件的創(chuàng)建按運維與開發(fā)兩方的參與 度，分為了由運維人員管理的定位配置文件和功能配置文件、由開發(fā)人員管理的資源配置文件和配置模板。該定位配置文件提供了該服務器所處位置的配置參數(shù)，功能配置文件提供了指示服務器是否需要某項功能的配置參數(shù)，對于每項功能本申請為其設置了相應的資源配置文件，該資源配置文件中提供了各種服務器在所處位置所需求的資源的配置參數(shù)；該配置模板以完整的配置文件為基礎，將其中與所有變量相關的部分采用錨點進行標記。因此本申請對于配置模板，可以分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)，然后基于獲取到的配置參數(shù)生成完全狀態(tài)的第一配置文件。服務器在使用時則可以直接讀取該第一配置文件執(zhí)行相應的功能。

因此，首先：本申請將配置文件的創(chuàng)建所需內容按照運維人員與研發(fā)人員分離，運維人員和研發(fā)人員的溝通代價大大減少，在定位配置文件和功能配置文件不需要變更的情況下，研發(fā)人員甚至不需要和運維人員溝通即可通過更新配置模板實現(xiàn)系統(tǒng)的升級。

其次，本申請可以由集群中的服務器自身實現(xiàn)完全狀態(tài)的第一配置文件的生成過程，因此，可以實現(xiàn)各個服務器管理自身的配置文件，不依賴第三方系統(tǒng)去創(chuàng)建完整的配置文件，配置文件實現(xiàn)了分布式管理，集群中的一個服務器崩潰，并不影響其他服務器的配置文件的管理，提高了容災能力。

再次，本申請只需要定位配置文件、功能配置文件和資源配置文件三者分發(fā)到該服務器中，就可以根據(jù)配置模板自動生成配置文件。因此，本申請的配置文件的生成過程，降低了人工參與度，服務器具備自我識別能力，可以自動生成配置文件。

實施例四

參照圖4，示出了本申請的一種云集群能自識別的分布配置管理裝置實施例的結構框圖，具體可以包括如下模塊：

配置文件獲取模塊400，用于獲取各資源配置文件，以及屬于當前云服務器所在集群的定位配置文件、功能配置文件；其中，每個資源配置文件中的各資源地址與各集群的定位配置文件中的定位標識作為關鍵字段；所述功 能配置文件中的功能關鍵字段采用各資源配置文件的名稱。

模板接收模塊410，用于接收配置模板，具體包括：

第一模板接收模塊411，用于接收由調度服務器向各集群分發(fā)的配置模板；其中，分發(fā)給各集群的配置模板相同

配置參數(shù)獲取模塊420，用于配置參數(shù)獲取模塊，用于根據(jù)所述配置模板的各錨點，分別從定位配置文件、功能配置文件以及各資源配置文件中讀取與各錨點對應的配置參數(shù)，具體包括：

定位標識獲取子模塊421，用于根據(jù)所述配置模板中的定位錨點從定位配置文件獲取定位標識；

開關標識獲取子模塊422，用于根據(jù)所述配置模板中的功能錨點從功能配置文件中獲取功能開關標識；

資源地址獲取子模塊423，用于根據(jù)所述配置模板中的資源錨點以及定位標識從資源配置文件中獲取資源地址；所述資源錨點中包括定位錨點。

配置文件生成模塊430，用于以所述配置文件為基礎，在各錨點位置代入相應配置參數(shù)生成完全狀態(tài)的第一配置文件，具體包括：

第一配置文件生成子模塊431，用于以所述配置文件為基礎，在定位錨點代入定位標識、在功能錨點代入功能開關標識、在資源錨點代入資源地址，以生成完全狀態(tài)的第一配置文件。

調用模塊440，用于調用所述第一配置文件時，若檢查到第一配置文件中的任一功能的功能開關字段的功能開關標識表示禁止使用，則停止執(zhí)行所述功能的相關邏輯。

在本申請一優(yōu)選的實施例中，在配置文件生成模塊430之后，還包括：

功能配置文件檢測更新模塊，用于判斷功能配置文件是否更新；如果功能配置文件更新，則進入配置參數(shù)獲取模塊420。

在本申請一優(yōu)選的實施例中，在配置文件生成模塊430之后，還包括：

檢測配置模板更新模塊，用于判斷所述配置模板是否更新；如果所述配置模板更新，則進入配置參數(shù)獲取模塊420。

在本申請一優(yōu)選的實施例中，在配置文件生成模塊430之后，還包括：

資源配置文件檢測更新模塊，用于判斷所述功能配置文件記錄的各功能所對應資源配置文件是否更新；如果所述功能配置文件記錄的各功能所對應資源配置文件更新，則進入配置參數(shù)獲取模塊420。

本申請實施例首先：本申請將配置文件的創(chuàng)建所需內容按照運維人員與研發(fā)人員分離，運維人員和研發(fā)人員的溝通代價大大減少，在定位配置文件和功能配置文件不需要變更的情況下，研發(fā)人員甚至不需要和運維人員溝通即可通過更新配置模板實現(xiàn)系統(tǒng)的升級。

比如對于某個功能的資源開發(fā)者，其開發(fā)了新的資源，則只需要將新的資源寫入相應功能的資源配置文件即可，無需運維的參與。

如果研發(fā)人員想要升級某個功能，只需要修改配置模板module.tpl、和/或者和res_*.conf即可，其中res_*.conf表示各種功能的資源配置文件，也無需運維的參與。

其次，本申請可以由集群中的服務器自身實現(xiàn)完全狀態(tài)的第一配置文件的生成過程，因此，可以實現(xiàn)各個服務器管理自身的配置文件，不依賴第三方系統(tǒng)去創(chuàng)建完整的配置文件，配置文件實現(xiàn)了分布式管理，集群中的一個服務器崩潰，并不影響其他服務器的配置文件的管理，提高了容災能力。

再次，本申請只需要定位配置文件、功能配置文件和資源配置文件三者分發(fā)到該服務器中，就可以根據(jù)配置模板自動生成配置文件。因此，本申請的配置文件的生成過程，降低了人工參與度，服務器具備自我識別能力，可以自動生成配置文件。

比如前述如果研發(fā)人員想要升級某個功能，其修改配置模板module.tpl、和/或者和res_*.conf即可，那么服務器會自動抓取其中的who.conf和switch.conf的信息，然后結合module.tpl和res_*.conf，自動生成真正的第一配置文件，實現(xiàn)了在低人工參與度的情況下，集群自動升級過程。

最后，由于使用了功能配置文件switch.config，新增了功能開關，通過功能使各個集群可以配置不同的功能，從而使用同一份配置模板，可以供各個集群使用，降低了配置模板的數(shù)量，無需為每個集群創(chuàng)建一份模板。

對于裝置實施例而言，由于其與方法實施例基本相似，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。

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

本領域內的技術人員應明白，本申請實施例的實施例可提供為方法、裝置、或計算機程序產(chǎn)品。因此，本申請實施例可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本申請實施例可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產(chǎn)品的形式。

在一個典型的配置中，所述計算機設備包括一個或多個處理器(cpu)、輸入/輸出接口、網(wǎng)絡接口和內存。內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內存等形式，如只讀存儲器(rom)或閃存(flashram)。內存是計算機可讀介質的示例。計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結構、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質的例子包括，但不限于相變內存(pram)、靜態(tài)隨機存取存儲器(sram)、動態(tài)隨機存取存儲器(dram)、其他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(cd-rom)、數(shù)字多功能光盤(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括非持續(xù)性的電腦可讀媒體(transitorymedia)，如調制的數(shù)據(jù)信號和載波。

本申請實施例是參照根據(jù)本申請實施例的方法、終端設備(系統(tǒng))、和計 算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理終端設備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理終端設備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(shù)據(jù)處理終端設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理終端設備上，使得在計算機或其他可編程終端設備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程終端設備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

盡管已描述了本申請實施例的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例做出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本申請實施例范圍的所有變更和修改。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者終端設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者終端設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者終 端設備中還存在另外的相同要素。

以上對本申請所提供的一種配置管理方法和一種配置管理裝置，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據(jù)本申請的思想，在具體實施方式及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。