Soa環(huán)境下的故障檢測方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001] 本申請涉及故障檢測技術(shù)領(lǐng)域，尤其涉及一種SOA環(huán)境下的故障檢測方法及裝 置。
【背景技術(shù)】
[0002] 隨著計(jì)算機(jī)技術(shù)的快速發(fā)展，出現(xiàn)很多新的服務(wù)架構(gòu)，例如，面向業(yè)務(wù)的架構(gòu) (Service-Oriented Architecture, S0A)就是一種新的服務(wù)架構(gòu)，它是一種粗粒度、松f禹合 的服務(wù)架構(gòu)，服務(wù)之間通過接口進(jìn)行通訊，不涉及底層編程接口和通訊模型，因此，SOA系統(tǒng) 能夠更加從容地面對業(yè)務(wù)的急劇變化。
[0003] 目前，在線上的SOA環(huán)境中，由于上線的代碼都經(jīng)過回歸測試確保了功能沒有問 題，故通常假設(shè)線上環(huán)境的代碼沒有錯(cuò)誤（BUG)。基于這個(gè)假設(shè)，導(dǎo)致系統(tǒng)不可用的原因就 只剩下容量不足，例如系統(tǒng)負(fù)載過高、數(shù)據(jù)庫（DB)負(fù)載過高等；物理資源異常，例如磁盤故 障、機(jī)器斷電、網(wǎng)絡(luò)設(shè)備故障等，故可以采用傳統(tǒng)的監(jiān)控方式監(jiān)控線上的環(huán)境。
[0004] 但是，在互聯(lián)網(wǎng)級別的SOA環(huán)境里，確保線上環(huán)境沒有錯(cuò)誤是非常困難的，具體原 因包括但不局限于以下幾點(diǎn) ：
[0005] (1)在互聯(lián)網(wǎng)級別的SOA環(huán)境里，量變導(dǎo)致質(zhì)變的場景很多，需要投入大量的代碼 來做異常情況的容錯(cuò)和恢復(fù)，比如DB(Database)掛了，應(yīng)用要自動(dòng)切換（failover)，網(wǎng)絡(luò) 異常套接字（socket)要斷線重連，主機(jī)（master)掛了，要重新選舉，吞吐量過大，要緩沖 排隊(duì)等等，這些邏輯在各種異常輸入的場景下無法保證互相配合沒有BUG，尤其在業(yè)務(wù)量大 增的情況下無法保證沒有BUG。
[0006] (2)大部分系統(tǒng)都有后臺的管理、規(guī)則的配置、動(dòng)態(tài)的調(diào)控，這些需要高級管理員、 運(yùn)營、運(yùn)維人員進(jìn)行操作，這些操作用例即使全部被測試100%覆蓋，也難以杜絕人為誤操 作。
[0007] (3)即使自身沒有BUG，但無法保證合作的第三方?jīng)]有BUG，例如支付寶下游的各 大銀行，他們的BUG會(huì)影響到支付寶的業(yè)務(wù)成功率。
[0008] (4)不是所有的容量問題都能通過物理機(jī)的性能指標(biāo)，例如負(fù)載（LOAD)來發(fā)現(xiàn)， 并且可能存在噪聲和盲點(diǎn)。
[0009] 由此可見，上述假設(shè)不能成立。當(dāng)上述假設(shè)不成立時(shí)，傳統(tǒng)的監(jiān)控方式就無法檢測 故障。
[0010] 另外，在傳統(tǒng)的監(jiān)控方案中，運(yùn)維人員每天都要收取大量的報(bào)警，少則幾百，多則 幾千，在這樣規(guī)模的報(bào)警下，報(bào)警已經(jīng)喪失了本身的價(jià)值。而公有云的機(jī)器故障其實(shí)都是 可以自動(dòng)化恢復(fù)的，但是運(yùn)維人員卻不敢取消報(bào)警--因?yàn)樗⒉恢涝跈C(jī)器自動(dòng)恢復(fù)之 后，程序是否恢復(fù)正常，沒有一個(gè)指標(biāo)告訴運(yùn)維人員業(yè)務(wù)和服務(wù)的健康狀態(tài)，而誤報(bào)、濫報(bào)、 漏報(bào)都可能會(huì)影響監(jiān)控效果。
[0011] 因此，迫切需要提供一種故障檢測方法，在線上有BUG的前提下，能夠及時(shí)發(fā)現(xiàn)故 障并找到故障原因。

【發(fā)明內(nèi)容】

[0012] 本申請旨在至少在一定程度上解決相關(guān)技術(shù)中的技術(shù)問題之一。
[0013] 為此，本申請的第一個(gè)目的在于提出一種SOA環(huán)境下的故障檢測方法，該方法在 線上有BUG的前提下，能夠及時(shí)發(fā)現(xiàn)故障。
[0014] 本申請的第二個(gè)目的在于提出一種SOA環(huán)境下的故障檢測裝置。
[0015] 為達(dá)上述目的，本申請第一方面實(shí)施例提出了一種SOA環(huán)境下的故障檢測方法， 所述SOA環(huán)境包括位于同一業(yè)務(wù)鏈的第一業(yè)務(wù)和第二業(yè)務(wù)，且所述第一業(yè)務(wù)位于所述業(yè)務(wù) 鏈的起點(diǎn)，所述第二業(yè)務(wù)位于所述業(yè)務(wù)鏈的終點(diǎn)，所述方法包括：獲得所述第一業(yè)務(wù)的第一 日志，并從所述第一日志中提取出輸入數(shù)據(jù)；獲得所述第二業(yè)務(wù)的第二日志，并從所述第二 日志中提取出輸出數(shù)據(jù)；以及將所述輸入數(shù)據(jù)和所述輸出數(shù)據(jù)進(jìn)行比對，定位出發(fā)生故障 的業(yè)務(wù)。
[0016] 本申請實(shí)施例的SOA環(huán)境下的故障檢測方法，通過從第一日志中提取出輸入數(shù)據(jù) 和從第二日志中提取出輸出數(shù)據(jù)，并將輸入數(shù)據(jù)和輸出數(shù)據(jù)進(jìn)行比對，定位出發(fā)生故障的 業(yè)務(wù)，從而在線上有BUG的前提下，能夠及時(shí)發(fā)現(xiàn)故障。
[0017] 為達(dá)上述目的，本申請第二方面實(shí)施例提出了一種SOA環(huán)境下的故障檢測裝置， 所述SOA環(huán)境包括位于同一業(yè)務(wù)鏈的第一業(yè)務(wù)和第二業(yè)務(wù)，且所述第一業(yè)務(wù)位于所述業(yè)務(wù) 鏈的起點(diǎn)，所述第二業(yè)務(wù)位于所述業(yè)務(wù)鏈的終點(diǎn)，所述裝置包括：第一提取模塊，用于獲得 所述第一業(yè)務(wù)的第一日志，并從所述第一日志中提取出輸入數(shù)據(jù)；第二提取模塊，用于獲得 所述第二業(yè)務(wù)的第二日志，并從所述第二日志中提取出輸出數(shù)據(jù)；以及第一定位模塊，用于 將所述第一提取模塊提取出的所述輸入數(shù)據(jù)和所述第二提取模塊提取出的所述輸出數(shù)據(jù) 進(jìn)行比對，定位出發(fā)生故障的業(yè)務(wù)。
[0018] 本申請實(shí)施例的SOA環(huán)境下的故障檢測裝置，通過第一提取模塊從第一日志中提 取出輸入數(shù)據(jù)和通過第二提取模塊從第二日志中提取出輸出數(shù)據(jù)，并通過第一定位模塊將 輸入數(shù)據(jù)和輸出數(shù)據(jù)進(jìn)行比對，定位出發(fā)生故障的業(yè)務(wù)，從而在線上有BUG的前提下，能夠 及時(shí)發(fā)現(xiàn)故障。
【附圖說明】
[0019] 圖1是本申請一個(gè)實(shí)施例的SOA環(huán)境的結(jié)構(gòu)示意圖。
[0020] 圖2是本申請一個(gè)實(shí)施例的SOA環(huán)境下的故障檢測方法的流程圖。
[0021] 圖3是本申請一個(gè)實(shí)施例的獲取輸入和輸出的示意圖。
[0022] 圖4是本申請一個(gè)實(shí)施例的用于推斷業(yè)務(wù)是否正常的報(bào)表的示意圖。
[0023] 圖5是本申請一個(gè)實(shí)施例的預(yù)期輸出和實(shí)際輸出的對比曲線的示意圖。
[0024] 圖6是本申請一個(gè)實(shí)施例的確定故障原因的流程圖。
[0025] 圖7是本申請一個(gè)實(shí)施例的確定故障原因的示意圖。
[0026] 圖8是本申請一個(gè)實(shí)施例的異常日志的示意圖。
[0027] 圖9是本申請另一個(gè)實(shí)施例的異常日志的示意圖。
[0028] 圖10是本申請一個(gè)實(shí)施例的SOA環(huán)境下的故障檢測裝置的結(jié)構(gòu)示意圖。
【具體實(shí)施方式】
[0029] 下面詳細(xì)描述本申請的實(shí)施例，所述實(shí)施例的示例在附圖中示出，其中自始至終 相同或類似的標(biāo)號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附 圖描述的實(shí)施例是示例性的，旨在用于解釋本申請，而不能理解為對本申請的限制。
[0030] 目前，針對線下單機(jī)環(huán)境，可以通過單元測試、調(diào)試（debug)、查看日志、卸出 (dump)內(nèi)存等方式，檢測出環(huán)境故障。但線上SOA環(huán)境和線下單機(jī)環(huán)境完全不同，線上SOA 環(huán)境包括多種業(yè)務(wù)，每種業(yè)務(wù)對應(yīng)一個(gè)集群系統(tǒng)（cluster)，而每個(gè)集群系統(tǒng)由多個(gè)系統(tǒng)組 成，
[0031] 如圖1所示。具體地，從故障排查的角度看，二者的區(qū)別如表1所示：
[0032] 表1線上SOA環(huán)境和線下單機(jī)環(huán)境的區(qū)別
[0033]
[0035] 由此可見，線上SOA環(huán)境和線下環(huán)境的差別主要體現(xiàn)在以下兩個(gè)方面：
[0036] 首先是安全、條件等因素。線下很多可以做的操作，在線上是禁止的，例如debug、 從DB中取數(shù)據(jù)（很多測試用例都會(huì)從DB中取數(shù)據(jù)作為輸出校驗(yàn)）、dump (線上的dump會(huì)影 響性能）、日志操作（曾經(jīng)有運(yùn)維人員對一個(gè)重要系統(tǒng)的日志執(zhí)行了 VI (Visual interface, VI編輯器）操作導(dǎo)致嚴(yán)重故障）等等。
[0037] 其次體現(xiàn)在量變導(dǎo)致質(zhì)變上。機(jī)器的數(shù)量從1個(gè)變?yōu)槌汕先f，要考慮的依賴關(guān) 系從內(nèi)部的模塊變成了成百上千個(gè)集群之間錯(cuò)綜復(fù)雜的業(yè)務(wù)。換言之，可以對單機(jī)的程序 做debug，但即使有一萬個(gè)工程師能夠同時(shí)對線上的一萬臺機(jī)器（即服務(wù)器）做debug，也 很難將各自的分析結(jié)果匯總聚合輸出有價(jià)值的信息。
[0038] 所以在SOA的分布式環(huán)境下，檢測故障的難點(diǎn)在于：
[0039] 1)單機(jī)上的經(jīng)驗(yàn)很難簡單地復(fù)用，由于SOA系統(tǒng)對侵入性的不可容忍，所以 debug、dump等分析方式都無法施行。即使是日志分析也要小心翼翼不能耗費(fèi)CPU、內(nèi)存資 源。
[0040] 2)機(jī)器數(shù)量眾多，依賴關(guān)系復(fù)雜，導(dǎo)致關(guān)鍵的數(shù)據(jù)容易被淹沒。例如在發(fā)生故障 時(shí)，不知從幾萬臺機(jī)器中的哪一臺來查看指標(biāo)，也不知道選擇哪些系統(tǒng)來分析故障原因。
[0041] 綜上所述，單機(jī)指標(biāo)數(shù)據(jù)難以直接參考，比如我們希望確認(rèn)當(dāng)前的關(guān)鍵業(yè)務(wù)有無 故障，但是單機(jī)上僅僅能夠推斷出此臺機(jī)器的業(yè)務(wù)量，無法得知整個(gè)SOA環(huán)境的業(yè)務(wù)健康 狀況。在單機(jī)發(fā)現(xiàn)一個(gè)異常的指標(biāo)時(shí)也難以推斷它是故障根源還是受害者。在單機(jī)上分析 出一種故障行為時(shí)也難以判斷它是單機(jī)特例還是集群的普遍現(xiàn)象。針對上述情況，本申請 實(shí)施例利用日志來實(shí)現(xiàn)和線下單機(jī)環(huán)境檢測效果類似的故障檢測方案。
[0042] 下面參考附圖描述本申請實(shí)施例的SOA環(huán)境下的故障檢測方法及裝置。
[0043] 圖2是本申請一個(gè)實(shí)施例的SOA環(huán)境下的故障檢測方法的流程圖，在該實(shí)施例中， SOA環(huán)境包括位于同一業(yè)務(wù)鏈的第一業(yè)務(wù)和第二業(yè)務(wù)，且第一業(yè)務(wù)位于業(yè)務(wù)鏈的起點(diǎn)，第二 業(yè)務(wù)位于業(yè)務(wù)鏈的終點(diǎn)，如圖2所示，該方法包括：
[0044] S201，獲得第一業(yè)務(wù)的第一日志，并從第一日志中提取出輸入數(shù)據(jù)。
[0045] 從第一日志中提取出輸入數(shù)據(jù)可以為：根據(jù)第一日志獲得匹配的第一日志模型， 使用第一日志模型從第一日志中提取出輸入數(shù)據(jù)，其中，該第一日志模型包括解析規(guī)則，還 可以包括解析權(quán)限等信息。
[0046] S202，獲得第二業(yè)務(wù)的第二日志，并從第二日志中提取出輸出數(shù)據(jù)。
[0047] 在線下單機(jī)環(huán)境，利用測試用例來檢查是否存在故障，其本質(zhì)是將輸入和輸出進(jìn) 行比對，也就是為其能夠提供的業(yè)務(wù)全部準(zhǔn)備一個(gè)測試用例，模擬（mock)它