本申請涉及互聯網技術領域,尤其涉及一種服務調用異常時的處理方法和裝置。
背景技術:
面向服務的體系架構(service-orientedarchitecture,soa)是一個組件模型,它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯系起來。在大型soa系統中,通常一個業務處理的鏈路需要2個以上系統,十多次甚至幾十次系統調用才能完成一次業務。目前soa系統之間的調用,一般是每個系統返回自己系統定義的特定的錯誤碼,每個系統只感知所直接調用的下游應用的異常。
一旦出現服務調用異常,需要逐層進行排查,當鏈路較長時需要的排查時間較長,定位問題的速度較慢。
技術實現要素:
本申請旨在至少在一定程度上解決相關技術中的技術問題之一。
為此,本申請的一個目的在于提出一種服務調用異常時的處理方法,該方法可以在發生服務調用異常時迅速定位問題所在的系統。
本申請的另一個目的在于提出一種服務調用異常時的處理裝置。
為達到上述目的,本申請第一方面實施例提出的服務調用異常時的處理方法,包括:在出現服務調用異常時,生成本層系統的錯誤碼;將本層系統的錯誤碼添加到返回結果中,其中,當下層系統出現服務調用異常時,所述返回結果中包含下層系統的錯誤碼;如果需要向上層系統反饋結果,將所述返回結果發送給上層系統。
本申請第一方面實施例提出的服務調用異常時的處理方法,通過在返回結果中包含出現服務調用異常的不同層的系統的錯誤碼,可以實現錯誤碼逐層上傳,從而在需要定位問題時,可以根據返回結果直接定位到出現問題的系統,從而提高定位問題的速度。
為達到上述目的,本申請第二方面實施例提出的服務調用異常時的處理裝置,包括:生成模塊,用于在出現服務調用異常時,生成本層系統的錯誤碼;添加模塊,用于將本層系統的錯誤碼添加到返回結果中,其中,當下層系統出現服務調用異常時,所述返回結果中包含下層系統的錯誤碼;反饋模塊,用于在需要向上層系統反饋結果時,將所述返回結果發送給上層系統。
本申請第二方面實施例提出的服務調用異常時的處理裝置,通過在返回結果中包含出現服務調用異常的不同層的系統的錯誤碼,可以實現錯誤碼逐層上傳,從而在需要定位問題時,可以根據返回結果直接定位到出現問題的系統,從而提高定位問題的速度。
本申請附加的方面和優點將在下面的描述中部分給出,部分將從下面的描述中變得明顯,或通過本申請的實踐了解到。
附圖說明
本申請上述的和/或附加的方面和優點從下面結合附圖對實施例的描述中將變得明顯和容易理解,其中:
圖1是本申請一實施例提出的服務調用異常時的處理方法的流程示意圖;
圖2是本申請實施例中系統交互示意圖;
圖3是本申請另一實施例提出的服務調用異常時的處理方法的流程示意圖;
圖4是本申請另一方面實施例提出的服務調用異常時的處理裝置的結構示意圖;
圖5是本申請另一方面實施例提出的服務調用異常時的處理裝置的結構示意圖。
具體實施方式
下面詳細描述本申請的實施例,所述實施例的示例在附圖中示出,其中自始至終相同或類似的標號表示相同或類似的模塊或具有相同或類似功能的模塊。下面通過參考附圖描述的實施例是示例性的,僅用于解釋本申請,而不能理解為對本申請的限制。相反,本申請的實施例包括落入所附加權利要求書的精神和內涵范圍內的所有變化、修改和等同物。
圖1是本申請一實施例提出的服務調用異常時的處理方法的流程示意圖,該方法包括:
s11:在出現服務調用異常時,生成本層系統的錯誤碼。
如圖2所示,假設一個業務處理的鏈路包括:系統a、系統b、系統c、系統d、系統e和系統f,相互之間的調用關系包括:合作伙伴調用系統a (1)、系統a調用系統b(2),系統b返回響應給系統a(3)、系統a再調用系統c(4)等。系統a、系統b等例如為支付寶系統,合作伙伴是需要調用支付寶的第三方,例如,購物網站(如淘寶)等。
當一個系統出現服務調用異常時,例如,系統e出現服務調用異常時,系統e生成本層的錯誤碼。
不同層的系統生成的錯誤碼具有相同的固定格式,具體的固定格式不限定。例如,每層生成的錯誤碼的格式如表1所示。
表1
其中:
1至8位固定標識:可以按大的業務劃分來確定,如國際支付的前綴名為ipay,國內支付為alipay,具體的長度可根據定義的前綴名來自由分配。
第9位返回碼級別:可以參考log4j的日志級別,定義為如下幾種:
info、warn、error、fatal給每個級別編號即可;
第10位返回碼類型,可以根據系統處理可能的結果,定義為如下幾種:
success、biz_error、sys_error、third_error給每個類別編號即可;
第11至13位系統編號:為所有系統分配一個系統編號,以唯一標識這個系統,根據這個標識可以通過一個錯誤碼直接定位到具體的應用系統。
第14至17位錯誤編碼:業務系統內部自行定義其錯誤碼;
可以理解的是,以上只是示例,每個范圍均可以自由定義。不同層具有相同的固定格式,推行到soa的每一個系統中。
s12:將本層系統的錯誤碼添加到返回結果中,其中,當下層出現服務 調用異常時,所述返回結果中包含下層系統的錯誤碼。
其中,返回結果中可以包括:業務是否處理成功,以及,在處理失敗時還包括錯誤上下文,不同層的錯誤碼記錄在錯誤上下文中。
在將不同層的錯誤碼記錄在錯誤上下文中時,可以采用錯誤碼堆棧方式進行記錄。
例如,系統d在生成系統d的錯誤碼后,如果系統d已經接收到系統e反饋的錯誤上下文,且該錯誤上下文中已經記錄系統e的錯誤碼,則系統d可以在錯誤上下文中添加系統d的錯誤碼,使得錯誤上下文中記錄系統d的錯誤碼和系統e的錯誤碼。而相關技術中,每層系統的返回結果中僅包含本層的錯誤碼,例如,系統e反饋給系統d的錯誤碼是系統e的錯誤碼,系統d反饋給系統c的錯誤碼是系統d的錯誤碼等。
另外,如果一個系統生成本層系統的錯誤碼時,沒有接收到其他系統反饋的錯誤上下文,則該系統可以新建錯誤上下文并將本層系統的錯誤碼記錄在新建的錯誤上下文中。例如,系統e在發生服務調用異常時,可以生成系統e的錯誤碼,并新建錯誤上下文,將系統e的錯誤碼記錄在錯誤上下文中并反饋給系統d。
s13:如果需要向上層系統反饋結果,將所述返回結果發送給上層系統。
例如,參見圖2,系統e將系統e的錯誤碼包含在返回結果中發送給系統d,系統d將系統d的錯誤碼和系統e的錯誤碼包含在返回結果中發送給系統c等,從而可以實現一個系統向上層系統反饋的返回結果中不僅包括本層系統的錯誤碼,還包括下層系統的錯誤碼。
另一方面,參見圖3,該方法還可以包括:
s14:如果需要定位問題,則將接收的返回結果中包含的錯誤碼對應的最 底層系統確定為出現問題的系統。
例如,合作伙伴或系統a的責任人需要定位問題時,由于返回結果中錯誤碼對應的最底層系統是系統e,則將系統e確定為出現問題的系統。
本實施例中,通過在返回結果中包含出現服務調用異常的不同層的系統的錯誤碼,可以實現錯誤碼逐層上傳,從而在需要定位問題時,可以根據返回結果直接定位到出現問題的系統,從而提高定位問題的速度。
圖4是本申請另一方面實施例提出的服務調用異常時的處理裝置的結構示意圖,該裝置40包括:生成模塊41、添加模塊42和反饋模塊43。
生成模塊41,用于在出現服務調用異常時,生成本層系統的錯誤碼;
不同層的系統生成的錯誤碼具有相同的固定格式,具體的固定格式不限定。例如,每層的錯誤碼中包含系統標識,系統標識例如系統編號。
具體的錯誤碼的格式可以如表1所示。
添加模塊42,用于將本層系統的錯誤碼添加到返回結果中,其中,當下層系統出現服務調用異常時,所述返回結果中包含下層系統的錯誤碼。
一些實施例中,所述返回結果中包括錯誤上下文,所述添加模塊具體用于:
以錯誤碼堆棧方式,將本層系統的錯誤碼添加到錯誤上下文中。
其中,返回結果中可以包括:業務是否處理成功,以及,在處理失敗時還包括錯誤上下文,不同層的錯誤碼記錄在錯誤上下文中。
在將不同層的錯誤碼記錄在錯誤上下文中時,可以采用錯誤碼堆棧方式進行記錄。
其中,返回結果中可以包括:業務是否處理成功,以及,在處理失敗時還包括錯誤上下文,不同層的錯誤碼記錄在錯誤上下文中。
在將不同層的錯誤碼記錄在錯誤上下文中時,可以采用錯誤碼堆棧方 式進行記錄。
一些實施例中,添加模塊具體用于:
如果未接收到其他系統反饋的錯誤上下文,則新建錯誤上下文,并在新建的錯誤上下文中添加本層系統的錯誤碼。
例如,如果一個系統生成本層系統的錯誤碼時,沒有接收到其他系統反饋的錯誤上下文,則該系統可以新建錯誤上下文并將本層系統的錯誤碼記錄在新建的錯誤上下文中。例如,系統e在發生服務調用異常時,可以生成系統e的錯誤碼,并新建錯誤上下文,將系統e的錯誤碼記錄在錯誤上下文中并反饋給系統d。
反饋模塊43,用于在需要向上層系統反饋結果時,將所述返回結果發送給上層系統。
例如,參見圖2,系統e將系統e的錯誤碼包含在返回結果中發送給系統d,系統d將系統d的錯誤碼和系統e的錯誤碼包含在返回結果中發送給系統c等,從而可以實現一個系統向上層系統反饋的返回結果中不僅包括本層系統的錯誤碼,還包括下層系統的錯誤碼。
一些實施例中,參見圖5,該裝置40還包括:
定位模塊44,用于在需要定位問題時,將所述返回結果中包含的錯誤碼對應的最底層系統確定為出現問題的系統。
例如,合作伙伴或系統a的責任人需要定位問題時,由于返回結果中錯誤碼對應的最底層系統是系統e,則將系統e確定為出現問題的系統。
本實施例中,通過在返回結果中包含出現服務調用異常的不同層的系統的錯誤碼,可以實現錯誤碼逐層上傳,從而在需要定位問題時,可以根據返回結果直接定位到出現問題的系統,從而提高定位問題的速度。
需要說明的是,在本申請的描述中,術語“第一”、“第二”等僅用于描述目的,而不能理解為指示或暗示相對重要性。此外,在本申請的描述中,除非另有說明,“多個”的含義是指至少兩個。
流程圖中或在此以其他方式描述的任何過程或方法描述可以被理解為,表示包括一個或更多個用于實現特定邏輯功能或過程的步驟的可執行指令的代碼的模塊、片段或部分,并且本申請的優選實施方式的范圍包括另外的實現,其中可以不按所示出或討論的順序,包括根據所涉及的功能按基本同時的方式或按相反的順序,來執行功能,這應被本申請的實施例所屬技術領域的技術人員所理解。
應當理解,本申請的各部分可以用硬件、軟件、固件或它們的組合來實現。在上述實施方式中,多個步驟或方法可以用存儲在存儲器中且由合適的指令執行系統執行的軟件或固件來實現。例如,如果用硬件來實現,和在另一實施方式中一樣,可用本領域公知的下列技術中的任一項或他們的組合來實現:具有用于對數據信號實現邏輯功能的邏輯門電路的離散邏輯電路,具有合適的組合邏輯門電路的專用集成電路,可編程門陣列(pga),現場可編程門陣列(fpga)等。
本技術領域的普通技術人員可以理解實現上述實施例方法攜帶的全部或部分步驟是可以通過程序來指令相關的硬件完成,所述的程序可以存儲于一種計算機可讀存儲介質中,該程序在執行時,包括方法實施例的步驟之一或其組合。
此外,在本申請各個實施例中的各功能單元可以集成在一個處理模塊中,也可以是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個模塊中。上述集成的模塊既可以采用硬件的形式實現,也可以采用軟件功能模塊的 形式實現。所述集成的模塊如果以軟件功能模塊的形式實現并作為獨立的產品銷售或使用時,也可以存儲在一個計算機可讀取存儲介質中。
上述提到的存儲介質可以是只讀存儲器,磁盤或光盤等。
在本說明書的描述中,參考術語“一個實施例”、“一些實施例”、“示例”、“具體示例”、或“一些示例”等的描述意指結合該實施例或示例描述的具體特征、結構、材料或者特點包含于本申請的至少一個實施例或示例中。在本說明書中,對上述術語的示意性表述不一定指的是相同的實施例或示例。而且,描述的具體特征、結構、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結合。
盡管上面已經示出和描述了本申請的實施例,可以理解的是,上述實施例是示例性的,不能理解為對本申請的限制,本領域的普通技術人員在本申請的范圍內可以對上述實施例進行變化、修改、替換和變型。