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

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

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

一、為什么需要「 調(diào)用鏈監(jiān)控 」？

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

好了，說了這么多，咱們下面就來具體看一下「調(diào)用鏈監(jiān)控」的作用有哪些：

項目網(wǎng)絡拓撲圖：

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

快速定位問題：

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

優(yōu)化系統(tǒng)：

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

提高團隊成員自律：

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

二、「 調(diào)用鏈監(jiān)控」的原理？

在調(diào)用鏈監(jiān)控系統(tǒng)中，有幾個核心概念需要了解：

Trace:

Trace是指一次請求調(diào)用的鏈路過程，trace id 是指這次請求調(diào)用的ID。在一次請求中，會在網(wǎng)絡的最開始生成一個全局唯一的用于標識此次請求的trace id，這個trace id在這次請求調(diào)用過程中無論經(jīng)過多少個節(jié)點都會保持不變，并且在隨著每一層的調(diào)用不停的傳遞。最終，可以通過trace id將這一次用戶請求在系統(tǒng)中的路徑全部串起來。

Span:

Span是指一個模塊的調(diào)用過程，一般用span id來標識。在一次請求的過程中會調(diào)用不同的節(jié)點/模塊/服務，每一次調(diào)用都會生成一個新的span id來記錄。這樣，就可以通過span id來定位當前請求在整個系統(tǒng)調(diào)用鏈中所處的位置，以及它的上下游節(jié)點分別是什么。

Annotation:

是指附屬信息，可以用于附屬在每一個Span上自定義的數(shù)據(jù)。

具體參考下圖：

從圖中可見，一次請求只有一個唯一的trace id=12345，在請求過程中的任何環(huán)節(jié)都不會改變。在這個請求的調(diào)用鏈中，SpanA調(diào)用了SpanB，然后SpanB又調(diào)用了SpanC和SpanD，每一次Span調(diào)用都會生成一個自己的span id，并且還會記錄自己的上級span id是誰。通過這些id，整個鏈路基本上就都能標識出來了。

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

所有的調(diào)用鏈監(jiān)控系統(tǒng)都由 數(shù)據(jù)埋點采集、數(shù)據(jù)存儲處理、數(shù)據(jù)分析展示 幾大部分組成，Zipkin也不例外。

圖中左上角Reporter部分集成到應用程序中采集數(shù)據(jù)，并將數(shù)據(jù)上報，由Collector進行收集，然后通過Storage模塊負責存儲，落地到存儲系統(tǒng)中（Zipkin用的是Cassandra）。而API模塊是可以將處理后的數(shù)據(jù)提供對外服務的，UI模塊就是數(shù)據(jù)統(tǒng)計展示層了。

三、「 調(diào)用鏈監(jiān)控」的應用？

了解了調(diào)用鏈監(jiān)控的原理之后，我們再看看目前業(yè)內(nèi)有哪些主流的開源調(diào)用鏈監(jiān)控系統(tǒng)：

CAT

CAT是由大眾點評開源的一款調(diào)用鏈監(jiān)控系統(tǒng)，基于JAVA開發(fā)的。有很多互聯(lián)網(wǎng)企業(yè)在使用，熱度非常高。它有一個非常強大和豐富的可視化報表界面，這一點其實對于一款調(diào)用鏈監(jiān)控系統(tǒng)而來非常的重要。在CAT提供的報表界面中有非常多的功能，幾乎能看到你想要的任何維度的報表數(shù)據(jù)。

CAT有個很大的優(yōu)勢就是處理的實時性，CAT里大部分系統(tǒng)是分鐘級統(tǒng)計。

CAT主要提供的報表有：

Transaction報表：

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

Event報表：

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

Problem報表：

主要是統(tǒng)計項目在運行過程中出現(xiàn)的問題，根據(jù)Transaction與Event的數(shù)據(jù)分析出來系統(tǒng)可能出現(xiàn)的異常，比如訪問較慢等。

Heartbeat報表：

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

Business報表：

業(yè)務監(jiān)控報表，如訂單指標、支付數(shù)據(jù)等業(yè)務指標。

Open Zipkin

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

Naver Pinpoint

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

以上，就是對微服務架構中「 調(diào)用鏈監(jiān)控」的一些思考。