本發(fā)明涉及器化微服務技術領域，尤其涉及一種容器化微服務自動伸縮及遷移調(diào)度的方法、系統(tǒng)和設備。

背景技術：

在如今的互聯(lián)網(wǎng)和企業(yè)應用開發(fā)領域，微服務和DevOps這兩個思想頗為深入人心。而Docker技術的出現(xiàn)和其對整個容器技術及其生態(tài)圈發(fā)展的促進，解決了微服務和DevOps這兩個思想實踐中的很多難題，使得微服務和DevOps這兩種思想大規(guī)模地實現(xiàn)成為了可能。而Docker給系統(tǒng)架構各應用的微服務容器化提供了諸多便利的同時，也對企業(yè)的服務治理帶來了很大挑戰(zhàn)。

為了充分利用IDC的物理資源、節(jié)省企業(yè)成本和保證服務的高可用性，在保證服務不中斷情況下需要對服務進行彈性伸縮和遷移調(diào)度。

目前，對服務進行彈性伸縮和遷移調(diào)度主要有兩種方式：

1、手工方式：

1)根據(jù)容器化微服務故障的監(jiān)控預警信息，運維人員手工把不可用的服務調(diào)度到集群中其它可用節(jié)點上。

2)預估系統(tǒng)流量壓力，運維人員提前在預測時間點手工擴容、縮減容器化微服務實例資源配額或數(shù)量。

2、基于系統(tǒng)性能監(jiān)控的自動調(diào)度方式：

服務治理平臺或監(jiān)控系統(tǒng)監(jiān)控容器的CPU、內(nèi)存、網(wǎng)絡流量，根據(jù)預先設定的規(guī)則，在CPU、內(nèi)存或網(wǎng)絡流量使用量達到閥值時自動擴容或縮減容器實例數(shù)量。

發(fā)明人在研究的過程中發(fā)現(xiàn)，上述兩種方式存在以下缺點：

手工方式效率低：從接到告警信息到運維人員完成手工伸縮，響應時間不及時。企業(yè)運維成本高：每次伸縮都需要運維人員全程參與造成運維成本高。操作失誤風險高和推廣困難：如策略、規(guī)則和伸縮模式復雜，會造成運維人員學習和應用困難，推廣阻力大。同時，由于根據(jù)策略和規(guī)則計算最優(yōu)的伸縮模式復雜，很容易造成操作失誤風險。

基于系統(tǒng)性能監(jiān)控的自動調(diào)度方式不能達到預期效果：沒有進行故障傳導分析，某個容器的資源利用情況不能真實反映整個調(diào)用鏈的瓶頸，達到閥值容器的資源利用情況會是由于下級微服務的服務質(zhì)量造成。伸縮策略受限：無法對容器實例的資源配額單獨伸縮。伸縮機制受限：不能根據(jù)單個容器化微服務的特性進行重啟，或單次伸縮數(shù)量、收縮時間間隔等。

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

為了解決上述技術問題，本發(fā)明提供了一種容器化微服務自動伸縮及遷移調(diào)度的方法、系統(tǒng)和設備，通過監(jiān)控容器的資源(CPU、內(nèi)存、IO、網(wǎng)絡和存儲)利用情況和容器化微服務的服務質(zhì)量(響應時間、失敗率、服務調(diào)用次數(shù))。結合大數(shù)據(jù)綜合分析結果，根據(jù)規(guī)則、策略和調(diào)度算法，提供容器化微服務無需人工干預快速的自動化伸縮和故障調(diào)度轉移。達到對硬件資源的合理利用、降低運維團隊成本、容器化微服務的高可用性和高性能目的。

本發(fā)明一方面提供了一種容器化微服務自動伸縮及遷移調(diào)度的方法，其特征在于，包括：

接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)；

觸發(fā)容器自動伸縮或故障調(diào)度轉移。

進一步的，所述接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)，包括：

實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)。

進一步的，所述實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)，包括：

資源監(jiān)控和分析系統(tǒng)實時采集服務調(diào)用日志和容器資源利用信息；

判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點；

實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的所述原始故障點的異常信息數(shù)據(jù)。

進一步的，所述判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點，包括：

基于服務器配置的預設預警條件閥值以及預設算法分析，判斷采集的HTTP和TCP/UDP類型的服務調(diào)用日志和容器資源利用信息中的容器CPU、內(nèi)存、存儲、IO和/或網(wǎng)絡的使用數(shù)據(jù)，以及微服務的響應時間、失敗率、QPS是否滿足系統(tǒng)預設預警條件；

若滿足系統(tǒng)預設預警條件之一，則進行故障傳導分析，在整個微服務調(diào)用鏈里定位原始故障點。

進一步的，所述系統(tǒng)預設預警條件包括但不限于高負荷、低使用率、異常波動或可用性不達標中的一種或多種。

進一步的，所述觸發(fā)容器自動伸縮或故障調(diào)度轉移，包括：

根據(jù)預警數(shù)據(jù)中的IP和端口或服務ID從容器集群環(huán)境中獲取相關微服務屬性信息；

把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移，包括：

參照RETE算法，根據(jù)預警數(shù)據(jù)的類型進行規(guī)則類型匹配，將每類中的預警數(shù)據(jù)根據(jù)屬性值進行多級規(guī)則匹配，選出一個條件被優(yōu)先滿足的規(guī)則后，根據(jù)選定的規(guī)則從規(guī)則適配決策表中匹配決策項集合，通過匹配的決策項集合解決決策項集合中的沖突，形成可順序執(zhí)行決策項，根據(jù)決策項的調(diào)度機制調(diào)用容器集群的API完成容器伸縮或故障調(diào)度轉移。

進一步的，所述接收第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移，包括：

接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)；

調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義，準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，包括：

接收第三方平臺通過HTTP或HTTPS協(xié)議提供的接口通過同步調(diào)用或異步調(diào)用服務使用JSON格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，并在注冊成功回調(diào)地址后可實現(xiàn)消息推送。

進一步的，所述觸發(fā)容器自動伸縮，包括：

伸縮容器的CPU、內(nèi)存、存儲資源中的一種或多種；

重啟容器；

基于預設時間間隔將容器逐一伸縮；

基于預設時間間隔按照預設比例將容器逐步伸縮。

本發(fā)明另一方面還提供了一種容器化微服務自動伸縮及遷移調(diào)度的系統(tǒng)，包括：

接收模塊，用于接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)；

觸發(fā)模塊，用于觸發(fā)容器自動伸縮或故障調(diào)度轉移。

進一步的，所述接收模塊，包括：

第一接收模塊，用于實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)。

進一步的，所述第一接收模塊，包括：

資源監(jiān)控和分析系統(tǒng)采集單元，用于實時采集服務調(diào)用日志和容器資源利用信息；

判斷單元，用于判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點；

接收單元，用于實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的所述原始故障點的異常信息數(shù)據(jù)。

進一步的，所述判斷單元，包括：

判斷子單元，用于基于服務器配置的預設預警條件閥值以及預設算法分析，判斷采集的HTTP和TCP/UDP類型的服務調(diào)用日志和容器資源利用信息中的容器CPU、內(nèi)存、存儲、IO和/或網(wǎng)絡的使用數(shù)據(jù)，以及微服務的響應時間、失敗率、QPS是否滿足系統(tǒng)預設預警條件；

定位單元，用于在判斷子單元判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件之一，則進行故障傳導分析，在整個微服務調(diào)用鏈里定位原始故障點。

進一步的，所述系統(tǒng)預設預警條件包括但不限于高負荷、低使用率、異常波動或可用性不達標中的一種或多種。

進一步的，所述觸發(fā)模塊，包括：

獲取單元，用于根據(jù)預警數(shù)據(jù)中的IP和端口或服務ID從容器集群環(huán)境中獲取相關微服務屬性信息；

第一觸發(fā)單元，用于把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述第一觸發(fā)單元，包括：

規(guī)則匹配單元，用于參照RETE算法，根據(jù)預警數(shù)據(jù)的類型進行規(guī)則類型匹配，將每類中的預警數(shù)據(jù)根據(jù)屬性值進行多級規(guī)則匹配，選出一個條件被優(yōu)先滿足的規(guī)則后，根據(jù)選定的規(guī)則從規(guī)則適配決策表中匹配決策項集合，通過匹配的決策項集合解決決策項集合中的沖突，形成可順序執(zhí)行決策項；

第一觸發(fā)子單元，用于根據(jù)決策項的調(diào)度機制調(diào)用容器集群的API完成容器伸縮或故障調(diào)度轉移。

進一步的，所述接收模塊，包括：

第二接收模塊，用于接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)。

進一步的，所述觸發(fā)模塊，包括：

第二觸發(fā)單元，用于調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義，準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述第二接收模塊，包括：

第二接收單元，用于接收第三方平臺通過HTTP或HTTPS協(xié)議提供的接口通過同步調(diào)用或異步調(diào)用服務使用JSON格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，并在注冊成功回調(diào)地址后可實現(xiàn)消息推送。

進一步的，所述觸發(fā)模塊，還包括：

第一伸縮單元，用于伸縮容器的CPU、內(nèi)存、存儲資源中的一種或多種；

重啟單元，用于重啟容器；

第二伸縮單元，用于基于預設時間間隔將容器逐一伸縮；

第三伸縮單元，用于基于預設時間間隔按照預設比例將容器逐步伸縮。

本發(fā)明另一方面還提供了一種容器化微服務自動伸縮及遷移調(diào)度的設備，包括前述任一項所述的容器化微服務自動伸縮及遷移調(diào)度的系統(tǒng)。

本發(fā)明通過接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移的技術方案，一旦微服務出現(xiàn)異常，加快了服務伸縮的響應時間和處理時間；解放了運維人員處理的繁重工作量；有效控制了人為處理服務伸縮帶來的不可控風險；降低了企業(yè)的運維成本；有效加快企業(yè)推廣系統(tǒng)容器化微服務改造；解決了容器收縮策略的限制；擴充了容器化微服務伸縮的多樣性和機制；通過對整個調(diào)用鏈的故障傳導分析準確的定位了真實的故障點，做到了對容器化微服務的精確伸縮。

附圖說明

圖1為根據(jù)本發(fā)明的容器化微服務自動伸縮及遷移調(diào)度的方法的實施例一的流程圖；

圖2為根據(jù)本發(fā)明的JSON格式調(diào)用程序的示意圖；

圖3為根據(jù)本發(fā)明的數(shù)據(jù)格式程序的示意圖；

圖4為根據(jù)本發(fā)明的容器化微服務自動伸縮及遷移調(diào)度的系統(tǒng)的實施例二的示意圖；

圖5為根據(jù)本發(fā)明的接收模塊的實施例二的示意圖；

圖6為根據(jù)本發(fā)明的第一接收模塊的實施例二的示意圖；

圖7為根據(jù)本發(fā)明的判斷單元的實施例二的示意圖；

圖8為根據(jù)本發(fā)明的觸發(fā)模塊的實施例二的示意圖；

圖9為根據(jù)本發(fā)明的第一觸發(fā)單元的實施例二的示意圖；

圖10為根據(jù)本發(fā)明的接收模塊的實施例二的另一示意圖；

圖11為根據(jù)本發(fā)明的觸發(fā)模塊的實施例二的另一示意圖；

圖12為根據(jù)本發(fā)明的第二接收模塊的實施例二的示意圖；

圖13為根據(jù)本發(fā)明的觸發(fā)模塊的實施例二的另一示意圖；

圖14為根據(jù)本發(fā)明的容器化微服務自動伸縮及遷移調(diào)度的設備的實施例三的結構框圖。

具體實施方式

為了使本技術領域的人員更好地理解本發(fā)明方案，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分的實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應當屬于本發(fā)明保護的范圍。

需要說明的是，本發(fā)明的說明書和權利要求書及上述附圖中的術語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。應該理解這樣使用的數(shù)據(jù)在適當情況下可以互換，以便這里描述的本發(fā)明的實施例能夠以除了在這里圖示或描述的那些以外的順序實施。此外，術語“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統(tǒng)、產(chǎn)品或設備不必限于清楚地列出的那些步驟或單元，而是可包括沒有清楚地列出的或對于這些過程、方法、產(chǎn)品或設備固有的其它步驟或單元。

實施例一

參照圖1，圖1示出了本發(fā)明提供的一種容器化微服務自動伸縮及遷移調(diào)度的方法的流程圖。包括：步驟S110、步驟S120。

在步驟S110中，接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)。

在步驟S120中，觸發(fā)容器自動伸縮或故障調(diào)度轉移。

進一步的，所述接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)，包括：

實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)。

進一步的，所述實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)，包括：

資源監(jiān)控和分析系統(tǒng)實時采集服務調(diào)用日志和容器資源利用信息；

判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點；

實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的所述原始故障點的異常信息數(shù)據(jù)。

進一步的，所述判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點，包括：

基于服務器配置的預設預警條件閥值以及預設算法分析，判斷采集的HTTP和TCP/UDP類型的服務調(diào)用日志和容器資源利用信息中的容器CPU、內(nèi)存、存儲、輸入/輸出IO接口或設備和/或網(wǎng)絡的使用數(shù)據(jù)，以及微服務的響應時間、失敗率、每秒查詢率QPS是否滿足系統(tǒng)預設預警條件；其中，預設預警條件閥值以及預設算法分析根據(jù)系統(tǒng)的硬件屬性或場景所需，設置配置的閥值和策略，通過實時大數(shù)據(jù)綜合分析所需的數(shù)據(jù)集。

若滿足系統(tǒng)預設預警條件之一，則進行故障傳導分析，在整個微服務調(diào)用鏈里定位原始故障點。在定位到故障點后，把異常信息數(shù)據(jù)按照“接口調(diào)用協(xié)議”定義的格式發(fā)送給容器化微服務自動調(diào)度系統(tǒng)中。

進一步的，所述系統(tǒng)預設預警條件包括但不限于高負荷、低使用率、異常波動或可用性不達標中的一種或多種。

進一步的，所述觸發(fā)容器自動伸縮或故障調(diào)度轉移，包括：

根據(jù)預警數(shù)據(jù)中的IP和端口或服務ID從容器集群環(huán)境中獲取相關微服務屬性信息；

把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移，包括：

參照RETE算法，根據(jù)預警數(shù)據(jù)的類型進行規(guī)則類型匹配，將每類中的預警數(shù)據(jù)根據(jù)屬性值進行多級規(guī)則匹配，選出一個條件被優(yōu)先滿足的規(guī)則后，根據(jù)選定的規(guī)則從規(guī)則適配決策表中匹配決策項集合，通過匹配的決策項集合解決決策項集合中的沖突，形成可順序執(zhí)行決策項，根據(jù)決策項的調(diào)度機制調(diào)用容器集群的API完成容器伸縮或故障調(diào)度轉移。

進一步的，所述接收第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移，包括：

接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)；

調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義，準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，所述接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，包括：

接收第三方平臺通過HTTP或HTTPS協(xié)議提供的接口通過同步調(diào)用或異步調(diào)用服務使用JSON格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，并在注冊成功回調(diào)地址后可實現(xiàn)消息推送。

本發(fā)明實施例中的與第三方平臺的通信模式，可獨立作為一個服務，以HTTP或HTTPS協(xié)議提供接口調(diào)用服務，其它業(yè)務系統(tǒng)或功能模塊可同步調(diào)用、異步調(diào)用。并在注冊成功回調(diào)地址后可實現(xiàn)消息推送。并可提供客戶端數(shù)字證書、用戶名加密碼、令牌三種方式認證客戶端調(diào)用的合法性。接口調(diào)用數(shù)據(jù)使用JSON格式，一應用例子，參考圖2所示的調(diào)用服務。

進一步的，所述觸發(fā)容器自動伸縮，包括：

伸縮容器的CPU、內(nèi)存、存儲資源中的一種或多種；

重啟容器；

基于預設時間間隔將容器逐一伸縮；

基于預設時間間隔按照預設比例將容器逐步伸縮。

另一應用例子，通過第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)；觸發(fā)容器自動伸縮或故障調(diào)度轉移。在互聯(lián)網(wǎng)票務B2C業(yè)務中，由于場館座位的限制，熱點演唱會項目售票通常指定時間點進行開票售賣。在到開票售賣后瞬間會有大量的黃牛黨和粉絲集中購買。首先預測演唱會搶票高峰服務的容器擴容量。

通過監(jiān)控微服務的并發(fā)訪問，統(tǒng)計出下單服務的壓力最大、響應時間最慢的微服務。由于下單響應時間的瓶頸延遲會造成整個交易流程體驗不好。

預測下單服務的擴容數(shù)量，根據(jù)歷史監(jiān)控數(shù)據(jù)，經(jīng)大數(shù)據(jù)平臺依據(jù)時間、城市、項目類型、項目內(nèi)容四個緯度預估出需要擴容的規(guī)模和數(shù)量。

運維人員通過服務治理平臺(第三方平臺)，選定訂單服務，并填入擴容的數(shù)量、擴容時間、擴容間隔時間、每次的擴容量。運維人員通過服務治理平臺，提交訂單服務擴容任務給“容器化微服務自動調(diào)度系統(tǒng)”。數(shù)據(jù)格式如圖3所示。

“容器化微服務自動調(diào)度系統(tǒng)”依據(jù)接收到的數(shù)據(jù)調(diào)用任務執(zhí)行引擎生成計劃任務。

任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義，準時調(diào)用容器集群的API完成容器伸縮或故障調(diào)度轉移。

本發(fā)明實施例一通過接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移的技術方案，一旦微服務出現(xiàn)異常，加快了服務伸縮的響應時間和處理時間；解放了運維人員處理的繁重工作量；有效控制了人為處理服務伸縮帶來的不可控風險；降低了企業(yè)的運維成本；有效加快企業(yè)推廣系統(tǒng)容器化微服務改造；解決了容器收縮策略的限制；擴充了容器化微服務伸縮的多樣性和機制；通過對整個調(diào)用鏈的故障傳導分析準確的定位了真實的故障點，做到了對容器化微服務的精確伸縮。

實施例二

參照圖4，圖4示出了本發(fā)明提供的一種容器化微服務自動伸縮及遷移調(diào)度的系統(tǒng)200一實施例的結構圖，包括：

接收模塊21，用于接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)。

觸發(fā)模塊22，用于觸發(fā)容器自動伸縮或故障調(diào)度轉移。

進一步的，參照圖5，所述接收模塊21，包括：

第一接收模塊211，用于實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)。

進一步的，參照圖6，所述第一接收模塊211，包括：

資源監(jiān)控和分析系統(tǒng)采集單元2111，用于實時采集服務調(diào)用日志和容器資源利用信息；

判斷單元2112，用于判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件后，在微服務調(diào)用鏈里定位原始故障點；

接收單元2113，用于實時接收資源監(jiān)控和分析系統(tǒng)發(fā)送的所述原始故障點的異常信息數(shù)據(jù)。

進一步的，參照圖7，所述判斷單元2112，包括：

判斷子單元21121，用于基于服務器配置的預設預警條件閥值以及預設算法分析，判斷采集的HTTP和TCP/UDP類型的服務調(diào)用日志和容器資源利用信息中的容器CPU、內(nèi)存、存儲、IO和/或網(wǎng)絡的使用數(shù)據(jù)，以及微服務的響應時間、失敗率、QPS是否滿足系統(tǒng)預設預警條件；

定位單元21122，用于在判斷子單元判斷所述采集的服務調(diào)用日志和容器資源利用信息滿足系統(tǒng)預設預警條件之一，則進行故障傳導分析，在整個微服務調(diào)用鏈里定位原始故障點。

進一步的，所述系統(tǒng)預設預警條件包括但不限于高負荷、低使用率、異常波動或可用性不達標中的一種或多種。

進一步的，參照圖8，所述觸發(fā)模塊22，包括：

獲取單元221，用于根據(jù)預警數(shù)據(jù)中的IP和端口或服務ID從容器集群環(huán)境中獲取相關微服務屬性信息；

第一觸發(fā)單元222，用于把預警數(shù)據(jù)交給規(guī)則引擎選出需要執(zhí)行動作的決策項集合，依據(jù)決策項的調(diào)度機制調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，參照圖9，所述第一觸發(fā)單元222，包括：

規(guī)則匹配單元2221，用于參照RETE算法，根據(jù)預警數(shù)據(jù)的類型進行規(guī)則類型匹配，將每類中的預警數(shù)據(jù)根據(jù)屬性值進行多級規(guī)則匹配，選出一個條件被優(yōu)先滿足的規(guī)則后，根據(jù)選定的規(guī)則從規(guī)則適配決策表中匹配決策項集合，通過匹配的決策項集合解決決策項集合中的沖突，形成可順序執(zhí)行決策項；

第一觸發(fā)子單元2222，用于根據(jù)決策項的調(diào)度機制調(diào)用容器集群的API完成容器伸縮或故障調(diào)度轉移。

進一步的，參照圖10，所述接收模塊21，包括：

第二接收模塊212，用于接收第三方平臺按照接口調(diào)用協(xié)議定義的格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)。

進一步的，參照圖11，所述觸發(fā)模塊22，包括：

第二觸發(fā)單元223，用于調(diào)用任務執(zhí)行引擎生成計劃任務，任務執(zhí)行引擎根據(jù)任務計劃數(shù)據(jù)定義，準時調(diào)用容器集群的API觸發(fā)容器完成自動伸縮或故障調(diào)度轉移。

進一步的，參照圖12，所述第二接收模塊212，包括：

第二接收單元2121，用于接收第三方平臺通過HTTP或HTTPS協(xié)議提供的接口通過同步調(diào)用或異步調(diào)用服務使用JSON格式提交的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，并在注冊成功回調(diào)地址后可實現(xiàn)消息推送。

進一步的，參照圖13，所述觸發(fā)模塊22，還包括：

第一伸縮單元224，用于伸縮容器的CPU、內(nèi)存、存儲資源中的一種或多種；

重啟單元225，用于重啟容器；

第二伸縮單元226，用于基于預設時間間隔將容器逐一伸縮；

第三伸縮單元227，用于基于預設時間間隔按照預設比例將容器逐步伸縮。

由于本實施例二的系統(tǒng)所實現(xiàn)的處理及功能基本相應于前述圖1-3所示的方法的實施例、原理和實例，故本實施例的描述中未詳盡之處，可以參見前述實施例中的相關說明，在此不做贅述。

本發(fā)明實施例二通過接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移的技術方案，一旦微服務出現(xiàn)異常，加快了服務伸縮的響應時間和處理時間；解放了運維人員處理的繁重工作量；有效控制了人為處理服務伸縮帶來的不可控風險；降低了企業(yè)的運維成本；有效加快企業(yè)推廣系統(tǒng)容器化微服務改造；解決了容器收縮策略的限制；擴充了容器化微服務伸縮的多樣性和機制；通過對整個調(diào)用鏈的故障傳導分析準確的定位了真實的故障點，做到了對容器化微服務的精確伸縮。

實施例三

參照圖14，圖14示出了本發(fā)明提供的一種容器化微服務自動伸縮及遷移調(diào)度的設備300，包括前述實施例二中的任一項所述的容器化微服務自動伸縮及遷移調(diào)度的系統(tǒng)200。

本發(fā)明實施例三通過接收容器和/或微服務產(chǎn)生的經(jīng)故障定位后的預警數(shù)據(jù)；和/或第三方平臺發(fā)送的攜帶容器和/或微服務自動伸縮任務計劃數(shù)據(jù)，觸發(fā)容器自動伸縮或故障調(diào)度轉移的技術方案，一旦微服務出現(xiàn)異常，加快了服務伸縮的響應時間和處理時間；解放了運維人員處理的繁重工作量；有效控制了人為處理服務伸縮帶來的不可控風險；降低了企業(yè)的運維成本；有效加快企業(yè)推廣系統(tǒng)容器化微服務改造；解決了容器收縮策略的限制；擴充了容器化微服務伸縮的多樣性和機制；通過對整個調(diào)用鏈的故障傳導分析準確的定位了真實的故障點，做到了對容器化微服務的精確伸縮。

上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。

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

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的裝置，可通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能單元的形式實現(xiàn)。

需要指出，根據(jù)實施的需要，可將本申請中描述的各個步驟/部件拆分為更多步驟/部件，也可將兩個或多個步驟/部件或者步驟/部件的部分操作組合成新的步驟/部件，以實現(xiàn)本發(fā)明的目的。

上述根據(jù)本發(fā)明的方法可在硬件、固件中實現(xiàn)，或者被實現(xiàn)為可存儲在記錄介質(zhì)(諸如CD ROM、RAM、軟盤、硬盤或磁光盤)中的軟件或計算機代碼，或者被實現(xiàn)通過網(wǎng)絡下載的原始存儲在遠程記錄介質(zhì)或非暫時機器可讀介質(zhì)中并將被存儲在本地記錄介質(zhì)中的計算機代碼，從而在此描述的方法可被存儲在使用通用計算機、專用處理器或者可編程或專用硬件(諸如ASIC或FPGA)的記錄介質(zhì)上的這樣的軟件處理?？梢岳斫?，計算機、處理器、微處理器控制器或可編程硬件包括可存儲或接收軟件或計算機代碼的存儲組件(例如，RAM、ROM、閃存等)，當所述軟件或計算機代碼被計算機、處理器或硬件訪問且執(zhí)行時，實現(xiàn)在此描述的處理方法。此外，當通用計算機訪問用于實現(xiàn)在此示出的處理的代碼時，代碼的執(zhí)行將通用計算機轉換為用于執(zhí)行在此示出的處理的專用計算機。

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到變化或替換，都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應以所述權利要求的保護范圍為準。