本申請涉及互聯網技術領域，更具體地說，涉及一種資源配置方法及裝置。

背景技術：

隨著互聯網的發(fā)展，各種類型的應用也如雨后春筍般出現，為用戶提供了多樣化的網絡業(yè)務，如視頻業(yè)務、游戲業(yè)務、網絡直播業(yè)務等等，極大的豐富了用戶的生活。

對于某一業(yè)務而言，隨著業(yè)務的運營以及時間變化，業(yè)務所需的資源配置會產生變化。如一款新上線的業(yè)務，隨著業(yè)務發(fā)展其在線用戶數量會逐漸上升，導致業(yè)務所需的資源配置會增加，此時需要重新調整業(yè)務所在容器的資源配置?，F有技術中，需要人工依據經驗決定是否需要對業(yè)務所在容器的資源配置進行調整，以及人工確定調整后的目標資源配置。

顯然，現有技術人工決定是否調整資源配置以及確定調整后目標資源配置的方式存在準確度低、浪費人工成本的問題。

技術實現要素：

有鑒于此，本申請?zhí)峁┝艘环N資源配置方法及裝置，用于解決現有技術人工決定是否調整資源配置以及確定調整后目標資源配置的方式存在準確度低、浪費人工成本的問題。

為了實現上述目的，現提出的方案如下：

一種資源配置方法，包括：

獲取目標業(yè)務程序所在容器的資源占用率信息；

根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；

若是，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；

將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

一種資源配置裝置，包括：

資源占用信息獲取單元，用于獲取目標業(yè)務程序所在容器的資源占用率信息；

調整判斷單元，用于根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；

目標資源配置確定單元，用于在所述調整判斷單元的判斷結果為是時，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；

資源配置調整單元，用于將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

本申請實施例提供的資源配置方法，獲取目標業(yè)務程序所在容器的資源占用率信息；根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；若是，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。本申請通過監(jiān)控獲取目標業(yè)務程序所在容器的資源占用率信息，結合運營策劃數據，能夠確定是否需要調整目標業(yè)務程序所在容器的資源配置，并在確定為是時利用資源占用率信息以及運營策劃數據確定所要調整至的目標資源配置，相比于人工依據經驗進行判斷的方式其準確度得到了很大的提升，且節(jié)省了大量的人力成本。

附圖說明

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

圖1為本申請實施例公開的一種硬件架構示意圖；

圖2為本申請實施例公開的一種資源配置方法流程圖；

圖3為本申請示例的客戶端與Cgroup交互示意圖；

圖4為本申請實施例公開的另一種資源配置方法流程圖；

圖5為本申請示例的一種容器縮容過程示意圖；

圖6為本申請實施例公開的又一種資源配置方法流程圖；

圖7為本申請實施例公開的一種資源配置裝置結構示意圖；

圖8為本申請實施例公開的一種控制中心硬件結構示意圖。

具體實施方式

下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

在介紹本申請方案之前，首先對業(yè)務程序的運行過程進行簡單介紹。

業(yè)務程序運行在容器中，一個業(yè)務程序可以對應一個或多個容器。容器位于容器集群中，一個容器集群包括眾多業(yè)務程序的容器。集群對應一資源池，為其內各個容器提供資源。一般性的，在生成業(yè)務程序之后，即為業(yè)務程序所在的各個容器配置資源標準，舉例如，為一個業(yè)務程序所在的每一個容器均配置10核CPU、50G內存等。在對業(yè)務程序所在容器的資源配置進行調整時，即調整業(yè)務程序所在每一容器的資源配置，舉例如，將某一業(yè)務程序所在的每一容器的內存下調50％。

首先介紹本申請方案的實施硬件架構，參見圖1，圖1為本申請實施例公開的一種硬件架構示意圖，如圖1所示，包括：

控制中心1和集群性能監(jiān)控模塊2，其中：

集群性能監(jiān)控設備2用于對集群內各容器進行監(jiān)控，監(jiān)控數據可以包括資源占用率信息等。

集群性能監(jiān)控設備2將監(jiān)控到的數據發(fā)送給控制中心1，由控制中心1根據監(jiān)控數據以及業(yè)務運營策劃數據，確定是否需要調整業(yè)務的資源配置，并在確定需要調整業(yè)務的資源配置時，按照計算出的目標資源配置進行調整。

其中，集群性能監(jiān)控模塊2可以是進程組資源管理系統(tǒng)Cgroup，其能夠對集群中各個業(yè)務的容器進行實時監(jiān)控。

控制中心1可以是一臺服務器，或者是多臺服務器組成的服務器集群。

接下來，本申請從控制中心的角度對本申請的資源配置方法進行介紹，參見圖2。如圖2所示，該方法包括：

步驟S200、獲取目標業(yè)務程序所在容器的資源占用率信息；

具體地，隨著業(yè)務發(fā)展以及運營策略的變化，目標業(yè)務的在線訪問數量會產生變化，導致目標業(yè)務程序所在容器的資源占用情況會發(fā)生變化。本步驟中，獲取目標業(yè)務程序所在容器的資源占用信息。具體的獲取策略可以是實時獲取，也可以是每隔設定時間獲取一次。獲取的資源占用率信息可以包括目標業(yè)務程序所在容器的歷史資源占用率信息以及當前時刻的資源占用率信息。

步驟S210、根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；若是，執(zhí)行步驟S220；

具體地，目標業(yè)務程序的運營策劃數據可以包括目標業(yè)務程序的近期活動，如在線時間滿足條件即贈送業(yè)務內虛擬資源等。運行策劃數據可以用于預測目標業(yè)務程序的在線訪問數量。

具體地，可以預先設置資源調整條件，如分別設置資源擴容條件和資源縮容條件，根據目標業(yè)務程序所在容器的資源占用率信息以及運營策劃數據，確定是否滿足設定的資源調整條件，在確定滿足時，即認定需要調整所述目標業(yè)務程序所在容器的資源配置，否則，認定不需要調整所述目標業(yè)務程序所在容器的資源配置。

步驟S220、利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；

具體地，本申請可以預先設定資源配置調整策略，如針對不同的資源設置不同的調整策略，進而根據資源調整策略，以及所述資源占用率信息、所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置。

其中可選的，資源配置可以包括CPU占用情況、內存占用情況、磁盤空間占用情況等。

步驟S230、將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

具體地，本申請可以在不需要目標業(yè)務程序暫停服務的情況下，實現在線對容器資源配置進行調整，避免業(yè)務停服給用戶帶來的負面影響。

本申請實施例提供的資源配置方法，獲取目標業(yè)務程序所在容器的資源占用率信息；根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；若是，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。本申請通過監(jiān)控獲取目標業(yè)務程序所在容器的資源占用率信息，結合運營策劃數據，能夠確定是否需要調整目標業(yè)務程序所在容器的資源配置，并在確定為是時利用資源占用率信息以及運營策劃數據確定所要調整至的目標資源配置，相比于人工依據經驗進行判斷的方式其準確度得到了很大的提升，且節(jié)省了大量的人力成本。

可選的，本申請獲取目標業(yè)務程序所在容器的資源占用率信息的過程，以及調整目標目標業(yè)務程序所在容器的資源配置的過程，均可以通過進程組資源管理系統(tǒng)Cgroup實現。

參見圖3，圖3為本申請示例的客戶端與Cgroup交互示意圖。

其中，客戶端為控制中心1的客戶端，Docker API為容器引擎接口，通過Docker API可以訪問Cgroup。Cgroup能夠實時對集群中各個容器的性能進行監(jiān)控。

本申請獲取目標業(yè)務程序所在容器的資源占用率信息的過程可以包括：

客戶端調用Docker API訪問Cgroup，以讀取所述Cgroup對所述目標業(yè)務程序所在容器的監(jiān)控數據，所述監(jiān)控數據可以包括資源占用率信息。

本申請將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置的過程可以包括：

客戶端調用Docker API訪問Cgroup，以通過所述Cgroup將所述目標業(yè)務程序所在容器的資源配置更改為所述目標資源配置。

本申請通過Cgroup實現容器的資源配置在線更改，不影響業(yè)務的正常服務。

在本申請的另一個實施例中，介紹另一種資源配置方法，參見圖4。

如圖4所示，該方法包括：

步驟S400、獲取目標業(yè)務程序所在容器的資源占用率信息；

步驟S410、根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否滿足設定的資源調整條件；若是，執(zhí)行步驟S420；

具體地，本申請可以預先設定資源調整條件，如設置資源擴容條件和資源縮容條件。在根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定滿足資源擴容條件或資源縮容條件時，確定需要調整目標業(yè)務程序所在容器的資源配置，否則，確定不需要調整所述目標業(yè)務程序所在容器的資源配置。

可以理解的是，若確定滿足資源擴容條件，則需要上調目標業(yè)務程序所在容器的資源配置；若確定滿足資源縮容條件，則需要下調目標業(yè)務程序所在容器的資源配置。

步驟S420、根據所述目標業(yè)務程序的運營策劃數據，預測所述目標業(yè)務程序的在線訪問數量；

具體地，通過目標業(yè)務程序的運營策劃數據可以預測未來一段時間內目標業(yè)務程序的在線訪問數量。舉例如，目標業(yè)務程序為一款游戲，游戲運營商策劃了一個游戲活動：國慶七天假期內，每天在線5小時以上獎勵游戲內道具。則基于該運營策劃數據可以預測，國慶七天假期內游戲在線訪問數量將會得到提升，并基于游戲當前的在線訪問數量，可以預測游戲在國慶七天假期內的在線訪問數量。

步驟S430、根據所述目標業(yè)務程序當前的在線訪問數量、所述目標業(yè)務程序當前的資源占用率信息以及預測得到的在線訪問數量，計算目標資源配置；

具體地，在預測得到目標業(yè)務程序的在線訪問數量之后，根據目標業(yè)務程序當前的在線訪問數量、目標業(yè)務程序當前的資源占用率信息以及預測得到的在線訪問數量，可以計算出目標資源配置，該目標資源配置為與預測得到的目標業(yè)務程序的在線訪問數量對應的資源配置量。

以一個簡單的例子進行說明：

游戲A當前的在線訪問數量為1萬，游戲A的容器內存分配大小為5G，且當前內存占用率為50％，結合游戲A的運營策略數據預測得到未來一段時間內游戲A的在線訪問數量將會達到2萬，為了保證游戲A的容器內存占用率始終不超過50％，則可以將游戲A的容器內存分配大小增加一倍，即目標內存大小為10G。

步驟S440、將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

可選的，若上述步驟S410中確定滿足資源擴容條件，則在步驟S430計算得到目標資源配置之后，該方法還可以進一步增加：

判斷所述目標業(yè)務程序所在容器所位于的目標容器集群的剩余資源量，是否滿足所述目標資源配置，若是，則執(zhí)行步驟S440。

其中，容器以集群形式存在，一個集群中設置有多個不同業(yè)務程序的容器。容器的總資源量是固定的，在確定滿足資源擴容條件時，若目標業(yè)務程序所在容器所位于的目標容器集群的剩余資源量不滿足所述目標資源配置，也即剩余資源量不夠目標資源配置，則無法進行擴容。

進一步可選的，在上述實施例的基礎上，本申請還可以增加校驗機制，即在步驟S440，將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置之后，增加如下步驟：

獲取所述目標業(yè)務程序所在容器的最新資源配置；

利用所述目標資源配置對所述最新資源配置進行校驗。

具體地，在對目標業(yè)務程序所在容器的資源配置進行調整之后，為了檢測是否成功進行調整，本申請可以進一步獲取目標業(yè)務程序所在容器的最新資源配置，并判斷該最新資源配置是否與目標資源配置相同，如果相同，則代表校驗通過，否則，代表校驗不通過。

通過增加校驗機制，保證資源調整順利執(zhí)行。

在本申請的又一個實施例中，以容器縮容過程為實例，對方案進行介紹。

參照圖5進行說明：

其中，集群A中包含眾多的容器，圖5中示例的兩列容器A1對應目標業(yè)務1所在的容器。針對目標業(yè)務1的每一容器的CPU占用量、內存MEM占用量、磁盤DISK占用量三個指標進行實時監(jiān)控。

某一時刻確定目標業(yè)務1所在的每一容器的資源配置情況如下：CPU占用X(core顆)、內存MEM占用Y(G)、磁盤DISK占用Z(G)。根據資源配置情況，以及通過目標業(yè)務1的運營策劃數據預測出的在線訪問數量，判斷滿足資源縮容條件，并計算縮容后的目標資源配置為當前資源配置的一半。調用容器引擎接口Docker API訪問進程組資源管理系統(tǒng)Cgroup，以通過所述Cgroup對容器A1的資源配置進行調整，調整后資源配置情況如下：CPU占用X/2(core顆)、內存MEM占用Y/2(G)、磁盤DISK占用Z/2(G)。

為了保證調整成功，可以增加校驗過程，即獲取調整后容器A1的資源配置，并與目標資源配置進行對比。

按照本實施例的調整方案，在確定目標業(yè)務滿足資源縮容條件時可以在線調整目標業(yè)務所在容器的資源配置，縮容得出的資源可以供該集群A中其它業(yè)務使用。

接下來，本申請分別對內存、CPU、磁盤三種資源的調整過程進行介紹。

第一、內存調整策略

在介紹內存調整之前首先介紹Cgroup關于內存的幾個統(tǒng)計參數：

(1)、cache緩存：包括了file cache文件緩存和shm共享內存

(2)、anon_LRU：對應Cgroup中的inactive_anon\active_anon，包括了anon匿名頁和shm共享內存

(3)、file_LRU：對應Cgroup中的inactive_file\active_file，包括file cache

(4)、rss：包括anon匿名頁

(5)、swap交換空間內存

其中，cache+rss＝anon_LRU+file_LRU。

anon+shm+swap這部分內存代表了正在使用，不能被釋放。而file cache，如果在內存足夠情況下，這部分內存不會釋放，但可以被回收，所以降內存只能針對這部分。

基于此，上述步驟S430，根據所述目標業(yè)務程序當前的在線訪問數量、所述目標業(yè)務程序當前的資源占用率信息以及預測得到的在線訪問數量，計算目標資源配置的過程可以包括：

根據所述目標業(yè)務程序當前的在線訪問數量、所述目標業(yè)務程序當前的內存占用率信息以及預測得到的在線訪問數量，計算擴/縮容比例；

將非活動文檔內存inactive_file與所述擴/縮容比例的乘積、活動匿名頁內存active_anon、非活動匿名頁內存inactive_anon、交換空間內存swap、活動文檔內存active_file的和值確定為目標內存大小，即目標內存大小：

target_value＝inactive_anon+active_anon+swap+active_file+inactive_file*X％

其中X％為擴/縮容比例。舉例如，X可以是30，對應縮容比例。

第二、CPU調整策略

CPU擴縮容以物理核為單位，CPU縮容過程比較簡單，在計算出目標CPU核數之后，將目標業(yè)務程序所在容器的CPU占用數量減少至目標CPU核數即可。本實施例中重點介紹CPU擴容過程。

在CPU擴容過程中，需要考慮CPU的NUMA((Non Uniform Memory Access Architecture))分布，盡量保證同一業(yè)務程序所在容器占用的CPU在同一NUMA節(jié)點。

基于此，在確定滿足擴容條件并計算得到目標CPU核數之后，步驟S440，將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置的過程可以包括：

S1、根據所述目標CPU核數以及所述目標業(yè)務程序所在容器當前占用的CPU核數，計算二者的差值；

S2、獲取每個NUMA節(jié)點中空閑CPU的下標和個數；

S3、判斷所述目標業(yè)務程序所在容器當前占用的CPU所在的節(jié)點中空閑CPU個數是否不小于所述差值；若是，執(zhí)行步驟S4；

S4、在所述目標業(yè)務程序所在容器當前占用的CPU所在的節(jié)點中的空閑CPU中，為所述目標業(yè)務程序所在容器增加分配所述差值個數的CPU。

為了便于理解，通過下述實例進行說明：

假設共存在2個node節(jié)點，每個node有12個物理核，支持超線程，所以存在24個邏輯核。其中CPU 0-11，24-35在node0，CPU 12-23,36-47在node1。且CPU0-6已經被目標業(yè)務程序所在容器占用。

假設目標CPU為12核，目標業(yè)務程序所在容器當前占用的CPU核數為6，且該6核CPU分別為CPU0-6。

計算差值12-6＝6，代表還需要額外為目標業(yè)務程序所在容器分配6核CPU。

按照上述分配原則，在node0上查找6個空閑CPU：7-11，24。則為目標業(yè)務程序增加分配的CPU的下標為：7-11和24。

第三、磁盤調整策略

磁盤的擴縮容相比于CPU和內存要簡單，通過系統(tǒng)提供的xfs的project quota功能可動態(tài)調整磁盤的限制空間。

這里需要注意的是，如果是判斷滿足資源縮容條件，則在計算出目標磁盤大小之后可以進一步計算目標業(yè)務程序所在容器的當前磁盤占用量與目標磁盤大小的比例，并判斷該比例是否超過設定比例閾值，如70％，若判斷超過，則可以將目標磁盤大小調大，以保證該比例不超過設定比例閾值。

通過這種機制，可以保證磁盤縮容之后仍存在足夠的剩余磁盤空間，以應對目標業(yè)務程序突發(fā)的磁盤占用。

基于上述各實施例介紹的資源配置過程以及內存、CPU、磁盤調整策略，本申請實施例提供了一種完整的資源配置方法，參見圖6，圖6為本申請實施例公開的又一種資源配置方法流程圖。

如圖6所示，該方法包括：

步驟S600、獲取目標業(yè)務程序在線擴縮容需求；

步驟S610、判斷需要擴容或縮容；在確定需要進行縮容時，執(zhí)行步驟S620-S660，在確定需要進行擴容時，執(zhí)行步驟S670-S680。

具體地，根據目標業(yè)務程序所在容器的資源占用率信息，以及目標業(yè)務程序的運營策劃數據，判斷出需要對目標業(yè)務程序所在容器進行擴容或縮容。

步驟S620、按照CPU調整策略計算目標CPU大??；

步驟S630、按照內存調整策略計算目標內存大??；

步驟S640、按照磁盤調整策略計算目標磁盤大?。?/p>

其中，步驟S620-S640的執(zhí)行順序并不限定，可以相互顛倒或同時執(zhí)行。具體調整策略可以參照上文相關介紹。

步驟S650、執(zhí)行在線縮容；

具體地，按照計算出的目標CPU大小、目標內存大小、目標磁盤大小，對目標業(yè)務程序所在容器的資源配置進行縮容調整。

步驟S660、結果校驗；

在縮容調整之后進行結果校驗，校驗過程可以參照上文相關介紹。

步驟S670、判斷集群剩余資源是否足夠，若是，執(zhí)行步驟S680；

具體地，在執(zhí)行該步驟時也需要先計算出擴容后的目標CPU大小、目標內存大小、目標磁盤大小，并判斷集群剩余資源是否支持擴容需求。

步驟S680、執(zhí)行在線擴容，并進一步執(zhí)行步驟S660。

下面對本申請實施例提供的資源配置裝置進行描述，下文描述的資源配置裝置與上文描述的資源配置方法可相互對應參照。

參見圖7，圖7為本申請實施例公開的一種資源配置裝置結構示意圖。

如圖7所示，該裝置包括：

資源占用信息獲取單元11，用于獲取目標業(yè)務程序所在容器的資源占用率信息；

調整判斷單元12，用于根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；

目標資源配置確定單元13，用于在所述調整判斷單元的判斷結果為是時，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；

資源配置調整單元14，用于將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

本申請通過監(jiān)控獲取目標業(yè)務程序所在容器的資源占用率信息，結合運營策劃數據，能夠確定是否需要調整目標業(yè)務程序所在容器的資源配置，并在確定為是時利用資源占用率信息以及運營策劃數據確定所要調整至的目標資源配置，相比于人工依據經驗進行判斷的方式其準確度得到了很大的提升，且節(jié)省了大量的人力成本。

可選的，所述資源占用信息獲取單元具體可以用于，調用容器引擎接口Docker API訪問進程組資源管理系統(tǒng)Cgroup，以讀取所述Cgroup對所述目標業(yè)務程序所在容器的監(jiān)控數據，所述監(jiān)控數據包括資源占用率信息。

可選的，所述資源配置調整單元具體可以用于，調用容器引擎接口Docker API訪問進程組資源管理系統(tǒng)Cgroup，以通過所述Cgroup將所述目標業(yè)務程序所在容器的資源配置更改為所述目標資源配置。

可選的，所述調整判斷單元可以包括：

條件判斷單元，用于根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否滿足設定的資源調整條件；

判斷結果確定單元，用于在所述條件判斷單元判斷為是時，確定需要調整所述目標業(yè)務程序所在容器的資源配置，判斷為否時，確定不需要調整所述目標業(yè)務程序所在容器的資源配置。

可選的，所述資源調整條件可以包括資源擴容條件和資源縮容條件，該裝置還可以包括：

集群剩余資源量判斷單元，用于在所述條件判斷單元確定滿足所述資源擴容條件時，判斷所述目標業(yè)務程序所在容器所位于的目標容器集群的剩余資源量，是否滿足所述目標資源配置，并在判斷為是時，執(zhí)行所述資源配置調整單元。

可選的，所述目標資源配置可以包括目標CPU核數，該目標CPU核數為在確定滿足資源擴容條件下確定的?；诖?，所述資源配置調整單元可以包括：

差值計算單元，用于根據所述目標CPU核數以及所述目標業(yè)務程序所在容器當前占用的CPU核數，計算二者的差值；

空閑CPU確定單元，用于獲取每個NUMA節(jié)點中空閑CPU的下標和個數；

差值判斷單元，用于判斷所述目標業(yè)務程序所在容器當前占用的CPU所在的節(jié)點中空閑CPU個數是否不小于所述差值；

CPU分配單元，用于在所述差值判斷單元判斷為是時，在所述目標業(yè)務程序所在容器當前占用的CPU所在的節(jié)點中的空閑CPU中，為所述目標業(yè)務程序所在容器增加分配所述差值個數的CPU。

可選的，所述目標資源配置確定單元可以包括：

在線訪問數量預測單元，用于根據所述目標業(yè)務程序的運營策劃數據，預測所述目標業(yè)務程序的在線訪問數量；

目標資源配置計算單元，用于根據所述目標業(yè)務程序當前的在線訪問數量、所述目標業(yè)務程序當前的資源占用率信息以及預測得到的在線訪問數量，計算目標資源配置。

可選的，所述目標業(yè)務程序所在容器的資源配置可以包括內存配置?；诖?，所述目標資源配置計算單元可以包括：

比例計算單元，用于根據所述目標業(yè)務程序當前的在線訪問數量、所述目標業(yè)務程序當前的內存占用率信息以及預測得到的在線訪問數量，計算擴/縮容比例；

目標內存大小計算單元，用于將非活動文檔內存與所述擴/縮容比例的乘積、活動和非活動匿名頁內存、交換空間內存、活動文檔內存的和值確定為目標內存大小。

可選的，本申請的裝置還可以包括：

校驗單元，用于在所述資源配置調整單元之后，獲取所述目標業(yè)務程序所在容器的最新資源配置；利用所述目標資源配置對所述最新資源配置進行校驗。

本申請實施例提供的資源配置裝置應用于控制中心，該控制中心的硬件結構可以是電腦、筆記本等處理設備，參見圖8，圖8為本申請實施例公開的一種控制中心硬件結構示意圖。如圖8所示，該控制中心可以包括：

處理器1，通信接口2，存儲器3，通信總線4，和顯示屏5；

其中處理器1、通信接口2、存儲器3和顯示屏5通過通信總線4完成相互間的通信；

可選的，通信接口2可以為通信模塊的接口，如GSM模塊的接口；

處理器1，用于執(zhí)行程序；

存儲器3，用于存放程序；

程序可以包括程序代碼，所述程序代碼包括處理器的操作指令。

處理器1可能是一個中央處理器CPU，或者是特定集成電路ASIC(Application Specific Integrated Circuit)，或者是被配置成實施本申請實施例的一個或多個集成電路。

存儲器3可能包含高速RAM存儲器，也可能還包括非易失性存儲器(non-volatile memory)，例如至少一個磁盤存儲器。

其中，程序具體可以用于：

獲取目標業(yè)務程序所在容器的資源占用率信息；

根據所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定是否需要調整所述目標業(yè)務程序所在容器的資源配置；

若是，利用所述資源占用率信息以及所述目標業(yè)務程序的運營策劃數據，確定所要調整至的目標資源配置；

將所述目標業(yè)務程序所在容器的資源配置調整至所述目標資源配置。

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

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

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