楊繼偉

（樂視云計算有限公司，北京 100025）

0 引言

視頻云服務是基于云計算、大數(shù)據等技術提供視頻服務的網絡應用模式。視頻云服務需要消耗大量的基礎設施資源，主要包括計算資源、存儲資源、網絡資源等[1]?；谝曨l市場的海量需求，云計算廠商為企業(yè)用戶提供了便捷、低成本、高質量的視頻云服務，但隨著業(yè)務的發(fā)展，集群規(guī)模不斷擴大，隨之也帶來很多問題，如集群管理、集群利用率偏低等[2]，因此如何管理這些資源，如何合理并高效的使用這些資源，從而降低成本，是云計算廠商關心的一個主要問題。

在視頻云源站生產控制系統(tǒng)存在如下幾個問題：一是生產任務的獲取采用拉取模式，生產機器需要定時訪問生產控制系統(tǒng)來獲取任務，當沒有任務時，機器仍然要訪問生產控制系統(tǒng)，這造成了機器資源、網絡資源的浪費。二是任務調度方式只是簡單的區(qū)域調度，沒有考慮資源情況，調度不均勻，導致節(jié)點利用率不均衡。三是調度模塊與生產控制系統(tǒng)耦合在一起，隨著業(yè)務發(fā)展以及調度策略的復雜性，使得生產控制系統(tǒng)越來越臃腫。

為解決上述問題，提出視頻云源站的資源調度系統(tǒng)，將調度功能與生產控制系統(tǒng)解耦，完成生產層機器的統(tǒng)一管理和動態(tài)調度，均衡的使用機器資源，從而達到提高機器利用率的目的。

1 研究進展

視頻云服務包括視頻生產和終端播放兩個環(huán)節(jié)，如圖1所示。視頻云生產是指源站不同協(xié)議、不同碼率視頻的生產。在這些任務環(huán)節(jié)中，需要合理的為任務分配機器，如分配轉碼機進行轉碼任務、分配RTMP服務器進行推流或拉流，分配錄制機器對HLS切片進行錄制等。

在云計算開源平臺中，具有資源管理與調度功能的軟件有OpenStack、Docker、Hadoop YARN。

OpenStack的作用是整合各種底層硬件資源對外提供虛擬機服務[3]，它的調度功能主要是用來決策虛擬機創(chuàng)建在哪個主機上。生產層機器一般為物理機，可以使用 OpenStack對物理機進行管理，提供虛擬機來部署生產服務。如果虛擬機性能滿足點播、直播需求，那么替換掉物理機將大大提高機器利用率。

Docker是一個基于 Linux容器的高級容器引擎[4]，可以快速實現(xiàn)服務器擴容和自動化部署。當Docker技術應用在視頻云源站服務中時，如果每個容器實例執(zhí)行一個生產任務，隨著任務數(shù)的增加容器實例也將不斷增多，與生產控制系統(tǒng)間交互的量級也將急劇增多，為系統(tǒng)帶來了負擔。如果每個容器仍然執(zhí)行多個生產任務，這種方式需要由上層業(yè)務方來管理每個容器上可執(zhí)行的任務數(shù)量，還需要決策每個任務在哪個容器中執(zhí)行，因此需要搭建資源調度系統(tǒng)對容器IP進行管理。

圖1 視頻云生產環(huán)節(jié)Fig.1 Production process of video cloud

Hadoop YARN[5]主要應用在大數(shù)據領域，調度的實時性以及與業(yè)務系統(tǒng)交互方式的缺失，并不適合應用在視頻云源站的資源調度中。

綜上所述，無論視頻云源站生產過程中使用的是物理機、虛擬機還是容器，都需要對其進行管理，因此需要搭建視頻云源站的資源調度系統(tǒng)實現(xiàn)生產任務調度功能。

2 需求分析

基于業(yè)務現(xiàn)狀，資源調度系統(tǒng)應該滿足如下功能：

第一，由于資源復用，同一臺機器上每個服務可執(zhí)行的任務數(shù)是不相同的，因此需要進行差別調度和管理。

第二，在特殊業(yè)務場景中，需要對機器調度進行個性化配置，如將某個用戶的請求固定發(fā)送到某一臺機器上。

第三，需要返回當前資源最優(yōu)的機器，例如當需要轉碼時，需要找到一臺資源最充足、離源站距離最近、網絡鏈路較好的機器來進行轉碼。

由于需要對資源進行管理和配置，同時還需要向業(yè)務方提供調度接口，因此資源調度系統(tǒng)的用戶有如下兩類：

（1）系統(tǒng)管理員。系統(tǒng)管理員是資源調度系統(tǒng)的使用者，可以管理生產環(huán)節(jié)用到的節(jié)點、機器等信息；可以為業(yè)務方分配資源池，設置資源使用權限；可以靈活配置資源調度策略，屏蔽某個機器的資源調度；可以實時監(jiān)控資源使用情況；對調度情況、資源情況進行統(tǒng)計分析。

（2）業(yè)務方系統(tǒng)。業(yè)務方一般是點播、直播生產控制系統(tǒng)，所以需要為其提供一個實時的、穩(wěn)定的資源調度接口。

3 系統(tǒng)總體設計

3.1 系統(tǒng)架構設計

考慮到系統(tǒng)的健壯性、模塊化、調度接口的性能以及便于管理，將系統(tǒng)設計分為兩個子系統(tǒng)，一是資源管理子系統(tǒng)，二是資源調度子系統(tǒng)，系統(tǒng)架構如圖2所示。

3.1.1 資源管理子系統(tǒng)

資源管理子系統(tǒng)為系統(tǒng)管理員提供各種資源創(chuàng)建和配置服務，同時需要和外部數(shù)據平臺、報警系統(tǒng)交互。系統(tǒng)功能主要分為五個模塊。

（1）基礎數(shù)據管理

管理生產環(huán)節(jié)用到的機器、節(jié)點、網絡信息，以及國家、省份、城市、運營商、IP庫等基本信息，對數(shù)據進行修改和維護。

（2）資源池管理

主要用于業(yè)務資源池創(chuàng)建、資源分配、業(yè)務角色的配置和修改。將節(jié)點和機器劃分成不同的業(yè)務資源池，多個機器可以同時分配給不同的業(yè)務方。

（3）調度管理

資源調度子系統(tǒng)需要依賴基礎的調度配置實現(xiàn)調度功能，調度管理包括路由調度配置和定制調度配置。路由調度配置指配置節(jié)點間的調度方向，定制調度配置指根據用戶 ID、請求來源 IP、節(jié)點 ID等進行定向配置。

（4）資源監(jiān)控

指對資源池中的資源總量、利用率進行監(jiān)控和預警，當資源使用量超過某一閾值時，與報警系統(tǒng)進行交互，發(fā)送郵件、短信或電話報警。

（5）統(tǒng)計報表

提供各類統(tǒng)計報表，如資源利用率統(tǒng)計、機器資源利用率等。報表的數(shù)據來源主要是對資源池中的資源進行定期采集，生成不同時間下的資源使用情況報表。

3.1.2 資源調度子系統(tǒng)

圖2 系統(tǒng)架構設計Fig. 2 The design of system architecture

資源調度子系統(tǒng)主要是基于資源量、地域、運營商等因素實現(xiàn)實時的動態(tài)調度，為業(yè)務系統(tǒng)返回最優(yōu)的生產機器。業(yè)務方包括點播生產控制系統(tǒng)、直播生產控制系統(tǒng)、輪播生產控制系統(tǒng)等。資源調度子系統(tǒng)功能分為3個模塊。

（1）調度API

向業(yè)務系統(tǒng)提供資源調度接口，對業(yè)務方進行身份認證和接入鑒權，系統(tǒng)提供的調度服務包括轉碼調度、流媒體生產調度、切片生產調度、錄制調度、截圖調度等。

（2）調度策略

資源調度是建立在調度模型基礎上，通過資源適配器，適配出合適的業(yè)務資源池，再根據不同的調度算法，如定制調度、路由調度、機器調度等查找合適的機器資源。

（3）三級存儲結構

三級存儲結構指數(shù)據庫、分布式緩存、內存。資源調度子系統(tǒng)與資源管理子系統(tǒng)共用數(shù)據庫，管理子系統(tǒng)對數(shù)據進行添加、修改后將數(shù)據保存到數(shù)據庫中等，調度子系統(tǒng)從數(shù)據庫中查詢數(shù)據。為了提高調度接口的響應時間，減輕數(shù)據庫的壓力，調度子系統(tǒng)采用 Redis緩存資源量數(shù)據，并進行數(shù)據一致性處理；采用內存存儲使用頻率高且不存在數(shù)據一致性問題的數(shù)據，如調度策略的配置、節(jié)點基本信息、機器基本信息等。

3.2 系統(tǒng)交互流程

業(yè)務系統(tǒng)、生產層與資源調度系統(tǒng)間的交互流程如圖3所示。具體流程如下：

（1）資源調度系統(tǒng)為業(yè)務系統(tǒng)預分配資源池，指定初始資源池大小。

（2）生產層機器定時向心跳平臺上報資源量、機器負載等信息。

（3）資源調度子系統(tǒng)訪問心跳平臺的接口，獲取機器資源量信息并將資源量保存到Redis緩存中。

（4）業(yè)務系統(tǒng)向資源調度子系統(tǒng)發(fā)起資源申請。

（5）資源調度子系統(tǒng)為業(yè)務匹配資源池，根據調度策略查找節(jié)點列表。

（6）資源調度子系統(tǒng)根據節(jié)點列表，從節(jié)點下查找滿足資源需求的最優(yōu)的機器，并對機器資源量進行減法操作，更新到分布式緩存中。

（7）業(yè)務系統(tǒng)獲取到機器后，向生產層機器下發(fā)任務，機器收到任務后執(zhí)行，同時機器上報本機的剩余資源至心跳平臺。

4 系統(tǒng)實現(xiàn)的關鍵技術

4.1 資源模型設計

由于生產層機器會出現(xiàn)業(yè)務復用的情況，因此本文采用基于角色模式建立資源模型。在機房建設時，每個機房是一個獨立的集群節(jié)點，一個機房的機器會同時向多個業(yè)務提供服務。因此需要將同一機房的機器資源按照業(yè)務需求劃分為多個子節(jié)點，每個子節(jié)點形成一個業(yè)務角色，最后將資源劃分為以角色為單位的資源池。資源模型如圖4所示。

圖3 系統(tǒng)架構設計Fig.3 S ystem interaction process

圖4 資源模型Fig.4 Resouce model

角色資源池由不同節(jié)點的不同機器組成，一個角色可以包含多個機器，同一個機器也可以擁有多個角色。對于擁有多個角色的機器而言，角色之間共享硬件資源，但在業(yè)務上，角色之間是獨立的。一個業(yè)務資源池由多個角色資源池組成，一個角色資源只能屬于一個業(yè)務資源。資源類數(shù)據結構及關系如圖5所示。

資源模型中，useful_count表示可用的資源量。以計算資源為例，CPU、IO等資源在資源調度時不能直接使用，需要轉換成可以計算的指標。不同于虛擬機或容器的資源量化方式，本文使用一個整數(shù)值來表示該類機器的可用資源量。計算資源量化的方法是根據機器機型、CPU配置等信息得出最大可執(zhí)行任務數(shù)或代表機器計算能力，例如一臺轉碼機上可以并行執(zhí)行 12個轉碼任務，12就表示該臺轉碼機的計算資源總量。存儲資源的量化是將磁盤容量作為機器資源總量，如存儲容量為 500 G。帶寬資源量化是將本機帶寬資源作為資源總量，如本機當前帶寬為1000 Mbps。

4.2 資源池創(chuàng)建與分配

圖5 資源數(shù)據結構Fig.5 Res ource data structure

業(yè)務方在使用調度子系統(tǒng)的資源申請功能前，系統(tǒng)管理員必須要通過資源管理頁面給業(yè)務方系統(tǒng)創(chuàng)建資源池。創(chuàng)建成功后該資源池中的資源為 0，必須經過資源分配，綁定節(jié)點和機器信息時該資源才可用。資源創(chuàng)建與分配流程如圖6所示。

為每一類資源分配節(jié)點以及節(jié)點下的機器資源，頁面功能如圖7所示。

例如在分配實時轉碼資源時，先選擇節(jié)點類型為實時轉碼節(jié)點，系統(tǒng)查出所有的實時轉碼節(jié)點后，勾選某一節(jié)點，然后單擊對應的“選擇機器”按鈕，系統(tǒng)查出該節(jié)點下的機器列表，勾選要分配的機器，提交表單，資源分配完成。

4.3 資源調度流程

資源調度從整體上可以分為三步：

第一，節(jié)點調度，按照調度策略得到節(jié)點列表；

第二，角色調度，將節(jié)點列表與業(yè)務資源池相匹配，最后得到排序的角色列表。

第三，機器調度，遍歷角色列表，從中查找符合需求的最優(yōu)的機器。

資源調度整體工作流程如圖8所示。

具體步驟如下：

（1）對用戶申請的資源進行適配，按申請的資源類別biz匹配資源池，得到資源ID。

（2）根據IP庫的數(shù)據，解析用戶的請求IP，獲取用戶的歸屬地信息，包括國家、省份、城市、運營商信息。

（3）采用定制調度查找節(jié)點，查找成功則跳轉到（6），失敗跳轉到（4）。

（4）采用路由調度查找節(jié)點，查找成功則跳轉到（6），失敗跳轉到（5）。

（5）采用經緯度調度查找節(jié)點，查找成功則跳轉到（6），失敗則返回未申請到資源。

（6）節(jié)點ID與資源ID相關聯(lián)，得到角色ID。

（7）依次遍歷角色 ID，過濾掉不可用機器，將機器按照資源量排序，得到資源量最高的機器。

（8）對資源進行減法操作，更新機器資源量緩存，返回機器IP。

4.4 資源調度模型

4.4.1 節(jié)點路由調度模型

路由調度是將運營商、地域和資源量3個因素作為篩選節(jié)點的條件，根據實際IDC機房的建設情況，可將節(jié)點按地域進行分層劃分，全網節(jié)點可以看成是一個有向圖，如圖9所示。該模型主要應用在節(jié)點機房較多的國家中。

圖6 資源分配流程Fig.6 Resour ce allocation process

圖7 資源分配頁面Fig.7 Resour ce allocation process

圖8 資源調度流程Fig.8 Re source schedule process

圖9 路由調度模型Fig.9 Routing scheduling model

路由調度模型的生成分成兩步：

首先生成世界地圖，由圖中的節(jié)點和直線箭頭組成。按照國家、省份、地市建立樹形結構，即每個國家用一棵樹表示，根節(jié)點是國家信息，第二層是省份或州信息，第三層是地市信息，第四層是葉子節(jié)點，為該地區(qū)的機房信息。多個國家之間形成森林，以上形成一個四層的世界地圖結構。

其次定義路由調度方向，即節(jié)點之間的調度方向，為圖中的弧形箭頭。系統(tǒng)維護調度路由表，該路由表采用地理上相鄰的國家、省份或州作為基礎數(shù)據。例如省份 A與省份B、C、D相鄰，則系統(tǒng)生成一條記錄，表示到達A省的請求可以往B、C、D調度。

（1）世界地圖

為了方便快速查找，Java中使用HashMap嵌套的結構實現(xiàn)世界地圖的存儲，HashMap實際上是鏈表散列，即數(shù)組和鏈表的結合體。數(shù)組中每一個元素包含一個key-value鍵值對，此種模式在查找數(shù)據時時間復雜度為O(1)，可以快速實現(xiàn)查找。Java中創(chuàng)建名稱為WORLD_MAP_NODE的數(shù)據結構，定義如下：

Map>>>>

初始化時，首先生成國家Map結構，key為國家ID，value為該國家的所有省份Map結構；省份Map結構中key為每個省份ID，value為該省份所有的城市 Map結構；依次類推，城市 Map中 key為城市ID，value為節(jié)點Map，節(jié)點Map中key為節(jié)點ID，value為機房節(jié)點信息。

（2）路由調度方向

如圖10所示，為路由調度方向的存儲結構，采用鄰接表實現(xiàn)。例如一共有5個節(jié)點P0、P1、P2、P3、P4。P0的鄰接點有P1，P1的鄰接點有P0、P2、P3、P4。圖中每個頂點的所有鄰接點構成一個線性表。

圖10 路由調度方向存儲結構Fig.10 Storage structure of routing scheduling direction

實現(xiàn)時，每個頂點的所有鄰接點也采用HashMap嵌套的結構，不同層級的key值包括國家ID、省份ID，依次遞進。Java中創(chuàng)建名稱ROUTE_SCHEDULE_RULE的數(shù)據結構用來表示調度方向，定義如下：

Map>>

使用該數(shù)據結構，表示可以根據國家ID找到其擁有的省份ID,再根據省份ID可以找到可調度到的國家-省份列表。其中ScheduleTargetCountry元數(shù)據的結構包含兩個字段，國家ID和省份ID。

4.4.2 節(jié)點經緯度調度模型

由于世界上國家較多，而且不是所有國家都有機房節(jié)點信息，因此將存在節(jié)點信息的國家使用路由調度模型方式，沒有節(jié)點的國家使用經緯度調度模型。

經緯度調度是根據用戶所在地的經緯度信息，與全網節(jié)點的經緯度分別做差值，節(jié)點間距離最小的離用戶最近，視為較優(yōu)節(jié)點。與路由調度策略相比，該策略比較單一，但同時可以減少遍歷節(jié)點的次數(shù)，提高查找效率。如圖11所示，為經緯度調度模型。

圖11 經緯度調度模型Fig.11 Schedule model of longitude and latitude

圖中A、B、C、D、E、F共6個節(jié)點，如在A節(jié)點，與其他5個節(jié)點的距離分別為s1、s2、s3、s4、s5，對這 5個距離按照從小到大排序，得出距離最小的節(jié)點。經緯度模型在內存中的存儲結構為：

Map>

該結構表示根據節(jié)點類型可以查找出所有節(jié)點，每個節(jié)點中配置了經緯度信息。

4.5 資源調度算法實現(xiàn)

4.5.1 IP查找算法

當業(yè)務方傳遞了IP這個參數(shù)時，調度系統(tǒng)需要根據IP庫中的信息，對參數(shù)IP進行解析，得出IP所在的地域信息用來進行路由調度。由于IP庫中存儲的是IP段所在的國家、省份、城市和運營商信息，直接查找數(shù)據庫很難定位IP的地域信息，且調度接口需要滿足實時性，因此將IP庫數(shù)據加載到內存中，在內存中判斷IP的地域信息，并由定時任務每天定時更新IP庫到內存。

IP庫在內存中，采用List集合進行存儲，即數(shù)組結構。每一條記錄包含了IP的起始地址段、結束地址段，起始地址長整型，結束地址長整型和地域歸屬信息。首先從數(shù)據庫查詢IP時，按照起始地址長整型從小到大排序，再保存到內存中，即內存中的數(shù)據是有序的。將請求來源IP轉換成長整型，利用二分查找算法，定位IP所在的IP段信息，IP段信息的數(shù)據結構包括IP歸屬國家ID、省份ID、運營商ID。

使用二分查找IP歸屬信息算法如下：

（1）定義變量low=最小數(shù)下標，hign=最大數(shù)下標，mid為中間數(shù)下標；

（2）初始化low=0，hign=集合大小；

（3）while(low <= high)

（a）中間數(shù)下標mid = (low + high)/2

（b）if ( Long IP >= 中間數(shù)List[mid])return 中間數(shù)

（c）else if (Long IP > 中間數(shù))

low = mid + 1

（d）else

high = mid – 1

二分查找代碼實現(xiàn)如圖12所示。

4.5.2 節(jié)點路由調度算法

路由調度算法流程分為四步：

第一步按照圖的廣度優(yōu)先遍歷，遍歷所有節(jié)點，按照相鄰省份之間的步長對節(jié)點分組，相鄰省份間的步長為1，當前節(jié)點到其鄰省的鄰省步長為2，依此類推。

第二步分別對步長相同的節(jié)點按照運營商進行分組，相同運營商的節(jié)點為一組，不同運營商的節(jié)點為另外一組。

第三步對分組后的節(jié)點與業(yè)務資源ID關聯(lián)，得到角色列表。

第四步對每一層的角色使用合并排序算法排序，最終得到排序的角色列表。

圖12 二分查找實現(xiàn)Fig.12 The implementation of Two point lookup

路由調度算法具體步驟如下：

（1）設請求所在地的省份為 P0，定義如下變量并初始化。

v：ScheduleTargetCountry數(shù)據對象，Q：待訪問的省份隊列，VisitQ：已訪問過的省份隊列，TempQ：臨時節(jié)點隊列，ReturnList：返回的節(jié)點集合，結構為List>。

其中隊列均采用鏈表 LinkedList結構，隊列中的元素為ScheduleTargetCountry數(shù)據對象，隊列Q的初值為請求所在地的ScheduleTargetCountry信息。

（2）while（隊列Q非空）

（3）隊列Q的隊頭元素出隊,v入隊列VisitQ，根據國家 ID、省份 ID從 ROUTE_SCHEDULE_RULE結構中獲取鄰接省份節(jié)點，即可調度到的ScheduleTargetCountry列表，該列表與VisitQ比較，將v的未被訪問過的鄰接點列表入隊列Q，同時記錄v與P0的步長。

（4）訪問省份v，從世界地圖中查找v的節(jié)點信息，如果v存在機器節(jié)點且節(jié)點滿足可用性等條件，則v的節(jié)點ID入隊列TempQ。否則重復步驟（2）、（3）、（4），直到全部省份被遍歷完。

（5）遍歷結束后，對TempQ按步長分組，形成List>形式的數(shù)據結構ReturnList。外層List表示步長序號，內層List表示節(jié)點列表。

（6）按照運營商對ReturnList分組，與用戶相同運營商的節(jié)點為一組，其它為另一組，返回ReturnList。

通過以上步驟，得到分組后的節(jié)點如圖13所示：

圖13 節(jié)點路由調度分組Fig.13 Node routing scheduling group

4.5.3 節(jié)點經緯度調度算法

經緯度調度算法如下：

（1）系統(tǒng)保存所有節(jié)點所在省份的經緯度信息。

（2）根據用戶所在省份信息，得出用戶的經緯度。

（3）計算用戶所在地經緯度與各節(jié)點的經緯度的距離。

（4）根據 Java中自帶的集合排序算法 Collections.sort，對所有距離排序，找出距離用戶最近的節(jié)點。

計算用戶所在地與各節(jié)點的距離，采用計算球面上任意兩點距離的方法。假設球面上兩點A、B，A點坐標為A(j1, w1),B點坐標為B(j2, w2)，其中j1、w1、j2、w2是經緯度信息。

圖14 球面距離模型Fig.14 S pherical distance model

球面距離公式如下：

L=R arccos (cosw1 cos w2 cos(j2-j1) + sin w1 sin w2

計算球面距離代碼實現(xiàn)如圖15所示。

圖15 球面距離實現(xiàn)Fig.15 The implementation of spherical distance

4.5.4 器調度算法

機器調度算法是根據角色信息查找該角色下的機器，返回資源量最高的機器，具體步驟如下：

（1）設用戶申請的資源量為 count，角色集合為L，大小為s，定義臨時變量i=0。

（2）遍歷角色，對角色下的機器按照資源總量從大到小排序

（3）while ( i < s)

（4）if（機器 L[i]的剩余資源>最小剩余閾值 and機器剩余資源>count），對該機器開啟 Redis事務。

（a）機器資源量減 count，更新緩存，如果更新成功，表示申請機器資源成功，接口返回機器IP。

（b）如果更新緩存失敗，對i加1，跳轉到步驟（3）。

（5）else資源不滿足，對i加 1，跳轉到步驟（3）。

4.6 分布式緩存與數(shù)據一致性

在響應業(yè)務方的申請資源請求或者調度子系統(tǒng)從心跳平臺查詢資源信息時，都要更新調度子系統(tǒng)的 Redis緩存。資源調度在查找機器時，需要根據角色ID先查找到機器信息，然后對緩存中該機器的資源量進行更新，因此內存中需要定義如下結構：

Map>

該結構表示某一角色下的機器 IP列表，其中BIZ_IP是業(yè)務類型和機器 IP的拼接，ServerCache存儲在緩存中，包括的字段如表1所示。

表1 名稱資源緩存數(shù)據結構Tab.1 Data struct of resouce cache

當申請資源進行資源量扣除時，對可用資源量字段進行事務操作。Java中 Redis的事務操作通過以下步驟實現(xiàn)：

（1）使用 Redis的 watch()方法對緩存中 key為BIZ_IP的字段進行監(jiān)控。

（2）使用multi()方法開啟事務。

（3）使用 decrBy()方法將資源量減去申請的數(shù)值。

（4）使用exec()方法提交事務，如果執(zhí)行成功，表示申請資源成功。否則申請失敗，返回。

5 系統(tǒng)測試

測試的主要內容是測試路由調度的準確性和靈活性，即運營商、省份區(qū)域和資源量對調度的影響。

測試環(huán)境服務器采用Linux系統(tǒng)，8 G內存，4核CPU，2.4 GHZ。Web容器采用Tomcat7.0，使用JDK1.7，Redis采用 3.2.9版本，Mysql采用 5.5版本，MongoDB采用3.0.3版本。

模擬多用戶并發(fā)請求資源調度接口，調度系統(tǒng)記錄請求日志，從日志中分析調度到的機器IP。測試前需預置數(shù)據，提前創(chuàng)建多個資源節(jié)點，如表 2所示。

表2 預置節(jié)點數(shù)據Tab.2 P repared node data

用戶請求來源可以分為兩類，一是節(jié)點中包含與用戶運營商相同的節(jié)點，二是節(jié)點中不包含與用戶運營商相同的節(jié)點，測試用例如表3所示。

表3 測試用例Tab.3 Te st case

（1）測試用例1

請求來源為杭州電信，調度的節(jié)點順序為東莞電信、長沙聯(lián)通、北京聯(lián)通，調度到的IP順序如圖16所示，X軸為請求個數(shù)，Y軸為IP序號。

（2）測試用例2

請求來源為安徽歌華有線，由于已知服務器的節(jié)點中沒有和請求所在地運營商相同的節(jié)點，且 3個節(jié)點距離請求所在地步長都相同，因此節(jié)點調度只按照資源量進行均勻調度，調度到的機器IP也是按照資源量均勻調度，如圖17所示，X軸為請求個數(shù)，Y軸為IP序號。

圖16 相同運營商請求Fig.16 The request from same ISP

測試結果表明：

（1）當節(jié)點中包含與請求所在地運營商相同的節(jié)點時,會最先匹配相同運營商節(jié)點，其次按照距離從近到遠，即調度配置的臨省關系，依次匹配不同運營商的節(jié)點，最后按照資源量從大到小匹配節(jié)點。

圖17 不同運營商請求Fig.17 The Request from different ISP

（2）當節(jié)點中不包含與用戶運營商相同的節(jié)點時，只會按照距離從近到遠、資源量從大到小匹配節(jié)點。

（3）無論哪類請求，當某節(jié)點內有多臺機器時，該節(jié)點內的機器資源是均衡使用的，保證了各個節(jié)點內資源利用率的均衡。設置節(jié)點剩余資源量的最低閾值解決資源不均衡問題，同時防止節(jié)點被全部打滿。

資源管理問題一直是云計算廠商關心的主要問題，通過各種虛擬化、資源整合復用等技術，提高機器資源利用率，降低企業(yè)成本。在未來云計算的資源管理還會投入更多的研究，使得各種資源進行融合，發(fā)揮出巨大的價值。

6 結論

本論文設計并實現(xiàn)了視頻云源站生產環(huán)節(jié)的資源調度系統(tǒng)，系統(tǒng)整合了視頻云生產層的所有機器，使得之前零散的機器管理得到統(tǒng)一，方便后續(xù)的資源復用；系統(tǒng)提供了基于資源量、地域、運營商的動態(tài)調度算法，解決了原有系統(tǒng)中調度不準確、不靈活的問題，提高了機器利用率，促進了各生產環(huán)節(jié)交互的穩(wěn)定性。

通過實際的應用，資源調度系統(tǒng)解決了原調度系統(tǒng)中調度不準確、不靈活的問題，但同時也存在著不足：

（1）隨著任務逐漸增多，機器資源利用率也逐漸升高，在節(jié)點利用率達到較高值時，每臺機器會產生一定的資源碎片不能被利用。

（2）節(jié)點間網絡鏈路情況也是影響調度的一個因素，當按照距離和資源量進行節(jié)點調度時，會優(yōu)先打滿距離請求所在地最近的節(jié)點，但此種方法在網絡鏈路好的情況下，節(jié)點間資源利用率出現(xiàn)了不均衡。由于資源池中資源一般較為充足，可以通過

[1] 陳國良, 明仲. 云計算工程[M]. 北京: 人民郵電出版社,2016: 160-183.

[2] 易觀智庫. 2016中國視頻云專題研究報告[R/OL].(2016-06-20). [2018-01-05]. http://www.useit.com.cn/thread-12482-1-1.html.

[3] 潘虎. 云計算理論與實踐[M]. 北京: 電子工業(yè)出版社,2016: 142-162.

[4] 劉志成, 林東升, 彭勇. 云計算技術與應用基礎[M]. 北京:人民郵電出版社, 2017: 178-181.

[5] Arun C. Murthy, Vinod Kumar Vavilapalli. Hadoop YARN權威指南[M]. 羅韓梅,譯.第1版. 北京: 機械工業(yè)出版社,2015: 27-45.

[6] 武凱, 勾學榮, 朱永剛. 云計算資源管理淺析[J]. 軟件,2015, 36(2): 97-101.

[7] 李華清. 云計算技術及應用服務模式探討[J]. 軟件, 2014,35(2): 127-128.

[8] 段忠祥. 基于云計算的網絡平臺共享資源模型的建設[J].軟件, 2013, 34(5): 119-121.

[9] 張棟梁, 譚永杰. 云計算中負載均衡優(yōu)化模型及算法研究[J]. 軟件, 2013, 34(8): 52-55.

[10] Ellis Horowitz, Sartaj Sahni, Sanguthevar Rajasekeran. 計算機算法[M]. 趙穎, 武永衛(wèi), 等譯. 2版. 北京: 清華大學出版社, 2015: 96-115, 219-225.