[發(fā)明專利]技術(shù)中臺中基于微服務(wù)架構(gòu)實現(xiàn)業(yè)務(wù)鏈路分析的方法、系統(tǒng)、裝置及存儲介質(zhì)

有效

• 申請?zhí)枺?/td>: 202011244058.2
• 申請日: 2020-11-10
• 公開（公告）號: CN112422335B
• 公開（公告）日: 2023-02-21
• 發(fā)明（設(shè)計）人: 黃榮;焦烈焱;喻吉林
• 申請（專利權(quán)）人: 普元信息技術(shù)股份有限公司
• 主分類號: H04L41/0631
• 分類號: H04L41/0631;H04L41/14;H04L43/0852;H04L43/0876
• 代理公司: 上海智信專利代理有限公司 31002
• 代理人: 王潔;鄭暄

本發(fā)明涉及一種技術(shù)中臺中基于微服務(wù)架構(gòu)實現(xiàn)業(yè)務(wù)鏈路分析的系統(tǒng)，包括根據(jù)業(yè)務(wù)鏈路數(shù)據(jù)元模型構(gòu)建業(yè)務(wù)流程模型、微服務(wù)部署模型和業(yè)務(wù)指標模型，并形成體現(xiàn)業(yè)務(wù)概念的業(yè)務(wù)鏈路數(shù)據(jù)模型來記錄全鏈路信息；在微服務(wù)架構(gòu)下通過全鏈路追蹤日志在日志文件中采集全鏈路信息；進行業(yè)務(wù)鏈路分析，自動識別業(yè)務(wù)流程，并按照業(yè)務(wù)維度給出分析結(jié)果。本發(fā)明還涉及一種技術(shù)中臺中基于微服務(wù)架構(gòu)實現(xiàn)業(yè)務(wù)鏈路分析的方法。采用了本發(fā)明的技術(shù)中臺中基于微服務(wù)架構(gòu)實現(xiàn)業(yè)務(wù)鏈路分析的方法、系統(tǒng)、裝置及其計算機可讀存儲介質(zhì)，建立了業(yè)務(wù)鏈路數(shù)據(jù)模型，通過業(yè)務(wù)流程與服務(wù)調(diào)用鏈相匹配，將服務(wù)調(diào)用鏈路與業(yè)務(wù)概念關(guān)聯(lián)，從業(yè)務(wù)維度對服務(wù)調(diào)用鏈進行分析，實現(xiàn)了微服務(wù)架構(gòu)下業(yè)務(wù)鏈路的分析，以圖形化的方式展現(xiàn)業(yè)務(wù)狀況信息。

技術(shù)領(lǐng)域

本發(fā)明涉及微服務(wù)架構(gòu)領(lǐng)域，尤其涉及全鏈路追蹤領(lǐng)域，具體是指一種技術(shù)中臺中基于微服務(wù)架構(gòu)實現(xiàn)業(yè)務(wù)鏈路分析的方法、系統(tǒng)、裝置及其計算機可讀存儲介質(zhì)。

背景技術(shù)

微服務(wù)架構(gòu)是軟件架構(gòu)演進發(fā)展出來的一種架構(gòu)風格，它把大型的單體應用程序分解為一個個單獨打包、獨立部署的小應用，即微服務(wù)架構(gòu)的功能模塊是分布式部署運行的，并以輕量級機制(通常是HTTP資源的API)進行通信。從前臺到后臺的完整業(yè)務(wù)流會經(jīng)過很多個微服務(wù)的處理和傳遞，因此，業(yè)務(wù)鏈路的分析需要跟蹤各個微服務(wù)之間的調(diào)用關(guān)系和業(yè)務(wù)處理順序，通過全鏈路追蹤日志形成一條完整的調(diào)用鏈，記錄每個處理步驟的請求內(nèi)容及耗時等信息，從而進行用戶體驗分析、交易全路徑監(jiān)控與分析、端到端性能分析、系統(tǒng)異常分析、系統(tǒng)故障定位等。

微服務(wù)架構(gòu)中，通過全鏈路追蹤日志實現(xiàn)服務(wù)監(jiān)控與問題分析。就是必須清楚某個接口調(diào)用了哪些微服務(wù)，以及調(diào)用的順序，把這些微服務(wù)串起來，看起來就像鏈條一樣，即“調(diào)用鏈”。

調(diào)用鏈的實現(xiàn)需要為每次微服務(wù)調(diào)用做個順序標識，然后將服務(wù)調(diào)用按標識大小排列，便可以清晰地看出調(diào)用順序，該標識即為“SpanId”。

調(diào)用鏈需要知道具體某次請求調(diào)用的情況，僅有SpanId還不夠，需要在第一個接收到外部請求的微服務(wù)中生成全局唯一的追蹤標識，即“TraceId”，并在后續(xù)的微服務(wù)調(diào)用時對TraceId進行傳遞，每個被調(diào)用的微服務(wù)輸出日志時記錄該TraceId，最終對記錄的日志進行分析，這樣便能根據(jù)追蹤標識查出本次請求調(diào)用的所有服務(wù)，獲取完整的鏈路追蹤信息。

根據(jù)SpanId可以分析被調(diào)用微服務(wù)的先后順序，但無法分析調(diào)用的層級關(guān)系，多個服務(wù)可能是逐級調(diào)用，也可能是同時被同一個服務(wù)調(diào)用。所以每次調(diào)用都會記錄下是誰調(diào)用的，即記錄“ParentId”。

至此，已經(jīng)可以分析調(diào)用順序和層級關(guān)系了，但是接口出現(xiàn)問題后，還是不能找到出問題的環(huán)節(jié)，通常某個服務(wù)有問題時會導致調(diào)用執(zhí)行的耗時很長，要想計算出服務(wù)執(zhí)行的耗時，還需要時間戳，精確到微秒級，記錄發(fā)起調(diào)用時的時間戳和服務(wù)返回時的時間戳，以便計算發(fā)起調(diào)用和服務(wù)返回之間的時間差。

服務(wù)調(diào)用到服務(wù)返回的總耗時包含了服務(wù)的執(zhí)行時間和網(wǎng)絡(luò)延遲，實際應用中需要分析出這兩類時間以便做針對性優(yōu)化。我們把調(diào)用和返回的過程分為以下四個事件：

1)Client Sent，簡稱cs，客戶端發(fā)起調(diào)用請求到服務(wù)端。

2)Server Received，簡稱sr，指服務(wù)端接收到了客戶端的調(diào)用請求。

3)Server Sent，簡稱ss，指服務(wù)端完成了處理，準備將信息返給客戶端。

4)Client Received，簡稱cr，指客戶端接收到了服務(wù)端的返回信息。

在這四個事件發(fā)生時記錄下時間戳，就可以計算出各段的耗時，比如sr減去cs就是調(diào)用時的網(wǎng)絡(luò)延遲，ss減去sr就是服務(wù)執(zhí)行時間，cr減去ss就是服務(wù)響應的延遲，cr減cs就是整個服務(wù)調(diào)用執(zhí)行的時間。