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

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

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

一、為什么需要「 調用鏈監控 」？

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

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

項目網絡拓撲圖：

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

快速定位問題：

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

優化系統：

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

提高團隊成員自律：

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

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

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

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主要提供的報表有：

Transaction報表：

主要是監控一段代碼運行情況，如：運行次數、QPS、錯誤次數、失敗率、響應時間等。

Event報表：

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

Problem報表：

主要是統計項目在運行過程中出現的問題，根據Transaction與Event的數據分析出來系統可能出現的異常，比如訪問較慢等。

Heartbeat報表：

以一分鐘為周期，定期向服務端匯報當前運行的一些狀態，如：JVM狀態、Memory、Thread等。

Business報表：

業務監控報表，如訂單指標、支付數據等業務指標。

Open Zipkin

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

Naver Pinpoint

Pinpoint中的服務關系依賴圖做得非常棒，超出市面上任何一款產品。另外，Pinpoint因為采用字節碼增強方式去埋點，所以在埋點的時候是不需要修改業務代碼的，非侵入式的，非常適合項目已經完成之后再增加調用鏈監控的時候去使用的方案。但是也是由于采用字節碼增強的方式，所以它目前僅支持JAVA語言。

以上，就是對微服務架構中「 調用鏈監控」的一些思考。