本發(fā)明涉及內(nèi)容分發(fā)網(wǎng)絡(luò)技術(shù)領(lǐng)域,特別涉及一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法和系統(tǒng)。
背景技術(shù):
內(nèi)容分發(fā)網(wǎng)絡(luò)(contentdeliverynetwork,cdn)構(gòu)建在網(wǎng)絡(luò)之上,依靠部署在各地的邊緣服務(wù)器,通過中心平臺的負(fù)載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊,使用戶就近獲取所需內(nèi)容,降低網(wǎng)絡(luò)擁塞,提高用戶訪問響應(yīng)速度和命中率。
隨著網(wǎng)絡(luò)的發(fā)展,傳統(tǒng)超文本傳輸協(xié)議(hypertexttransferprotocol,http)和下載使網(wǎng)絡(luò)數(shù)據(jù)量飛速上升,網(wǎng)絡(luò)游戲產(chǎn)業(yè)逐漸成熟,特別是網(wǎng)絡(luò)視頻等需要高帶寬的內(nèi)容,對服務(wù)器和網(wǎng)絡(luò)帶寬的壓力更大,對內(nèi)容分發(fā)網(wǎng)絡(luò)服務(wù)需求迫切。網(wǎng)站的內(nèi)容類型不斷增加和豐富,在新的需求下,流媒體、flash、視頻和下載等網(wǎng)站內(nèi)容及業(yè)務(wù)成了新的主要應(yīng)用對象。為了給軟件下載、視頻流媒體、企業(yè)網(wǎng)頁(web)應(yīng)用、企業(yè)對企業(yè)(business-to-business,b2b)交易和第二代互聯(lián)網(wǎng)(web2.0)互動等各種服務(wù)加速,傳統(tǒng)的內(nèi)容分發(fā)網(wǎng)絡(luò)技術(shù)之上又增加了壓縮、流量整形、智能路由和網(wǎng)絡(luò)優(yōu)化等技術(shù)。隨著內(nèi)容分發(fā)網(wǎng)絡(luò)能夠提供加速的內(nèi)容類型不斷豐富,其提供的服務(wù)也已從單純的內(nèi)容加速拓展到應(yīng)用和服務(wù)的加速。再加上直播的興起,給內(nèi)容分發(fā)網(wǎng)絡(luò)帶來新的爆發(fā)式增長。傳統(tǒng)的服務(wù)器模式,已經(jīng)不能很好的支撐日益增長的內(nèi)容分發(fā)網(wǎng)絡(luò)業(yè)務(wù)。
2010年開始的云計(jì)算風(fēng)潮,以及2013年興起的容器(docker)等新興虛擬化技術(shù),給內(nèi)容分發(fā)網(wǎng)絡(luò)帶來了新的技術(shù)風(fēng)向。這些新的技術(shù)各有所長,可以部分改善傳統(tǒng)物理服務(wù)器模式下的劣勢,帶來更高的靈活性及資源利用率,以及硬件故障下的高可用性,更高的運(yùn)維效率等等。
然而因?yàn)樾录夹g(shù)接口各不相同互不兼容,造成了巨大的管理挑戰(zhàn)。現(xiàn)有的技術(shù)方案主要是各體系內(nèi)的融合,比如私有云與公有云的管理融合,但是沒有橫跨物理服務(wù)器、虛擬服務(wù)器、虛擬主機(jī)及容器的統(tǒng)一管理體系。openstack有實(shí)現(xiàn)一套與docker的整合方案。但是該方案是基于openstack進(jìn)行平臺即服務(wù)(platformasaservice,paas)這一層的整合,實(shí)際效果不好。不支持docker的一些高級特性,因?yàn)閚ovaapi是對機(jī)器的抽象,而dockerapi包含了對進(jìn)程/應(yīng)用的抽象。
如何將新的技術(shù)快速融入到內(nèi)容分發(fā)網(wǎng)絡(luò)體系是一個(gè)亟待解決的技術(shù)難
題,現(xiàn)有技術(shù)存在的問題有:(1)因?yàn)椴煌南到y(tǒng)管理差異較大,內(nèi)容分發(fā)網(wǎng)絡(luò)系統(tǒng)在引入新的子系統(tǒng)時(shí)往往需要投入大量的人力物力,才能將新子系統(tǒng)融入到內(nèi)容分發(fā)網(wǎng)絡(luò)系統(tǒng)之中。(2)不同子系統(tǒng)之間互相兼容性不高,對于垂直化管理造成了巨大的管理挑戰(zhàn)。
技術(shù)實(shí)現(xiàn)要素:
為了解決現(xiàn)有技術(shù)的問題,本發(fā)明實(shí)施例提供了一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法和系統(tǒng)。所述技術(shù)方案如下:
一方面,一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法,內(nèi)容分發(fā)網(wǎng)絡(luò)平臺包括邏輯應(yīng)用層和基礎(chǔ)資源層,構(gòu)建方法包括以下步驟:
邏輯應(yīng)用層在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層;
基礎(chǔ)資源層接收到實(shí)際資源配置需求信息和資源類型信息,根據(jù)實(shí)際資源配置需求信息和資源類型信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
進(jìn)一步的,邏輯應(yīng)用層在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層的步驟具體為:
在邏輯應(yīng)用層上注冊應(yīng)用信息,然后對創(chuàng)建請求中的應(yīng)用基本信息進(jìn)行校驗(yàn),校驗(yàn)通過后根據(jù)創(chuàng)建請求中的應(yīng)用能力需求信息確定應(yīng)用的實(shí)際資源配置需求信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層。
進(jìn)一步的,應(yīng)用創(chuàng)建請求至少包括應(yīng)用基本信息和應(yīng)用能力需求信息,還包括資源類型信息;
應(yīng)用基本信息包括:應(yīng)用名稱,網(wǎng)絡(luò)協(xié)議地址和部署區(qū)域中的一種或幾種;
應(yīng)用能力需求信息包括:api(applicationprogramminginterface,應(yīng)用程序編程接口)響應(yīng)能力,帶寬能力,高可用性(highavailability,ha)能力和輸入輸出(input/output,io)能力中的一種或幾種;
資源類型信息包括:物理機(jī)、虛擬機(jī)和容器中的一種或幾種。
進(jìn)一步的,邏輯應(yīng)用層在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將創(chuàng)建信息和資源類型信息發(fā)送給基礎(chǔ)資源層的具體步驟包括:
在邏輯應(yīng)用層上注冊應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息;
邏輯應(yīng)用層收到應(yīng)用創(chuàng)建請求后,查詢應(yīng)用的注冊信息,與應(yīng)用創(chuàng)建請求中的信息對比,進(jìn)行校驗(yàn);
校驗(yàn)通過后邏輯應(yīng)用層查詢應(yīng)用能力的使用情況和剩余情況,根據(jù)查詢結(jié)果將應(yīng)用能力需求信息轉(zhuǎn)換為實(shí)際資源配置需求信息;
當(dāng)應(yīng)用創(chuàng)建請求中包含資源類型信息時(shí),邏輯應(yīng)用層將應(yīng)用創(chuàng)建請求中的資源類型信息和實(shí)際資源配置需求信息發(fā)送給基礎(chǔ)資源層;
當(dāng)應(yīng)用創(chuàng)建請求中沒有資源類型信息時(shí),邏輯應(yīng)用層查詢配置好的自動創(chuàng)建策略,根據(jù)實(shí)際資源配置需求和自動創(chuàng)建策略決定部署應(yīng)用的資源類型信息,然后再將資源類型信息和實(shí)際資源配置需求信息發(fā)送給基礎(chǔ)資源層。
進(jìn)一步的,自動創(chuàng)建策略包括當(dāng)前資源富余情況、現(xiàn)有資源分配情況和應(yīng)用自身最優(yōu)資源類型。
進(jìn)一步的,基礎(chǔ)資源層根據(jù)實(shí)際資源配置需求信息和資源類型信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境的具體步驟包括:
基礎(chǔ)資源層將同類技術(shù)統(tǒng)一抽象為一種資源類型,根據(jù)資源類型信息找到對應(yīng)的資源類型,然后根據(jù)資源類型和實(shí)際資源配置需求信息找到對應(yīng)的驅(qū)動程序,最后通過驅(qū)動程序結(jié)合實(shí)際資源配置需求信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
另一方面,一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的系統(tǒng),包括:
邏輯應(yīng)用層,用于在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層;
基礎(chǔ)資源層,用于根據(jù)實(shí)際資源配置需求信息和資源類型信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
進(jìn)一步的,邏輯應(yīng)用層包括:
邏輯應(yīng)用管理api模塊,用于管理業(yè)務(wù)功能模塊;
業(yè)務(wù)功能模塊,用于注冊應(yīng)用信息,通過邏輯應(yīng)用管理api模塊對創(chuàng)建請求中的應(yīng)用基本信息進(jìn)行校驗(yàn),校驗(yàn)通過后根據(jù)創(chuàng)建請求中的應(yīng)用能力需求信息確定應(yīng)用的實(shí)際資源配置需求信息。
進(jìn)一步的,邏輯應(yīng)用管理api模塊包括:
應(yīng)用周期管理api,用于提供應(yīng)用創(chuàng)建請求,具體包括應(yīng)用的查找、刪除、增加、修改及遷移恢復(fù);
應(yīng)用能力管理api,用于查詢和統(tǒng)計(jì)應(yīng)用能力的使用情況及剩余情況;
應(yīng)用信息管理api,用于查詢應(yīng)用基本信息;
應(yīng)用策略管理api,用于配置和查詢自動創(chuàng)建策略。
進(jìn)一步的,業(yè)務(wù)功能模塊包括:
應(yīng)用信息管理子模塊,用于注冊應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息,并接收應(yīng)用周期管理api發(fā)來的應(yīng)用創(chuàng)建請求,然后通過應(yīng)用信息管理api查詢應(yīng)用的注冊信息,與應(yīng)用創(chuàng)建請求中的信息對比,進(jìn)行校驗(yàn);
應(yīng)用能力管理子模塊,用于在校驗(yàn)通過后,通過應(yīng)用能力管理api查詢應(yīng)用能力管理api統(tǒng)計(jì)的應(yīng)用能力的使用情況及剩余情況,然后根據(jù)查詢結(jié)果將應(yīng)用能力需求信息轉(zhuǎn)換為實(shí)際資源配置需求信息;
應(yīng)用創(chuàng)建策略子模塊,用于當(dāng)應(yīng)用創(chuàng)建請求中沒有資源類型信息時(shí),通過應(yīng)用策略管理api查詢配置好的自動創(chuàng)建策略,根據(jù)自動創(chuàng)建策略和實(shí)際資源配置需求決定部署應(yīng)用的資源類型信息。
進(jìn)一步的,基礎(chǔ)資源層包括:
基礎(chǔ)資源層包括:
統(tǒng)一資源管理api模塊,用于管理技術(shù)抽象層和技術(shù)驅(qū)動層;
技術(shù)抽象層,用于將同類技術(shù)統(tǒng)一抽象為一種資源類型,根據(jù)資源類型信息,通過統(tǒng)一資源管理api模塊找到對應(yīng)資源類型;
技術(shù)驅(qū)動層,用于根據(jù)技術(shù)抽象層的資源類型和實(shí)際資源配置需求信息找到對應(yīng)的驅(qū)動程序,然后驅(qū)動程序結(jié)合實(shí)際資源配置需求信息通過統(tǒng)一資源管理api模塊創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
進(jìn)一步的,統(tǒng)一資源管理api模塊包括:
資源周期管理api,用于管理基礎(chǔ)資源的生命周期,包括查詢、刪減、增加和修改,驅(qū)動程序結(jié)合實(shí)際資源配置需求信息通過資源周期管理api創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境;
資源清單管理api,用于查詢和統(tǒng)計(jì)不同類型的資源使用情況和剩余情況,根據(jù)查詢結(jié)果和資源類型信息在技術(shù)抽象層找到對應(yīng)的資源類型。
進(jìn)一步的,技術(shù)抽象層的資源類型包括:物理機(jī)、虛擬機(jī)和容器。
進(jìn)一步的,技術(shù)驅(qū)動層具體包括:物理機(jī)管理系統(tǒng)驅(qū)動,私有云管理系統(tǒng)驅(qū)動,云主機(jī)管理系統(tǒng)驅(qū)動和kubernetes管理系統(tǒng)驅(qū)動中的一種或幾種。
本發(fā)明實(shí)施例提供的技術(shù)方案帶來的有益效果是:本發(fā)明提供一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法和系統(tǒng),基于自定義邏輯應(yīng)用模型,以能力建模的方式實(shí)現(xiàn)對物理機(jī)、虛擬機(jī)、容器等多種異構(gòu)技術(shù)方案構(gòu)建的服務(wù)進(jìn)行統(tǒng)一管理。利用物理服務(wù)器、虛擬機(jī)、公有云主機(jī)、容器等異構(gòu)技術(shù)構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò),將應(yīng)用管理服務(wù)(業(yè)務(wù)平面)從資源架構(gòu)(技術(shù)平面)里剝離出來,但仍然保持各種資源技術(shù)的獨(dú)特價(jià)值、特點(diǎn)和智能?;A(chǔ)資源層采用兩層抽象驅(qū)動的模式對資源進(jìn)行統(tǒng)一管理,可以實(shí)現(xiàn)在不變動原有結(jié)構(gòu)的基礎(chǔ)上,快速接納新的技術(shù)方案。采用分層管理,簡化運(yùn)維。上層業(yè)務(wù)可以自定義業(yè)務(wù)能力模型和創(chuàng)建策略,完成多種技術(shù)平臺下的自動化部署,不同的應(yīng)用之間可以共享或者獨(dú)立配置,配置靈活。
附圖說明
為了更清楚地說明本發(fā)明實(shí)施例中的技術(shù)方案,下面將對實(shí)施例描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例,對于本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)這些附圖獲得其他的附圖。
圖1是本發(fā)明提供的一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法的實(shí)施方式的流程圖;
圖2是圖1中步驟s101的具體流程圖;
圖3是圖1中步驟s102的具體流程圖;
圖4是本發(fā)明提供的一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的系統(tǒng)1的實(shí)施方式結(jié)構(gòu)圖。
圖5是圖4中在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的系統(tǒng)1的具體結(jié)構(gòu)圖;
圖6是圖5中邏輯應(yīng)用層100的具體結(jié)構(gòu)圖;
圖7是圖5中基礎(chǔ)資源層200的具體結(jié)構(gòu)圖。
具體實(shí)施方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚,下面將結(jié)合附圖對本發(fā)明實(shí)施方式作進(jìn)一步地詳細(xì)描述。
本發(fā)明提供一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的方法的實(shí)施方式,內(nèi)容分發(fā)網(wǎng)絡(luò)平臺包括邏輯應(yīng)用層(applicationlayer)和基礎(chǔ)資源層(resourcelayer),構(gòu)建方法如圖1所示,包括以下步驟:
s101,邏輯應(yīng)用層在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層。
因?yàn)椴煌夹g(shù)方案管理差異較大,要將不同技術(shù)方案的新系統(tǒng)融入已有cnd系統(tǒng)往往需要投入大量人力物力。同時(shí)由于不同技術(shù)方案之間的兼容性較低,對于系統(tǒng)的垂直化管理造成了巨大挑戰(zhàn)。為此本發(fā)明提出一種基于邏輯應(yīng)用模型的統(tǒng)一抽象管理方法,通過將構(gòu)建于不同技術(shù)方案之上的應(yīng)用以應(yīng)用能力的方式進(jìn)行統(tǒng)一建模,實(shí)現(xiàn)上層管理對于應(yīng)用的統(tǒng)一管理。
邏輯應(yīng)用模型是本發(fā)明抽象出的應(yīng)用管理基本單元,每個(gè)邏輯應(yīng)用實(shí)體由業(yè)務(wù)功能程序和資源環(huán)境程序組成。例如a應(yīng)用是部署在物理機(jī)上的,那么a應(yīng)用的實(shí)體就包括a應(yīng)用本身的功能程序及承載功能程序運(yùn)行的物理機(jī)實(shí)體及系統(tǒng)和軟件環(huán)境。
通過上述方法本發(fā)明將內(nèi)容分發(fā)網(wǎng)絡(luò)平臺分成邏輯應(yīng)用層和基礎(chǔ)資源層,邏輯應(yīng)用層在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層。
應(yīng)用創(chuàng)建請求至少包括應(yīng)用基本信息和應(yīng)用能力需求信息,還可以包括資源類型信息,資源類型信息為可選信息,創(chuàng)建請求中可以不包含該信息,如果不包含該信息,可以在創(chuàng)建過程中由邏輯應(yīng)用層根據(jù)需求自行判斷選擇。
應(yīng)用基本信息包括:應(yīng)用名稱、網(wǎng)絡(luò)協(xié)議(internetprotocol,ip)地址和部署區(qū)域等,主要用于描述應(yīng)用的基本信息,可以根據(jù)需求任意定義所需信息,上文只示例性給出了的幾種應(yīng)用基本信息,還可以有應(yīng)用賬號(identity,id)等其他信息,本發(fā)明對此不作具體限定。
應(yīng)用能力需求信息包括:應(yīng)用程序編程接口(applicationprogramminginterface,api)響應(yīng)能力、帶寬能力、高可用性(highavailability,ha)能力和輸入輸出(input/output,io)能力等,可以根據(jù)需求任意定義所需的應(yīng)用能力需求信息,上文只給出了幾種示例性的應(yīng)用能力需求信息,對于不同應(yīng)用可以有其他應(yīng)用能力需求信息,本發(fā)明對此不作具體限制。
資源類型信息包括:物理機(jī)(physical)、虛擬機(jī)(instance)和容器(docker)。
s102,基礎(chǔ)資源層接收到實(shí)際資源配置需求信息和資源類型信息,根據(jù)實(shí)際資源配置需求信息和資源類型信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
本發(fā)明基于自定義邏輯應(yīng)用模型,以能力建模的方式實(shí)現(xiàn)對物理機(jī)、虛擬機(jī)、容器等多種異構(gòu)技術(shù)方案構(gòu)建的服務(wù)進(jìn)行統(tǒng)一管理。利用物理服務(wù)器、虛擬機(jī)、公有云主機(jī)、容器等異構(gòu)技術(shù)構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò),將應(yīng)用管理服務(wù)(業(yè)務(wù)平面)從資源架構(gòu)(技術(shù)平面)里剝離出來,同時(shí)仍然保持各種資源技術(shù)的獨(dú)特價(jià)值、特點(diǎn)和智能。
具體的,如圖2所示是圖1中步驟s101的具體步驟:
步驟s201,在邏輯應(yīng)用層上注冊應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息。
在創(chuàng)建應(yīng)用前,首先需要在cdn系統(tǒng)的邏輯應(yīng)用層上對各種應(yīng)用預(yù)先進(jìn)行注冊,注冊的內(nèi)容包括應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息等,比如應(yīng)用虛擬機(jī)a,在邏輯應(yīng)用層注冊應(yīng)用名稱:虛擬機(jī)a,網(wǎng)絡(luò)協(xié)議地址:192.168.1.10;子網(wǎng)掩碼:255.255.0.0;部署區(qū)域:山東電信;應(yīng)用賬號:admin001;虛擬網(wǎng)卡連接方式:橋接;處理性能:8核處理器;內(nèi)存:16g;存儲性能:480g;資源類型信息:虛擬機(jī)等內(nèi)容。
不同的應(yīng)用在邏輯應(yīng)用層上有不同的注冊信息,這些注冊信息可以在創(chuàng)建應(yīng)該的過程中可以和創(chuàng)建請求中的應(yīng)用信息進(jìn)行對比,以驗(yàn)證創(chuàng)建請求,決定是否在系統(tǒng)上創(chuàng)建該應(yīng)用。
步驟s202,邏輯應(yīng)用層收到應(yīng)用創(chuàng)建請求后,查詢應(yīng)用的注冊信息,與應(yīng)用創(chuàng)建請求中的信息對比,進(jìn)行校驗(yàn)。
當(dāng)邏輯應(yīng)用層收到創(chuàng)建應(yīng)用的請求后,查詢要創(chuàng)建的應(yīng)用在邏輯應(yīng)用層上預(yù)先注冊過的注冊信息,如上一步注冊的應(yīng)用賬號、應(yīng)用名稱、網(wǎng)絡(luò)協(xié)議地址、部署區(qū)域等信息,與創(chuàng)建請求中的信息進(jìn)行對比,如果信息一致,校驗(yàn)通過,可以在系統(tǒng)上繼續(xù)創(chuàng)建該應(yīng)用,如果信息不一致,校驗(yàn)失敗,停止應(yīng)用創(chuàng)建過程。
步驟s203,校驗(yàn)通過后邏輯應(yīng)用層查詢應(yīng)用能力的使用情況和剩余情況,根據(jù)查詢結(jié)果將應(yīng)用能力需求信息轉(zhuǎn)換為實(shí)際資源配置需求信息。
當(dāng)校驗(yàn)通過后,邏輯應(yīng)用層查詢當(dāng)前系統(tǒng)中現(xiàn)有應(yīng)用的應(yīng)用能力使用情況以及剩余的應(yīng)用能力,根據(jù)查詢的結(jié)果可知當(dāng)前系統(tǒng)中還有多少可用的應(yīng)用能力,結(jié)合創(chuàng)建請求中的應(yīng)用能力需求信息,將應(yīng)用能力需求信息如虛擬網(wǎng)卡連接方式:橋接;處理性能:8核處理器;內(nèi)存:16g;存儲性能:480g等轉(zhuǎn)換為實(shí)際資源配置需求信息。以避免創(chuàng)建請求中應(yīng)用需求的應(yīng)用能力大于系統(tǒng)中剩余的應(yīng)用能力,系統(tǒng)因應(yīng)用能力不足創(chuàng)建過程出現(xiàn)錯誤的情況。
步驟s204,當(dāng)應(yīng)用創(chuàng)建請求中包含資源類型信息時(shí),邏輯應(yīng)用層將應(yīng)用創(chuàng)建請求中的資源類型信息和實(shí)際資源配置需求信息發(fā)送給基礎(chǔ)資源層。
如果應(yīng)用已經(jīng)指定了所需的資源類型,即創(chuàng)建請求中包含資源類型信息,邏輯應(yīng)用層直接將步驟s203得到的實(shí)際資源配置需求和創(chuàng)建請求中的資源類型信息發(fā)送給基礎(chǔ)資源層,由基礎(chǔ)資源層完成后續(xù)資源配置過程即可。
步驟s205,當(dāng)應(yīng)用創(chuàng)建請求中沒有資源類型信息時(shí),邏輯應(yīng)用層查詢配置好的自動創(chuàng)建策略,根據(jù)實(shí)際資源配置需求和自動創(chuàng)建策略決定部署應(yīng)用的資源類型信息,然后再將資源類型信息和實(shí)際資源配置需求信息發(fā)送給基礎(chǔ)資源層。
邏輯應(yīng)用層事先配置有自動創(chuàng)建策略,自動創(chuàng)建策略能夠根據(jù)當(dāng)前資源富余情況、現(xiàn)有資源分配情況和應(yīng)用自身最優(yōu)資源類型等條件結(jié)合實(shí)際資源配置需求信息決定部署應(yīng)用的資源類型信息。當(dāng)創(chuàng)建請求中只有應(yīng)用基本信息和應(yīng)用能力需求信息,而沒有資源類型信息時(shí),邏輯應(yīng)用層查詢事先配置好的自動創(chuàng)建策略,結(jié)合實(shí)際資源配置需求確定部署應(yīng)用的資源類型信息,然后將實(shí)際資源配置需求和資源類型信息發(fā)送給基礎(chǔ)資源層,由基礎(chǔ)資源層完成后續(xù)資源配置過程。
本發(fā)明的邏輯應(yīng)用層可以自定義業(yè)務(wù)能力模型和創(chuàng)建策略,完成多種技術(shù)平臺下的自動化部署,不同的應(yīng)用之間可以共享或者獨(dú)立配置,配置方式靈活。
具體的,如圖3所示是圖1中步驟s102的具體步驟:
步驟s301,基礎(chǔ)資源層將同類技術(shù)統(tǒng)一抽象為一種資源類型。比如物理機(jī)(physical)、虛擬機(jī)(instance)或者容器(docker)等,每種資源類型下具體又包括不同驅(qū)動程序,比如物理機(jī)管理系統(tǒng)驅(qū)動(realservermanager),私有云管理系統(tǒng)驅(qū)動(privatecloud),云主機(jī)管理系統(tǒng)驅(qū)動(ec2)和kubernetes管理系統(tǒng)驅(qū)動等,本發(fā)明在此不再一一列舉。
步驟s302,根據(jù)資源類型信息找到對應(yīng)的資源類型。
基礎(chǔ)資源層收到實(shí)際資源配置需求信息和資源類型信息后根據(jù)資源類型信息在基礎(chǔ)資源成找到對應(yīng)的資源類型。
步驟s303,根據(jù)資源類型和實(shí)際資源配置需求信息找到對應(yīng)的驅(qū)動程序。
在基礎(chǔ)資源層找到對應(yīng)資源類型后,在相應(yīng)的資源類型下根據(jù)實(shí)際資源配置需求選擇合適合的驅(qū)動程序。
步驟s304,通過驅(qū)動程序結(jié)合實(shí)際資源配置需求信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
本發(fā)明采用分層管理,簡化運(yùn)維,僅需要維護(hù)好內(nèi)部服務(wù)的資源情況,保障資源運(yùn)行良好及富余情況。而無需過多關(guān)注運(yùn)行的具體應(yīng)用內(nèi)容及應(yīng)用功能。
本發(fā)明還提供一種在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的系統(tǒng)1的實(shí)施方式,如圖4所示,包括:邏輯應(yīng)用層100和基礎(chǔ)資源層200。
邏輯應(yīng)用層100用于在收到應(yīng)用創(chuàng)建請求后根據(jù)創(chuàng)建請求確定應(yīng)用的實(shí)際資源配置需求信息和資源類型信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層200。
基礎(chǔ)資源層200用于根據(jù)實(shí)際資源配置需求信息和資源類型信息創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
在創(chuàng)建應(yīng)用前,首先需要在邏輯應(yīng)用層100上對各種應(yīng)用預(yù)先進(jìn)行注冊,注冊的內(nèi)容包括應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息等。邏輯應(yīng)用層100收到的應(yīng)用創(chuàng)建請求中至少包括應(yīng)用基本信息和應(yīng)用能力需求信息,還可以包括資源類型信息。應(yīng)用基本信息包括:應(yīng)用名稱,網(wǎng)絡(luò)協(xié)議地址和部署區(qū)域中的一種或幾種;應(yīng)用能力需求信息包括:api響應(yīng)能力,帶寬能力,高可用性能力和輸入輸出能力中的一種或幾種;資源類型信息包括:物理機(jī)、虛擬機(jī)和容器中的一種或幾種。收到應(yīng)用創(chuàng)建請求后,邏輯應(yīng)用層100對創(chuàng)建請求中的應(yīng)用基本信息進(jìn)行驗(yàn)證,驗(yàn)證通過后將創(chuàng)建請求中的應(yīng)用能力信息轉(zhuǎn)換為實(shí)際資源配置需求信息,然后將實(shí)際資源配置需求信息和資源類型信息發(fā)送給基礎(chǔ)資源層200?;A(chǔ)資源層200將同類技術(shù)抽象為一種資源類型,每種資源類型下具體又包括不同驅(qū)動程序?;A(chǔ)資源層200根據(jù)收到的資源類型信息找到對應(yīng)資源類型,然后在對應(yīng)的資源類型下根據(jù)實(shí)際資源配置需求確定合適的的驅(qū)動程序,最后通過驅(qū)動程序按照實(shí)際資源配置需求信息創(chuàng)建邏輯應(yīng)用的基礎(chǔ)資源環(huán)境,依據(jù)應(yīng)用需要完成應(yīng)用的部署與配置。
具體的,如圖5所示是圖4中在異構(gòu)資源上構(gòu)建內(nèi)容分發(fā)網(wǎng)絡(luò)平臺的系統(tǒng)1的具體結(jié)構(gòu)。
邏輯應(yīng)用層100包括:邏輯應(yīng)用管理api模塊101和業(yè)務(wù)功能模塊102。
基礎(chǔ)資源層200包括:統(tǒng)一資源管理api模塊201、技術(shù)抽象層202和技術(shù)驅(qū)動層203。
邏輯應(yīng)用管理api模塊101用于管理業(yè)務(wù)功能模塊;業(yè)務(wù)功能模塊102用于注冊應(yīng)用信息,通過邏輯應(yīng)用管理api模塊對創(chuàng)建請求中的應(yīng)用基本信息進(jìn)行校驗(yàn),校驗(yàn)通過后根據(jù)創(chuàng)建請求中的應(yīng)用能力需求信息確定應(yīng)用的實(shí)際資源配置需求信息。
統(tǒng)一資源管理api模塊201用于管理技術(shù)抽象層和技術(shù)驅(qū)動層;技術(shù)抽象層202用于將同類技術(shù)統(tǒng)一抽象為一種資源類型,根據(jù)資源類型信息,通過統(tǒng)一資源管理api模塊找到對應(yīng)資源類型;技術(shù)驅(qū)動層203用于根據(jù)技術(shù)抽象層的資源類型和實(shí)際資源配置需求信息找到對應(yīng)的驅(qū)動程序,然后驅(qū)動程序結(jié)合實(shí)際資源配置需求信息通過統(tǒng)一資源管理api模塊創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境。
本發(fā)明采用分層管理,簡化運(yùn)維,僅需要維護(hù)好內(nèi)部服務(wù)的資源情況,保障資源運(yùn)行良好及富余情況。而無需過多關(guān)注運(yùn)行的具體應(yīng)用內(nèi)容及應(yīng)用功能。
如圖6所示是圖5中邏輯應(yīng)用層100的具體結(jié)構(gòu)。
邏輯應(yīng)用管理api模塊101包括:應(yīng)用周期管理api(applicationlifecycle)1011、應(yīng)用能力管理api(applicationabilityinventory)1012、應(yīng)用信息管理api(applicationinformation)1013和應(yīng)用策略管理api(applicationstrategy)1014。
務(wù)功能模塊102包括:應(yīng)用信息管理子模塊(appmanager)1021、應(yīng)用能力管理子模塊(appabilitymapper)1022和應(yīng)用創(chuàng)建策略子模塊(creationstrategy)1023。
應(yīng)用周期管理api1011用于提供應(yīng)用創(chuàng)建請求,具體包括應(yīng)用的查找、刪除、增加、修改及遷移恢復(fù);應(yīng)用能力管理api1012用于查詢和統(tǒng)計(jì)應(yīng)用能力的使用情況及剩余情況;應(yīng)用信息管理api1013用于查詢應(yīng)用基本信息;應(yīng)用策略管理api1014用于配置和查詢自動創(chuàng)建策略。
應(yīng)用信息管理子模塊1021用于注冊應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息,并接收應(yīng)用周期管理api1011發(fā)來的應(yīng)用創(chuàng)建請求,然后通過應(yīng)用信息管理api1013查詢應(yīng)用的注冊信息,與應(yīng)用創(chuàng)建請求中的信息對比,進(jìn)行校驗(yàn);應(yīng)用能力管理子模塊1022用于在校驗(yàn)通過后,通過應(yīng)用能力管理api1012查詢應(yīng)用能力管理api1012統(tǒng)計(jì)的應(yīng)用能力的使用情況及剩余情況,然后根據(jù)查詢結(jié)果將應(yīng)用能力需求信息轉(zhuǎn)換為實(shí)際資源配置需求信息;應(yīng)用創(chuàng)建策略子模塊1023用于當(dāng)應(yīng)用創(chuàng)建請求中沒有資源類型信息時(shí),通過應(yīng)用策略管理api1014查詢配置好的自動創(chuàng)建策略,根據(jù)自動創(chuàng)建策略和實(shí)際資源配置需求決定部署應(yīng)用的資源類型信息。
創(chuàng)建應(yīng)用前首先通過應(yīng)用信息管理子模塊1021在邏輯應(yīng)用層100上注冊應(yīng)用基本信息、應(yīng)用能力信息和應(yīng)用資源類型信息。通過應(yīng)用周期管理api1011向應(yīng)用信息管理子模塊1021發(fā)送應(yīng)用創(chuàng)建請求后,應(yīng)用信息管理子模塊1021通過應(yīng)用信息管理api1013查詢應(yīng)用的注冊信息,與應(yīng)用創(chuàng)建請求中的信息對比,進(jìn)行校驗(yàn)。如果信息不一致,校驗(yàn)失敗,停止應(yīng)用創(chuàng)建過程;如果信息一致,校驗(yàn)通過,應(yīng)用能力管理子模塊1022通過應(yīng)用能力管理api1012查詢應(yīng)用能力管理api1012自身統(tǒng)計(jì)的應(yīng)用能力的使用情況及剩余情況,然后根據(jù)查詢結(jié)果將應(yīng)用能力需求信息轉(zhuǎn)換為實(shí)際資源配置需求信息;當(dāng)應(yīng)用創(chuàng)建請求中沒有資源類型信息時(shí)應(yīng)用創(chuàng)建策略子模塊1023通過應(yīng)用策略管理api1014查詢配置好的自動創(chuàng)建策略,根據(jù)自動創(chuàng)建策略和實(shí)際資源配置需求決定部署應(yīng)用的資源類型信息。
本發(fā)明在邏輯應(yīng)用層可以自定義業(yè)務(wù)能力模型和創(chuàng)建策略,完成多種技術(shù)平臺下的自動化部署,不同的應(yīng)用之間可以共享或者獨(dú)立配置,配置方式靈活。
如圖7所示是圖5中基礎(chǔ)資源層200的具體結(jié)構(gòu)。
統(tǒng)一資源管理api模塊201包括:資源周期管理api(resourcelifecycle)2011和資源清單管理api(resourceinventory)2012。資源周期管理api2011用于管理基礎(chǔ)資源的生命周期,包括查詢、刪減、增加和修改,驅(qū)動程序結(jié)合實(shí)際資源配置需求信息通過資源周期管理api創(chuàng)建應(yīng)用的基礎(chǔ)資源環(huán)境;資源清單管理api2012用于查詢和統(tǒng)計(jì)不同類型的資源使用情況和剩余情況,根據(jù)查詢結(jié)果和資源類型信息在技術(shù)抽象層找到對應(yīng)的資源類型。
技術(shù)抽象層202的資源類型包括:物理機(jī)2021、虛擬機(jī)2022和容器2023。
技術(shù)驅(qū)動層203具體包括:物理機(jī)管理系統(tǒng)驅(qū)動2031,私有云管理系統(tǒng)驅(qū)動2032,云主機(jī)管理系統(tǒng)驅(qū)動2033和kubernetes管理系統(tǒng)驅(qū)動2034。
基礎(chǔ)資源層200收到實(shí)際資源配置需求信息和資源類型信息后,通過資源清單管理api2012查詢和統(tǒng)計(jì)技術(shù)抽象層202中不同類型的資源使用情況和剩余情況,根據(jù)查詢結(jié)果和資源類型信息在技術(shù)抽象層找到對應(yīng)的資源類型。然后在對應(yīng)的資源類型下根據(jù)實(shí)際資源配置需求確定合適的驅(qū)動程序,該驅(qū)動程序,按照實(shí)際資源配置需求信息通過資源周期管理api2011完成應(yīng)用基礎(chǔ)資源環(huán)境的創(chuàng)建,依據(jù)應(yīng)用需要完成應(yīng)用的部署與配置。
本發(fā)明在基礎(chǔ)資源層采用兩層抽象驅(qū)動的模式對資源進(jìn)行統(tǒng)一管理,可以實(shí)現(xiàn)在不變動原有結(jié)構(gòu)的基礎(chǔ)上,快速接納物理機(jī)、虛擬機(jī)等新的技術(shù)方案。只需要在資源的技術(shù)驅(qū)動層中完成功能對接既可以納入系統(tǒng)管理,能夠快速引入新的技術(shù)架構(gòu)。
上述本發(fā)明實(shí)施例序號僅僅為了描述,不代表實(shí)施例的優(yōu)劣。
以上所描述的裝置實(shí)施例僅僅是示意性的,其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個(gè)地方,或者也可以分布到多個(gè)網(wǎng)絡(luò)單元上。可以根據(jù)實(shí)際的需要選擇其中的部分或者全部模塊來實(shí)現(xiàn)本實(shí)施例方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性的勞動的情況下,即可以理解并實(shí)施。
通過以上的實(shí)施方式的描述,本領(lǐng)域的技術(shù)人員可以清楚地了解到各實(shí)施方式可借助軟件加必需的通用硬件平臺的方式來實(shí)現(xiàn),當(dāng)然也可以通過硬件。基于這樣的理解,上述技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來,該計(jì)算機(jī)軟件產(chǎn)品可以存儲在計(jì)算機(jī)可讀存儲介質(zhì)中,如rom/ram、磁碟、光盤等,包括若干指令用以使得一臺計(jì)算機(jī)設(shè)備(可以是個(gè)人計(jì)算機(jī),服務(wù)器,或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行各個(gè)實(shí)施例或者實(shí)施例的某些部分所述的方法。
以上所述僅為本發(fā)明的較佳實(shí)施例,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內(nèi),所作的任何修改、等同替換、改進(jìn)等,均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。