[發明專利]一種微服務全鏈路監控系統及方法

在審

• 申請號: 201910048998.5
• 申請日: 2019-01-18
• 公開（公告）號: CN111464373A
• 公開（公告）日: 2020-07-28
• 發明（設計）人: 王富平;翟小青;楊升;崔建梅;孫遷
• 申請（專利權）人: 蘇寧易購集團股份有限公司
• 主分類號: H04L12/26
• 分類號: H04L12/26
• 代理公司: 北京市萬慧達律師事務所 11111
• 代理人: 趙然

本發明公開了一種微服務全鏈路監控系統及方法，屬于微服務技術領域。所述微服務全鏈路監控系統，所述系統包括：采集框架模塊，用于采集服務調用數據和進行鏈路串聯；消息隊列模塊，用于實時接收來自所述采集框架模塊的服務調用數據；計算中心模塊，用于向所述消息隊列模塊訂閱服務調用數據，實時聚合存儲；監控中心模塊，用于讀取所述計算中心模塊存儲的監控數據，并提供監控功能；其中，所述消息隊列模塊和所述計算中心模塊均采用分布式部署方式。本發明提供的微服務全鏈路監控系統及方法，解決了跨線程調用服務的鏈路埋點問題，代碼無侵入，監控便利性和可用性大大提升；解決了跨線程的鏈路傳遞難題，適合大規模場景。

技術領域

本發明涉及微服務技術領域，特別涉及一種微服務全鏈路監控系統及方法。

背景技術

目前微服務設計模式在國內已經普及開來，微服務設計模式鼓勵服務拆分，方便了代碼解耦，但同時也帶來了新的問題，使得服務間依賴增加，一個服務往往依賴多個底層服務，調用鏈路較深，超過三層的服務嵌套調用越來越常見，因此許多問題亟待解決：問題定位困難、性能瓶頸難以發現。

市面上也有不少全鏈路監控系統，有些網上平臺的CAT、Spring cloud自帶的zipkin，都存在以下幾個問題：1、代碼侵入性太強，需要顯示進行代碼編寫，進行監控埋點；2、實時性差、計算存在瓶頸，不適合大規模微服務系統監控場景，無論是Cat還是ZipKin都存在一個中心節點，進行計算存儲(cat存儲到mysql，zipkin一般是ES)，架構上存的性能瓶頸，可擴展性差；3、鏈路容易斷開，跨線程調用會造成鏈路斷開。

發明內容

為了解決現有技術的問題，本發明實施例提供了一種微服務全鏈路監控系統及方法，解決了跨線程調用服務的鏈路埋點問題，代碼無侵入，監控便利性和可用性大大提升；解決了跨線程的鏈路傳遞難題，無需通過硬編碼進行跨線程鏈路傳遞；提供了分布式擴展能力，適合大規模場景。所述技術方案如下：

第一方面，提供了一種微服務全鏈路監控系統，所述系統包括：

采集框架模塊，用于采集服務調用數據和進行鏈路串聯；

消息隊列模塊，用于實時接收來自所述采集框架模塊的服務調用數據；

計算中心模塊，用于向所述消息隊列模塊訂閱服務調用數據，實時聚合存儲；

監控中心模塊，用于讀取所述計算中心模塊存儲的監控數據，并提供監控功能；

其中，所述消息隊列模塊和所述計算中心模塊均采用分布式部署方式。

結合第一方面，在第一種可能的實現方式中，所述采集框架模塊用于采集包括鏈路ID、節點ID、服務名稱、請求參數、服務器IP、響應時間在內的服務調用數據。

結合第一方面，在第二種可能的實現方式中，所述采集框架模塊用于根據調用方傳遞過來的鏈路ID、節點ID為當前服務設置鏈路ID、節點ID或生成新的鏈路ID、節點ID。

結合第一方面的第一種或第二種可能實現方式的任意一種，在第三至四種可能的實現方式中，所述鏈路ID為TraceID，所述節點ID為SpanID。

結合第一方面，在第五種可能的實現方式中，所述消息隊列模塊采用Kafka架構，和/或，所述計算中心模塊采用Druid架構。

結合第一方面，在第六種可能的實現方式中，所述監控中心模塊用于讀取所述計算中心模塊存儲的監控數據，并提供包括調用鏈路展示、搜索、監控、告警在內的監控功能。

第二方面，提供了一種結合第一方面所述的微服務全鏈路監控系統的微服務全鏈路監控方法，所述方法包括數據采集步驟，所述數據采集步驟具體包括以下子步驟：

請求第一服務；