[發明專利]基于服務發現和容器技術的大數據平臺彈性伸縮方法

有效

• 申請號: 201711062730.4
• 申請日: 2017-11-02
• 公開（公告）號: CN107948249B
• 公開（公告）日: 2019-12-10
• 發明（設計）人: 林偉偉;吳梓明;張子龍
• 申請（專利權）人: 華南理工大學
• 主分類號: H04L29/08
• 分類號: H04L29/08;H04L12/26
• 代理公司: 44245 廣州市華學知識產權代理有限公司
• 代理人: 李斌

本發明公開了一種基于服務發現和容器技術的大數據平臺彈性伸縮方法，包括以下步驟：(1)使用容器技術組件化大數據平臺；(2)啟動大數據集群，注冊集群元數據信息；(3)向服務代理匯報心跳數據并更新相關信息；(4)代理服務周期向服務代理讀取大數據集群管理信息，判斷是否存在節點失效或者需求變更情況，如果存在，則執行第五步驟；否則，執行第六步驟；(5)若存在節點失效情況，則嘗試恢復失效的節點容器；若存在需求變更情況，則根據需求變更元數據，為集群添加或則刪除節點容器；(6)重復執行以上第三至第五步驟，直至集群服務終止運行。本發明能夠感知大數據平臺內部狀態從而進行有效彈性伸縮和提高集群資源使用率。

技術領域

本發明涉及云計算大數據彈性伸縮領域,特別涉及一種基于服務發現和容器技術的大數據平臺彈性伸縮方法。

背景技術

在云計算相關領域，彈性伸縮有助于數據中心保持資源管理的魯棒性，能夠降低能耗緩解系統資源浪費。目前不管是流量巨大的電商、游戲等娛樂行業，還是請求量波動極大的視頻、直播等新媒體行業，都需要在“資源不足”和“資源浪費”之間做權衡。鄧子凡針對水平伸縮和垂直伸縮各自的缺點，提出一種將水平伸縮和垂直伸縮兩種方式相結合的彈性伸縮模式，但依然存在虛擬機技術帶來的缺點。在Gandhi等人的研究中指出了傳統的解決方案的缺陷：AlwaysOn采用全冗余的方式會造成嚴重的資源浪費；Reactive采用延遲啟動策略，但在虛擬機或應用環境啟動時setup延遲時間太長，一般都會超過200秒；Predictive嘗試利用線性回歸等策略來擬合負載模型，提前啟動虛擬機來縮短setup時間；彈性伸縮方法根據請求量動態調整資源配給，但由于虛擬機的啟動延遲等缺陷，而采用了與Predictive結合的方式。

隨著容器技術的發展，彈性伸縮方法得到了更廣泛的利用。例如在YW Chen等人的研究中利用容器的彈性伸縮加速異構環境中的大數據作業，但在其解決方案中需要擴展大數據平臺的相關模塊，缺乏通用性。Toffetti G等人利用容器的彈性伸縮提出了一種能夠自我管理的微服務架構，在其實現中采用etcd作為狀態持久化中心，可以實時響應到集群狀態的節點故障，從而實現自我恢復。HE Yu等人提出了一種基于容器的高性能計算集群彈性伸縮架構，但其實現中用單節點維護服務狀態，容易出現單點故障，缺乏可用性，Kan C等人實現了一種基于容器的彈性伸縮云平臺，該實現采用了與Predictive方法相結合的方式來預測流量變化，不能應對流量突變。

雖然最近幾年在面向大數據平臺的彈性伸縮方向上已經開展了不少研究工作，然而，從傳統的架構上來看，彈性伸縮需要結合Predictive方法預測流量的變化，這是由于虛擬機具有較高的啟動延遲的缺點，而且這樣的方法無法實時應對流量突變。此外，當前基于容器技術的彈性伸縮方法要不就是需要額外的擴展，要不就是存在功能上的缺陷，對目前流行的大數據平臺不具有普遍適用性。

發明內容

鑒于上述現有技術存在的不足，本發明目的是提供一種基于服務發現和容器技術的大數據平臺彈性伸縮方法，能根據服務代理提供大數據服務的生命周期信息，從而能夠感知到集群內部的狀態變化，為大數據集群提供按需的、靈活的彈性伸縮服務，并有效提高集群資源利用率。

為實現以上目的，本發明采取如下技術方案：

本發明的一種基于服務發現和容器技術的大數據平臺彈性伸縮方法，包括以下步驟：

第一步驟：使用容器技術對各大數據平臺進行組件化封裝處理；

第二步驟：初始化大數據集群管理的元數據目錄，在大數據集群啟動時，拉取并啟動相應大數據平臺組件，并將集群元數據信息注冊到服務代理；

第三步驟：每個主機集群節點的狀態監控器周期向服務代理匯報心跳數據，并更新相關信息，實現對集群內部的狀態感知；