微服務架構之「 調用鏈監控 」

「 調用鏈監控 」是在微服務興起後纔有的一種新流行的監控模式。由於在咱們傳統單體應用的項目中，不存在服務鏈/調用鏈的概念，因此也就根本沒有調用鏈監控的需求了。

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

所以你們就想到了一個辦法，將這個請求通過的每個節點都記錄下來，造成一個完整的調用鏈監控系統，那麼一旦發生請求調用異常的狀況，只須要去排查這個調用鏈日誌就能很清楚看到出錯的環節在哪兒。

1、爲何須要「 調用鏈監控 」？

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

好了，說了這麼多，我們下面就來具體看一下「調用鏈監控」的做用有哪些：

1. 項目網絡拓撲圖：

   咱們能夠根據「調用鏈監控」中記錄的鏈路信息，給項目生成一張網絡調用的拓撲圖。經過這張圖，咱們就能夠知道系統中的各個服務之間的調用關係是怎樣的，以及系統依賴了哪些服務。而且還能夠起到監控全局服務的做用，便於架構師掌握系統的狀態。

2. 快速定位問題：

   這個做用前面一直在講，微服務架構下，問題定位就變得很是複雜了，一個請求可能會通過多個服務節點，那麼有這麼一套調用鏈監控系統就能讓開發人員快速的定位到問題和相應模塊。

3. 優化系統：

   優化系統也是「調用鏈監控」很重要的一個功能。由於咱們記錄了請求在調用鏈上每個環節的信息，咱們就能夠經過這個來找出系統的瓶頸，作出針對性的優化。還能夠分析這個調用路徑是否合理，是否調用了沒必要要的服務節點，是否有更近、響應更快的服務節點。經過對調用鏈路的分析，咱們就能夠找出最優質的調用路徑，從而提升系統的性能。

4. 提升團隊成員自律：

   上面都是系統層面的做用。但若是有了「調用鏈監控」以後，對團隊開發人員的幫助也是很是大的。由於團隊全部成員均可以經過這個調用鏈監控系統看到系統各個模塊的狀態，至關於給了開發同窗一個放大鏡，之前開發同窗完成項目交付後，只要沒有出現問題，可能不太關心繫統的優化，可是有這個調用鏈監控系統以後，哪一個模塊性能高，哪一個模塊問題大，一眼就能分辨，經過這麼一個看板，開發同窗慢慢的也會對本身負責的模塊有更多的責任感，也會很自覺的去優化本身的模塊。這種習慣的養成，對研發團隊而言，很是的重要。

2、「 調用鏈監控」的原理？

在調用鏈監控系統中，有幾個核心概念須要瞭解：

• 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模塊就是數據統計展現層了。

3、「 調用鏈監控」的應用？

瞭解了調用鏈監控的原理以後，咱們再看看目前業內有哪些主流的開源調用鏈監控系統：

• 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技術 等。