ServiceComb如何實現zipkin分布式調用鏈追蹤

這篇文章主要介紹“ServiceComb如何實現zipkin分布式調用鏈追蹤”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“ServiceComb如何實現zipkin分布式調用鏈追蹤”文章能幫助大家解決問題。

SeviceComb + Zipkin 簡介

ServiceComb 是Apache的微服務頂級項目，在微服務框架中，微服務之間通過網絡進行通信，我們必須處理所有與網絡相關的問題，例如延遲，超時和分區。隨著部署的微服務越來越多，我們需要系統監控微服務網絡延遲和請求流。

ServiceComb 如何支持zipkin

ServiceComb 提供了處理鏈機制，消費端和服務端的調用鏈請求都會經過該處理鏈，通過擴展handler處理鏈接口，可以實現負載均衡、熔斷容錯、流量控制等能力。同樣，調用鏈追蹤能力也是通過擴展該接口實現的。

ServiceComb 擴展handler處理鏈接口，編寫了handler-tracing-zipkin 模塊。Handler-tracing-zipkin 模塊在java-chassis/handler處理鏈下，模塊內容如下。

handler-tracing-zipkin模塊實現追蹤調用鏈記錄數據和上傳追蹤數據到zipkin服務，即可支持Zipkin。

handler-tracing-zipkin模塊源碼解讀

每一次接口調用請求都會觸發handler鏈的處理，而在這個handler鏈當中，ServiceComb專門為Zipkin編寫了handler類ZipkinConsumerTracingHandler

和ZipkinProviderTracingHandle進行適配。下面我們來看下這兩個類。

ZipkinConsumerTracingHandler 和ZipkinProviderTracingHandler

查看這兩個類源碼可知，都繼承自ZipkinTracingHandler
，都只有兩個構造器。

區別在于分別向父類構造器傳遞了不同的ZipkinTracingDelegate實現。

ZipkinTracingDelegate實現分別為ZipkinConsumerDelegate和ZipkinProviderDelegate。

這兩個代理類分別封裝了對應的Zipkin請求消費和請求生產操作。下面重點看下ZipkinTracingHandler的源碼實現。

ZipkinTracingHandler

handler類最重要的方法是handler方法，該方法接收一個Invocation對象和AsyncResponse對象（全是ServiceComb內置對象）。Invocation對象包含當前調用相關信息（包括HttpServletRequest對象）。下面我們看下這個方法做了什么事情。

handler方法執行步驟：

一

調用了tracingDelegate.createSpan(invocation)方法創建了一個span。tracingDelegate是一個ZipkinTracingDelegate對象。

二

調用當前對象的onResponse方法封裝成一個AsyncResponse對象。該對象是是一個函數式對象，在如下圖的函數體中可看到最終調用了tracingDelegate.onResponse(span, response, error)上傳span到Zipkin服務器。

三

調用invocation.next()方法將生成的AsyncResponse對象傳遞給下一個handler處理。

四

如果在以上操作中發生異常，將調用tracingDelegate.onResponse(span, null, e)方法發送帶有異常信息的span到Zipkin服務器。

從以上分析我們可以看到tracingDelegate十分重要，下面我們接著看這個ZipkinTracingDelegate接口到底做了什么。

ZipkinTracingDelegate接口

如下圖，該接口定義了4個方法。

1.tracer() ,獲取對應的追蹤器

2.createSpan(), 根據Invocation對象攜帶的信息創建對應的span

3.onResponse()，將span對象和對應的響應信息和異常信息上傳到Zipkin服務器

4.name() , 區分消費操作和生產操作

該接口有兩個實現類ZipkinConsumerDelegate
和ZipkinProviderDelegate，分別對應請求消費操作和請求生產操作。

下面我們可以看到兩個實現的區別。

ZipkinConsumerDelegate和ZipkinProviderDelegate

下面我們先上兩張圖片仔細對比一下，第一張是ZipkinConsumerDelegate類，第二張是ZipkinProviderDelegate類。

我們會發現它們都是用handler變量來進行相應的操作，注意這里的handler變量在兩個類分別是不一樣的類型，ZipkinConsumerDelegate的handler變量是HttpClientHandler對象，而ZipkinProviderDelegate的hanler變量是HttpServerHandler對象。HttpClientHandler和HttpServerHandler類都是final修飾的類，不可繼承。前面我們看到創建span和發送span都是由這兩個類來負責，那么我們來看下這兩個對象怎么生成的。

仔細觀察可發現↓↓↓

ZipkinConsumerDelegate構造器部分代碼：

this.handler = HttpClientHandler.create(httpTracing, new ConsumerInvocationAdapter());

ZipkinProviderDelegate構造器部分代碼 ： 

this.handler = HttpServerHandler.create(httpTracing, new ProviderInvocationAdapter());

從上面兩段構造器代碼中可發現HttpClientHandler和HttpServerHandler在創建對象時都分別傳入ConsumerInvocationAdapter對象和ProviderInvocationAdapter對象，這兩個對象分別繼承了Zipkin的HttpClientAdapter和HttpServerAdapter抽象類，提供了屬于ServiceComb本身的客戶端信息和服務端信息。而Zipkin可以在不改動代碼的情況下獲取到這些定制信息并用于調用鏈追蹤。

關于“ServiceComb如何實現zipkin分布式調用鏈追蹤”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。