ServiceComb如何實(shí)現(xiàn)zipkin分布式調(diào)用鏈追蹤

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

SeviceComb + Zipkin 簡介

ServiceComb 是Apache的微服務(wù)頂級(jí)項(xiàng)目，在微服務(wù)框架中，微服務(wù)之間通過網(wǎng)絡(luò)進(jìn)行通信，我們必須處理所有與網(wǎng)絡(luò)相關(guān)的問題，例如延遲，超時(shí)和分區(qū)。隨著部署的微服務(wù)越來越多，我們需要系統(tǒng)監(jiān)控微服務(wù)網(wǎng)絡(luò)延遲和請求流。

ServiceComb 如何支持zipkin

ServiceComb 提供了處理鏈機(jī)制，消費(fèi)端和服務(wù)端的調(diào)用鏈請求都會(huì)經(jīng)過該處理鏈，通過擴(kuò)展handler處理鏈接口，可以實(shí)現(xiàn)負(fù)載均衡、熔斷容錯(cuò)、流量控制等能力。同樣，調(diào)用鏈追蹤能力也是通過擴(kuò)展該接口實(shí)現(xiàn)的。

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

handler-tracing-zipkin模塊實(shí)現(xiàn)追蹤調(diào)用鏈記錄數(shù)據(jù)和上傳追蹤數(shù)據(jù)到zipkin服務(wù)，即可支持Zipkin。

handler-tracing-zipkin模塊源碼解讀

每一次接口調(diào)用請求都會(huì)觸發(fā)handler鏈的處理，而在這個(gè)handler鏈當(dāng)中，ServiceComb專門為Zipkin編寫了handler類ZipkinConsumerTracingHandler

和ZipkinProviderTracingHandle進(jìn)行適配。下面我們來看下這兩個(gè)類。

ZipkinConsumerTracingHandler 和ZipkinProviderTracingHandler

查看這兩個(gè)類源碼可知，都繼承自ZipkinTracingHandler
，都只有兩個(gè)構(gòu)造器。

區(qū)別在于分別向父類構(gòu)造器傳遞了不同的ZipkinTracingDelegate實(shí)現(xiàn)。

ZipkinTracingDelegate實(shí)現(xiàn)分別為ZipkinConsumerDelegate和ZipkinProviderDelegate。

這兩個(gè)代理類分別封裝了對應(yīng)的Zipkin請求消費(fèi)和請求生產(chǎn)操作。下面重點(diǎn)看下ZipkinTracingHandler的源碼實(shí)現(xiàn)。

ZipkinTracingHandler

handler類最重要的方法是handler方法，該方法接收一個(gè)Invocation對象和AsyncResponse對象（全是ServiceComb內(nèi)置對象）。Invocation對象包含當(dāng)前調(diào)用相關(guān)信息（包括HttpServletRequest對象）。下面我們看下這個(gè)方法做了什么事情。

handler方法執(zhí)行步驟：

一

調(diào)用了tracingDelegate.createSpan(invocation)方法創(chuàng)建了一個(gè)span。tracingDelegate是一個(gè)ZipkinTracingDelegate對象。

二

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

三

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

四

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

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

ZipkinTracingDelegate接口

如下圖，該接口定義了4個(gè)方法。

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

2.createSpan(), 根據(jù)Invocation對象攜帶的信息創(chuàng)建對應(yīng)的span

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

4.name() , 區(qū)分消費(fèi)操作和生產(chǎn)操作

該接口有兩個(gè)實(shí)現(xiàn)類ZipkinConsumerDelegate
和ZipkinProviderDelegate，分別對應(yīng)請求消費(fèi)操作和請求生產(chǎn)操作。

下面我們可以看到兩個(gè)實(shí)現(xiàn)的區(qū)別。

ZipkinConsumerDelegate和ZipkinProviderDelegate

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

我們會(huì)發(fā)現(xiàn)它們都是用handler變量來進(jìn)行相應(yīng)的操作，注意這里的handler變量在兩個(gè)類分別是不一樣的類型，ZipkinConsumerDelegate的handler變量是HttpClientHandler對象，而ZipkinProviderDelegate的hanler變量是HttpServerHandler對象。HttpClientHandler和HttpServerHandler類都是final修飾的類，不可繼承。前面我們看到創(chuàng)建span和發(fā)送span都是由這兩個(gè)類來負(fù)責(zé)，那么我們來看下這兩個(gè)對象怎么生成的。

仔細(xì)觀察可發(fā)現(xiàn)↓↓↓

ZipkinConsumerDelegate構(gòu)造器部分代碼：

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

ZipkinProviderDelegate構(gòu)造器部分代碼 ： 

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

從上面兩段構(gòu)造器代碼中可發(fā)現(xiàn)HttpClientHandler和HttpServerHandler在創(chuàng)建對象時(shí)都分別傳入ConsumerInvocationAdapter對象和ProviderInvocationAdapter對象，這兩個(gè)對象分別繼承了Zipkin的HttpClientAdapter和HttpServerAdapter抽象類，提供了屬于ServiceComb本身的客戶端信息和服務(wù)端信息。而Zipkin可以在不改動(dòng)代碼的情況下獲取到這些定制信息并用于調(diào)用鏈追蹤。

關(guān)于“ServiceComb如何實(shí)現(xiàn)zipkin分布式調(diào)用鏈追蹤”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。