1. 程式人生 > >微服務架構之「 呼叫鏈監控 」

微服務架構之「 呼叫鏈監控 」

「 呼叫鏈監控 」是在微服務興起後才有的一種新流行的監控模式。因為在我們傳統單體應用的專案中,不存在服務鏈/呼叫鏈的概念,所以也就根本沒有呼叫鏈監控的需求了。

當我們開始微服務架構之後,我們的很多服務變成分散式的了,並且我們對服務進行了拆分,拆分之後,使用者的一個請求進來,會依次經過不同的服務節點進行處理,處理完成後再返回結果給使用者。那麼在整個處理的鏈條中,如果有任何一個節點出現了延遲或者問題,都有可能導致最終的結果出現異常,有的時候不同的服務節點甚至是由不同的團隊開發的、部署在不同的伺服器上,那麼在這麼錯綜複雜的環境下,我們想要排查出是鏈條中的具體哪個服務節點出了問題,其實並不容易。

因此大家就想到了一個辦法,將這個請求經過的每一個節點都記錄下來,形成一個完整的呼叫鏈監控系統,那麼一旦發生請求呼叫異常的情況,只需要去排查這個呼叫鏈日誌就能很清楚看到出錯的環節在哪兒。

一、為什麼需要「 呼叫鏈監控 」?

「呼叫鏈監控」是在微服務架構中非常重要的一環。它除了能幫助我們定位問題以外,還能幫助專案成員清晰的去了解專案部署結構,畢竟一個幾十上百的微服務,相信在執行時間久了之後,專案的結構很可能就是下面圖片這樣了,在這種情況下,團隊開發者甚至是架構師都不一定能對專案的網路結構有很清晰的瞭解,那就更別談系統優化了。

好了,說了這麼多,咱們下面就來具體看一下「呼叫鏈監控」的作用有哪些:

  1. 專案網路拓撲圖:

    我們可以根據「呼叫鏈監控」中記錄的鏈路資訊,給專案生成一張網路呼叫的拓撲圖。通過這張圖,我們就可以知道系統中的各個服務之間的呼叫關係是怎樣的,以及系統依賴了哪些服務。並且還可以起到監控全域性服務的作用,便於架構師掌握系統的狀態。

  2. 快速定位問題:

    這個作用前面一直在講,微服務架構下,問題定位就變得非常複雜了,一個請求可能會經過多個服務節點,那麼有這麼一套呼叫鏈監控系統就能讓開發人員快速的定位到問題和相應模組。

  3. 優化系統:

    優化系統也是「呼叫鏈監控」很重要的一個功能。因為我們記錄了請求在呼叫鏈上每一個環節的資訊,我們就可以通過這個來找出系統的瓶頸,做出針對性的優化。還可以分析這個呼叫路徑是否合理,是否呼叫了不必要的服務節點,是否有更近、響應更快的服務節點。通過對呼叫鏈路的分析,我們就可以找出最優質的呼叫路徑,從而提高系統的效能。

  4. 提高團隊成員自律:

    上面都是系統層面的作用。但如果有了「呼叫鏈監控」之後,對團隊開發人員的幫助也是非常大的。因為團隊所有成員都可以通過這個呼叫鏈監控系統看到系統各個模組的狀態,相當於給了開發同學一個放大鏡,以前開發同學完成專案交付後,只要沒有出現問題,可能不太關心繫統的優化,但是有這個呼叫鏈監控系統之後,哪個模組效能高,哪個模組問題大,一眼就能分辨,通過這麼一個看板,開發同學慢慢的也會對自己負責的模組有更多的責任感,也會很自覺的去優化自己的模組。這種習慣的養成,對研發團隊而言,非常的重要。

二、「 呼叫鏈監控」的原理?

在呼叫鏈監控系統中,有幾個核心概念需要了解:

  • Trace:

    Trace是指一次請求呼叫的鏈路過程,trace id 是指這次請求呼叫的ID。在一次請求中,會在網路的最開始生成一個全域性唯一的用於標識此次請求的trace id,這個trace id在這次請求呼叫過程中無論經過多少個節點都會保持不變,並且在隨著每一層的呼叫不停的傳遞。最終,可以通過trace id將這一次使用者請求在系統中的路徑全部串起來。

  • Span:

    Span是指一個模組的呼叫過程,一般用span id來標識。在一次請求的過程中會呼叫不同的節點/模組/服務,每一次呼叫都會生成一個新的span id來記錄。這樣,就可以通過span id來定位當前請求在整個系統呼叫鏈中所處的位置,以及它的上下游節點分別是什麼。

  • Annotation:

    是指附屬資訊,可以用於附屬在每一個Span上自定義的資料。

具體參考下圖:

從圖中可見,一次請求只有一個唯一的trace id=12345,在請求過程中的任何環節都不會改變。在這個請求的呼叫鏈中,SpanA呼叫了SpanB,然後SpanB又呼叫了SpanC和SpanD,每一次Span呼叫都會生成一個自己的span id,並且還會記錄自己的上級span id是誰。通過這些id,整個鏈路基本上就都能標識出來了。

好了,瞭解了核心概念之後,我們再來看一下它具體是如何工作的,下面選取Twitter開源的Zipkin原理圖作為參考:

所有的呼叫鏈監控系統都由 資料埋點採集、資料儲存處理、資料分析展示 幾大部分組成,Zipkin也不例外。

圖中左上角Reporter部分整合到應用程式中採集資料,並將資料上報,由Collector進行收集,然後通過Storage模組負責儲存,落地到儲存系統中(Zipkin用的是Cassandra)。而API模組是可以將處理後的資料提供對外服務的,UI模組就是資料統計展示層了。

三、「 呼叫鏈監控」的應用?

瞭解了呼叫鏈監控的原理之後,我們再看看目前業內有哪些主流的開源呼叫鏈監控系統:

  • CAT

    CAT是由大眾點評開源的一款呼叫鏈監控系統,基於JAVA開發的。有很多網際網路企業在使用,熱度非常高。它有一個非常強大和豐富的視覺化報表介面,這一點其實對於一款呼叫鏈監控系統而來非常的重要。在CAT提供的報表介面中有非常多的功能,幾乎能看到你想要的任何維度的報表資料。

    CAT有個很大的優勢就是處理的實時性,CAT裡大部分系統是分鐘級統計。

    CAT主要提供的報表有:

  1. Transaction報表:

    主要是監控一段程式碼執行情況,如:執行次數、QPS、錯誤次數、失敗率、響應時間等。

  2. Event報表:

    主要是監控一行程式碼/一個事件執行次數,如:程式中某個事件運行了多少次、錯誤了多少次等。Event報表的整體結構與Transaction報表幾乎一樣,只缺少響應時間的統計。

  3. Problem報表:

    主要是統計專案在執行過程中出現的問題,根據Transaction與Event的資料分析出來系統可能出現的異常,比如訪問較慢等。

  4. Heartbeat報表:

    以一分鐘為週期,定期向服務端彙報當前執行的一些狀態,如:JVM狀態、Memory、Thread等。

  5. Business報表:

    業務監控報表,如訂單指標、支付資料等業務指標。

  • Open Zipkin

    Zipkin由Twitter開源,支援的語言非常多,基於 Google Dapper 的論文設計而來,國內外很多公司都在用,文件資料也很豐富。在上面講原理的環節已經介紹過了Zipkin,這裡就不贅述了,下面是示例圖:

  • Naver Pinpoint

    Pinpoint中的服務關係依賴圖做得非常棒,超出市面上任何一款產品。另外,Pinpoint因為採用位元組碼增強方式去埋點,所以在埋點的時候是不需要修改業務程式碼的,非侵入式的,非常適合專案已經完成之後再增加呼叫鏈監控的時候去使用的方案。但是也是由於採用位元組碼增強的方式,所以它目前僅支援JAVA語言。

以上,就是對微服務架構中「 呼叫鏈監控」的一些思考。

在微服務架構的系列文章中,前面已經通過文章介紹過了「服務註冊 」、「服務閘道器 」、「配置中心 」、「 監控系統 」,大家可以翻閱歷史文章檢視。

另外,為了方便小夥伴們交流微服務架構相關的技術,我建立了一個「 聊聊架構與微服務 」的交流群。

新增微信後拉你進群:WH-IT-er,加微信時備註:微服務加群

 

本文原創釋出於微信公眾號「 不止思考 」,歡迎關注。涉及 思維認知、個人成長、架構、大資料、Web技術 等。