業務狀態處理方法和裝置與流程

本發明涉及通訊技術領域，具體而言，涉及業務狀態處理方法和裝置。

背景技術：

隨著互聯網浪潮的興起和“互聯網+”概念的普及，各類互聯網業務蓬勃發展，互聯網產品大量涌現。在這種趨勢下，同一類型的產品往往同時面臨幾十、上百款競品，行業競爭異常激烈。為了能夠緊跟用戶需求、不斷試錯、提升用戶體驗，業務的開發和迭代周期也被一再縮短。

現階段行業內，針對業務系統運行狀態的監控主要基于TPC、SPEC、HPCC等搭建而來。以上做法基本上都是搭建一個專屬的業務監控系統，然后在各項業務子進程中添加監控點，將各個監控點的數據進行匯總分析，同時相伴的還有一個專屬的分析系統并將分析結果集成在一個后臺系統中用于展示。這些系統都能夠提供詳盡的業務系統運行狀態數據，包括每個業務節點的訪問量，丟包率，超時等。

目前，常見的業務監控系統的工作流程是用戶通過客戶端等終端向服務器發送請求之后，中心服務器就會將請求轉發到對應的業務服務器上，然后對應業務服務器上的業務模塊就會執行業務處理，并向其所位于的業務服務器上的監控采集模塊發送業務監控數據，其中所述業務監控數據以預定格式指示業務模塊名稱和監控點名稱；在達到預定的時間間隔時由所述監控采集模塊基于至少一個所接收的業務監控數據生成監控信息；將所生成的監控信息發送到監控服務器；由所述監控服務器存儲所接收的監控信息；以及由所述監控服務器按照統計時間間隔基于所存儲的監控信息生成分級統計匯總數據。其中評判業務系統的健康程度時經常使用TPC、SPEC、Linpack、HPCC等，這些方法能夠從處理器性能、服務器系統性能、商業應用性能等方面模擬或者量化線上業務請求，然后給出了一個量化的評價指標。

一般TPC類型服務器評測體系的做法是在一個服務器上安裝一個數據庫,然后在數據庫模擬一些標準化操作,最后會得到數據庫每分鐘處理事務數或數據庫每秒鐘處理事務數這兩種統計結果。TPC就是用這兩種統計結果來評價服務器的性能；一般SPEC服務器評測體系的做法是一個全面衡量Web應用中java企業應用服務器性能的基礎測試。在這個基準測試中，系統模擬一個現代化企業的電子化業務工作，如客戶定購查詢、產品生產制造管理、供應商等，給系統以巨大的負載，以全面測試運行典型java業務應用的服務器性能水平；一般Linpack服務器評測體系的做法是在目標集群中運行Linpack測試程序,測試結果以浮點運算每秒(Flops)給出。其中：MFlops＝每秒一百萬次(10^6)浮點運算、GFlops＝每秒十億次(10^9)浮點運算。

隨著互聯網產品需求的高速變更，業務開發時的敏捷及快速迭代要求，從現階段監控系統的工作流程中可以看出，雖然上述這些傳統的業務監控系統能夠對業務系統提供詳細的運行狀態數據，但也暴露出很多弊端：

首先，傳統監控系統需要在各個子項業務中添加監控點，當業務快速擴張時需要添加的監控點也急速增多，這無疑增大了開發的復雜度和任務量，需要大量人力資源；其次，快速增多的監控數據，也要求對監控點的匯總分析系統進行快速迭代，這會占用更多的人力資源；再次，監控數據的增多也需要投入大量的開發資源和服務器資源，占用資源降低速度；最后，在業務快速擴張的過程中，人力物力都會比較緊張，難以維護一個同樣快速膨脹的監控系統，監控系統的有效性就會大打折扣。

綜上，傳統方式打造的監控系統很難適應高速擴張的業務系統，現在常用的業務監控系統不適用于業務高速發展的互聯網業務，而且缺乏對業務報警擴展能力的支持，具有應用的局限性。

針對現有技術中采用監控點進行監控的監控系統所存在的問題，目前尚未提出有效的解決方案。

技術實現要素：

本發明提供了一種業務狀態處理方法和裝置，以解決現有技術中采用監控點進行監控的監控系統所存在的問題。

根據本發明實施例的一個方面，提供了一種業務狀態處理方法，包括：在預定周期內，獲取業務中的每個子業務對應的服務進程的運行狀態；對所述每個子業務對應的服務進程的運行狀態進行匯總得到第一匯總結果；根據所述第一匯總結果確定所述業務的狀態。

進一步地，在確定所述業務狀態之后，所述方法還包括：在所述業務的狀態符合第一預定條件和/或所述子業務對應的服務進程的運行狀態符合第二預定條件的情況下，進行告警。

進一步地，獲取業務中的每個子業務對應的服務進程的運行狀態包括：統計所述每個子業務對應的服務進程每次對接受到請求的處理時間；在所述預定周期內對所述處理時間進行累積得到累計結果；根據所述累積結果獲取所述預定周期內的運行狀態。

進一步地，根據所述累積結果獲取所述預定時間內的運行狀態包括：計算所述預定周期內的所述每個子業務對應的服務進程處理接收到請求的理論處理時間的上限；將所述累積結果與所述理論處理時間的上限的比值作為健康值，其中，所述健康值用于標識所述運行狀態。

進一步地，所述方法還包括：對預定時間段內的所述每個子業務對應的服務進程的每個所述預定周期的運行狀態進行匯總得到的第二匯總結果，其中，所述預定時間段大于所述預定周期；根據所述第二匯總結果確定所述業務的狀態。

進一步地，對所述每個子業務對應的服務進程的運行狀態進行匯總還包括：獲取所述預定時間段內所述每個子業務對應的服務進程的總運行狀態；對所述每個子業務對應的服務進程的總運行狀態進行排序。

進一步地，對所述每個子業務對應的服務進程的運行狀態進行匯總還包括：對所述總運行狀態的排序結果進行告警。

進一步地，所述預定周期為時間片。

根據本發明實施例的另一方面，提供了一種業務狀態處理裝置。根據本發明的業務狀態處理裝置包括：獲取單元，用于在預定周期內，獲取業務中的每個子業務對應的服務進程的運行狀態；匯總單元，用于對所述每個子業務對應的服務進程的運行狀態進行匯總得到第一匯總結果；確認單元，根據所述第一匯總結果確定所述業務的狀態。進一步地，所述業務狀態處理裝置還包括：告警單元，用于在所述業務的狀態符合第一預定條件和/或所述子業務對應的服務進程的運行狀態符合第二預定條件的情況下，進行告警。

進一步地，所述獲取單元包括：統計模塊，用于統計所述每個子業務對應的服務進程每次對接受到請求的處理時間；累計模塊，用于在所述預定周期內對所述處理時間進行累積得到累計結果；第一獲取模塊，用于根據所述累積結果獲取所述預定周期內的運行狀態。

進一步地，所述第一獲取模塊用于：計算所述預定周期內的所述每個子業務對應的服務進程處理接收到請求的理論處理時間的上限；并將所述累積結果與所述理論處理時間的上限的比值作為健康值，其中，所述健康值用于標識所述運行狀態。

進一步地，所述匯總單元還用于對：預定時間段內的所述每個子業務對應的服務進程的每個所述預定周期的運行狀態進行匯總得到的第二匯總結果，其中，所述預定時間段大于所述預定周期；所述確認單元還用于：根據所述第二匯總結果確定所述業務的狀態。

進一步地，所述匯總單元還包括：第二獲取模塊，用于獲取所述預定時間段內所述每個子業務對應的服務進程的總運行狀態；排序模塊，用于對所述每個子業務對應的服務進程的總運行狀態進行排序。

進一步地：所述匯總單元還包括：告警模塊，用于對所述總運行狀態的排序結果進行警告。

根據發明實施例，采用了在預定周期內，獲取業務中的每個子業務對應的服務進程的運行狀態；對所述每個子業務對應的服務進程的運行狀態進行匯總得到第一匯總結果；根據所述第一匯總結果確定所述業務的狀態。通過本發明解決了現有技術中采用監控點進行監控的監控系統所存在的問題，改善了監控效果。

附圖說明

構成本申請的一部分的附圖用來提供對本發明的進一步理解，本發明的示意性實施例及其說明用于解釋本發明，并不構成對本發明的不當限定。在附圖中：

圖1是根據本發明實施例的一種業務狀態處理方法的流程圖；

圖2是根據本發明實施例的一種業務狀態處理方法的系統結構圖；

圖3是根據本發明實施例的一種業務狀態處理方法的數據流程圖；

圖4是是根據本發明實施例的一種業務狀態處理方法的每日匯總郵件示意圖；

圖5是根據本發明實施例的一種業務狀態處理裝置的具體硬件架構示意圖；以及

圖6是根據本發明實施例的一種業務狀態處理裝置的示意圖。

具體實施方式

需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。下面將參考附圖并結合實施例來詳細說明本發明。

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

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

本發明實施例提供了一種業務狀態處理方法。圖1是根據本發明實施例的一種業務狀態處理方法的流程圖。如圖1所示，該方法包括步驟如下：

步驟S102，在預定周期內，獲取業務中的每個子業務對應的服務進程的運行狀態；

步驟S104，對每個子業務對應的服務進程的運行狀態進行匯總得到第一匯總結果；

步驟S106，根據第一匯總結果確定該業務的狀態。

在上述步驟，采用了監控一個業務中的每個子業務服務進程的狀態，通過這種狀態的匯總就可以得知該業務的運行情況，這不同于現有技術中的設置不同監控點的處理方法，在業務的流程進行調整之后，由于上述步驟當中并沒有針對業務本身的流程設置監控點，所以不需要對監控進行太大的調整。從而解決了現有技術中采用監控點進行監控的監控系統所存在的問題，改善了監控效果。

例如，如果將注冊看成一個業務，在該業務中有一個短信發送接收處理子業務，該子業務對應一個服務進程。由于某種原因需要對短信的發送接收的流程進行改動，將原來發送一次短信修改為發送多次短信，此時按照現有技術中的處理，需要增加多個監控點，這樣的處理比較繁瑣，而在上述步驟中，雖然流程發生了變動，但是服務進程仍然是在運行中，監控的是服務進程，此時只需要觀察服務進程的負荷是否變化即可，而不需要對監控的流程進行調整。

上述步驟中的預定的周期可以根據實際的需要進行調整，對于一個業務的所有的子業務可以采用同樣的周期，也可以對不同的子業務采用不同的周期。作為一個可選的方式，對子業務采用的不同周期可以根據子業務的優先級來確定。例如，如果一個子業務的優先級很高，即該子業務比較重要，周期就可以設置的短一點，如果該子業務的級別比較低，周期可以設置的長一點。這樣的處理可以把有限的監控資源使用到比較重要的地方，提高監控的效果。

在一個可選的實施方式中，可以通過定時器來實現周期，此時可以在總的業務流程中設置一個定時器，在一個固定可調整的時間段內統計每一個業務進程的運行狀態。也可以對于業務的每個子業務均設置一個定時器，用來統計每個子業務的運行狀態。

運行狀態的表示方法有很多種，例如，可以通過獲取服務進程的負載情況來判斷服務進程的運行狀態，服務進行的負載狀況可以通過對請求的處理時間來進行表示，當然也可以使用其他的參數來進行表示，可以根據實際的需要來確定使用什么類型的參數來表示服務進程負載。在一個可選實施方式中，采用了處理時間表示，此時，獲取業務中的每個子業務對應的服務進程的運行狀態可以包括如下步驟：

步驟S202，統計每個子業務對應的服務進程每次對接受到請求的處理時間，即計算每次的處理耗時時間；

步驟S204，在預定周期內對處理時間進行累積得到累計結果；即計算出當前統計周期內的總處理耗時時間；

步驟S206，根據累積結果獲取預定周期內的運行狀態。

通過上述步驟使用了處理時間來表示運行狀態，這是由于處理時間相對其他參數而言更能表示運行狀態，會取得相對較好的監控效果。

為了使運行狀態表示的更加形象，在一個可選實施方式中，可以使用健康度這個詞來表示運行狀態，例如，在每個業務進程內對當前統計周期內每一個外部請求的處理耗時做累積，進而計算出當前統計周期內的總處理耗時時間。

在確定上述業務狀態之后，在一個可選實施方式中，可以針對整個業務來進行告警，也可以根據每個子業務進行告警，即，在業務的狀態符合第一預定條件和/或子業務對應的服務進程的運行狀態符合第二預定條件的情況下，進行告警。第一預定條件和第二預定條件可以包括很多種情況，例如，根據不同的健康度設置告警閾值。例如，當實時健康度高于75實時通過短信，可以通過即時通訊軟件進行告警。此處的健康度可以是業務的健康度，一個業務的健康度可以是由組成其的子業務的健康度經過計算得到的。也可以是子業務的健康度，每個子業務的健康度不符合閾值則可以針對該子業務進行單獨報警。

通過上述步驟中判斷預定條件的方式判斷子業務對應的服務進程的運行狀態，可以更加準確快速的對業務狀態進行監控，能夠及時發現問題反饋，每一個子業務有所變動時可以及時的獲得告警信息。下面以一個可選實施方式進行說明。

在該例子中，第一預定條件用來判斷針對業務是否需要進行告警，在該情況下可以分別獲取每個子業務的健康度，然后進行匯總，判斷匯總后的健康度是否超過閾值，如果超過健康度閥值則進行告警。第二預定條件可以針對子業務的健康度進行告警，在這種情況下，如果一個子業務的健康度不符合條件，則針對該子業務進行單獨告警。在該例子中，健康度閥值可以包括至少兩個閾值，其中一個閾值對應于業務，所有的子業務可以對應一個閾值，或者也可以每個子業務均對應一個閾值，或者也可以對子業務進行分組，每組子業務對應一個閾值。滿足這些閾值可以認為是符合第一預定條件和/或第二預定條件。例如，實時健康度的數值范圍是0-100區間，0表示最空閑，100表示最忙。設定健康度閥值為75，當實時健康度高于75實時通過短信、易信告警。該例子的75的健康度閾值可以是針對一個子業務的，也可以是針對一組子業務的，或者也可以是針對業務的。

在一個可選的實施方式中，步驟S206累積結果獲取預定時間內的運行狀態包括：計算預定周期內的每個子業務對應的服務進程處理接收到請求的理論處理時間的上限；將累積結果與理論處理時間的上限的比值作為健康值，其中，健康值用于標識運行狀態。

通過對健康值具體的計算，來使運行狀態的評估更加精確化。

例如：用總處理耗時時間和統計周期內理論的處理時間上限做百分比除法而算出當前統計周期的實時健康度。實時健康度的數值范圍是0-100區間，0表示最空閑，100表示最忙。

在一個可選的實施方式中，可以對預定時間內的每個子業務分別對應的總的運行狀態進行匯總得到匯總結果，例如，可以對短信處理進行一個月內的運行狀態進行匯總，然后將一個月內的所有的子業務的運行狀態都進行匯總得到該業務的在這一個月內的運行情況。這一個月的時間是可以自由設定的，這樣可以使用戶不僅僅了解一個周期內的運行情況，還可以了解一個比較長的時間段的總體的運行情況。即，在該可選實施例中，

即，上述方法還可以包括：對預定時間段內的每個子業務對應的服務進程的每個預定周期的運行狀態進行匯總得到的第二匯總結果，其中，預定時間段大于預定周期。

為了描述方便，可以將該預定時間段的匯總所有子業務狀態得到的結果稱為是第二匯總結果。在這種情況下，該可選實施方式可以通過如下步驟實現：

對預定時間段內的每個子業務對應的服務進程的每個預定周期的運行狀態進行匯總，得到第二匯總結果；

根據第二匯總結果確定業務在預定時間段內的狀態。

通過上述步驟在預定時間段內的對各子業務運行狀態的匯總，可以對某一段時間內的運行狀態進行監控統計，了解到每一段時間內業務的運行狀態及變化。例如：也可以將當天所有子業務處理進程的實時健康度進行匯總。

在一個可選的實施方式中，對每個子業務對應的服務進程的運行狀態進行匯總還包括：獲取預定時間段內每個子業務對應的服務進程的總運行狀態；對每個子業務對應的服務進程的總運行狀態進行排序。

通過將服務進程的總運行狀態排序，可以更加直觀的看到運行狀態的優先需要注意的次序，從而方便快捷的監控運行狀態。例如，按照各個業務，把業務的所有進程當天的實時健康度求和即得到該業務的當天的總健康度，然后對所有子業務按照總健康度的值從大到小排序。通過上述方式每天都能根據健康度排序數據發現有排名異動的業務，可以快速的發現還處于異常初期的業務，便于進一步進行業務優化。隨著業務需求的變動也可以了解到各個業務的服務器資源使用情況，按照健康度排序的指標可以有針對的進行系統部署調整，對健康度較高的業務增加部署，健康度較低的業務減少部署。既滿足業務需求，也減少服務器資源浪費。

在一個可選的實施方式中,對每個子業務對應的服務進程的運行狀態進行匯總還包括：對總運行狀態的排序結果進行告警。

通過以上方法，每當業務有異常的時候會都會實時收到該子業務的告警，保證了事件處理的及時性。

告警的方式可以有很多種，作為可選的實施方式可以通過發送郵件、短信和/或即時消息進行告警，這里的即時消息是指通過即時通訊軟件發送的消息。通過使用不同分類報警，能夠快速的應對系統中出現的突發問題，具有很好的擴展性。

周期可以按照不同的時間粒度來進行設計，例如，可以是按照秒來設置周期，也可以是按照毫秒設置周期等，在一個可選的實施方式中，預定周期可以為系統中的時間片。通過選擇使用時間片來判斷業務的運行狀態，根據不同的時間片準確的區分系統運行狀態，即系統健康度的信息，從而降低了開發難度和工作量。

作為可選的方式可以是：在總的業務流程中設置一個定時器，服務器在一個固定可調整的時間段內統計每一個業務進程的運行狀態(計算子業務的負載)，相當于計算健康度，并設置不同等級的健康度超限閾值，可以包括負載數據閥值和變化量閥值，這兩個閾值均可以作為業務的閾值來進行告警判斷，也可以作為每個子業務的閾值來進行判斷。作為業務的閾值來進行判斷的情況下，這兩個閾值作為上述實施例的第一預定條件；作為子業務的閾值來進行判斷的情況下，這兩個閾值可以作為上述實施例的第二預定條件。根據這兩個閾值可以得到健康度，如果健康度低于超限閾值時就會觸發相對應的實時告警，以IM、郵件或短信的方式發出消息。同時各個業務也會每天進行一次健康度排序，發出總的統計郵件，進而對業務系統進行長期跟蹤。

上述實施例通過選擇使用時間片來判斷業務的運行狀態，能夠提供較為準確的系統健康度信息，同時降低了開發難度和工作量，提供系統分類報警能夠快速應對系統中出現的突發問題，具有很好的擴展性，從而能夠更好的適應快速迭代的互聯網產品業務。

下面結合一個可選的實施例進行說明。

圖3是根據本發明實施例的一種業務狀態處理方法的數據流程圖，作為可選的實施方式，如圖3所示，一個子業務的狀態數據從產生到匯總的分級過濾處理過程可以如下：

一個典型的業務系統是由許多個子業務組合而來的，各個子業務分別對應處理各自的業務需求和任務。服務器響應請求后，通過不斷的檢查各個子業務的運行狀態，即計算各個子業務的負載數據，然后匯總在一起進行分析過濾，根據這些子系統的運行狀態數據(也就是負載數據)來確定業務系統的健康度。常見的業務產品開發是一個開發團隊完成的，每個開發負責自己開發的子業務，也就更加了解自己開發的業務實現細節，能夠更快速的發現問題并解決問題。通過按照子業務劃分的方式可以快速找到相關開發人員，便于快速處理突發問題，同時負責該業務的開發人員也可以通過查閱相關數據來判斷是否需要進行優化等操作。

其中在各子業務中設置一個固定的時間，在相隔一段時間之后就會上報一次自身的運行情況(即負載數據)；設置時間的具體的實現方法是在系統處理任務的底層類中添加一個統計任務運行時間的函數方法，每一個繼承該底層類的業務處理都會執行到這個方法，也就會統計到沒執行一次任務的耗時，然后在全局設定STAT_CYCLE時間片作為固定的時間段，定時上報自己的運行時間數據，同時還會與系統分配的時間上限進行百分比計算，上述計算結果作為業務運行的閾值，閾值的具體的計算公式(1)如下：

run_load＝self.pro_time/(self.thread_num×STAT_CYCLE) (1)

其中run_load為負載的值，self.pro_time為子業務在一個時間片內執行任務的耗時，self.thread_num為子業務的線程數目，STAT_CYCLE為時間片。

告警提示是在將各個子業務的負載信息匯總以后，添加一個分析過濾程序定時將匯總的數據發送到IM聊天公眾號，便于開發團隊及時了解系統健康度狀態。同時匯總系統還會每日早上發送上一天的匯總數據郵件，這樣可以更加直觀的了解各項子系統的負載和變化情況。在業務匯總中還有一個分級過濾，如果某項子業務的負載數據超過設定的閾值，就會觸發業務報警，系統會將該子業務的相關信息通過短信、IM、郵件等多種方式發送給相關業務責任人。這樣業務的開發者就能夠在第一時間處理對應的問題，保證了業務系統的安全性和穩定性。具體可以參看圖5為本實施例一種業務狀態處理方法的具體硬件架構示意圖，如圖5所示，常見的業務系統一般都采用典型的分布式系統，在多個服務器中分別運行各個子業務。各個子業務產生的狀態數據匯總到一臺匯總分析服務器中。

圖2為本實施例的系統結構圖，如圖2所示，PC客戶端、移動端、web端的請求都會轉發到各個對應的子業務中，在子業務中統計每次的請求處理時間，然后根據負載計算公式計算出負載，將各子系統的負載數據匯總在一起。數據匯總模塊還會對負載數據進行過濾，設定了負載的閾值和負載變化量的閾值。如果負載過高或者變化量過大就會觸發報警。在本發明中，設定了STAT_CYCLE為60s，負載的閾值為75％，如果超過這個值就會想對應的開發人員發送短信和IM消息預警。同時數據匯總模塊還會向IM消息發送子系統的負載值，隨著時間的流失就描繪出一條隨時間的負載曲線，描述了系統的健康度。圖4是本實施例的每日匯總郵件示意圖，如圖4所示，從負載排序中可以清楚的看出系統各子業務的運行健康狀態(具體數據參看第二行數據，數據越小代表業務越健康)。同時還可以與以前數據相對比。另外從截圖中還可以看出一個常見產品一般都含有幾百甚至上千個子業務，這些子業務同時還處在不斷迭代和調整中。如果每個業務都需要在開發中添加監控點，提供請求來源，請求參數等信息，就會占用較大的開發資源，這樣就會拖慢開發的進度。但是本發明是在基類中添加了統計任務執行時長的方法，不需要任何額外的開發工作，同時也能夠較好的檢測系統的健康度狀態，提供負載數據，還可以提供預警功能。

本發明實施例還提供了一種業務狀態處理裝置。該裝置可以通過獲取模塊和匯總模塊實現其功能。需要說明的是，本發明實施例的一種業務狀態處理裝置裝置可以用于執行本發明實施例所提供的一種業務狀態處理方法，本發明實施例的一種業務狀態處理方法也可以通過本發明實施例所提供的一種業務狀態處理裝置來執行。

圖6是根據本發明實施例的一種業務狀態處理裝置的示意圖。如圖6所示，一種業務狀態處理裝置包括：

獲取單元62，用于在預定周期內，獲取業務中的每個子業務對應的服務進程的運行狀態；

匯總單元64，用于對每個子業務對應的服務進程的運行狀態進行匯總得到第一匯總結果；

確認單元66，根據第一匯總結果確定業務的狀態。

在一個可選的實施方式中，還包括：

告警單元，用于在業務的狀態符合第一預定條件和/或子業務對應的服務進程的運行狀態符合第二預定條件的情況下，進行告警。

在一個可選的實施方式中，獲取單元包括：

統計模塊，用于統計每個子業務對應的服務進程每次對接受到請求的處理時間；

累計模塊，用于在預定周期內對處理時間進行累積得到累計結果；

第一獲取模塊，用于根據累積結果獲取預定周期內的運行狀態。

在一個可選的實施方式中，第一獲取模塊用于計算預定周期內的每個子業務對應的服務進程處理接收到請求的理論處理時間的上限，并將累積結果與理論處理時間的上限的比值作為健康值，其中，健康值用于標識運行狀態。

在一個可選的實施方式中，匯總單元還用于：對預定時間段內的每個子業務對應的服務進程的每個預定周期的運行狀態進行匯總，得到第二匯總結果；

確認單元還用于：根據第二匯總結果確定業務在預定時間段內的狀態。

在一個可選的實施方式中，匯總單元還包括：

第二獲取模塊，用于獲取預定時間段內每個子業務對應的服務進程的總運行狀態；

排序模塊，用于對每個子業務對應的服務進程的總運行狀態進行排序。

在一個可選的實施方式中，匯總單元還包括：

告警模塊，用于對總運行狀態的排序結果進行警告。

在一個可選的實施方式中，告警模塊或告警單元用于通過發送郵件、短信和/或即時消息進行告警。

上述一種業務狀態處理裝置裝置實施例是與一種業務狀態處理方法相對應的，所以對于有益效果不再贅述。通過上述實施例的分析描述，相對于傳統的業務系統的健康度(每個子業務對應的服務進程運行狀態)檢測來說，上述實施例中的部分可選實施方式有以下技術上的效果：

1.開發簡單高效，節省人力物力

與其他常見的監控系統不同的是，本發明沒有在各個子系統中添加監控點，沒有定制監控模塊，沒有定制分析模塊。不需要區分請求來源等數據，大量減少了開發的工作量。在業務的基類中添加一個統計任務用時(可以指在預定周期內統計服務進程的運行狀態)，基本上沒有任何新增的工作量，同時數據又能準確的反應系統的運行健康度情況，節省了人力物力。

2.實時監控各子業務的運行負載情況

本發明設定了可配置的時間片，每相隔一段時間，例如一分鐘，各個子業務系統就會上報一次業務的負載情況(每個子業務對應的服務進程運行狀態)，然后通過匯總服務器轉發到郵件或者IM通訊軟件上，方便實時的查看運行數據，即進行告警。

3.按業務劃分，便于進行優化處理和應對突發情況

本發明是根據各個子業務進行區分，匯總業務的負載情況(進程運行狀態)。當負載超過了設定的閾值就會觸發預警信息，通知相關開發人員。可以進行有針對性的優化。同時系統如果出現問題就會出現負載異常，同樣可以設定負載的判斷閾值和變化閾值，當這些值超過了設定的閾值(預定的條件)之后就會通過短信、IM消息、郵件等發送給責任人，能夠在第一時間發現并解決問題。

本發明上述實施例中所提及的時間片長度、過濾數據的閾值、以及判斷業務異常的預警閾值都是可以動態調整的，并不一定要包含實施例中所列示的各個性能參數。

上述實施例的監控參數僅為常用的監控服務器性能指標。

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

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

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

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目的。

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

所述集成的單元如果以軟件功能單元的形式實現并作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中。基于這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可為個人計算機、移動終端、服務器或者網絡設備等)執行本發明各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括：U盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、移動硬盤、磁碟或者光盤等各種可以存儲程序代碼的介質。

以上所述僅為本發明的優選實施例而已，并不用于限制本發明，對于本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。