[學習微服務-第5天] ServiceComb+Zipkin源碼解讀

SeviceComb + Zipkin 簡介

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

上篇文章咱們介紹瞭如何使用ServiceComb與Zipkin進行協同定位微服務應用的異常的微服務和具體異常函數。

 

本篇將介紹ServiceComb如何經過自身handler處理鏈機制支持Zipkin 微服務級別和函數級別的調用鏈追蹤的。

▼▼▼

ServiceComb 如何支持zipkin

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

 

關於ServiceComb處理鏈參考 ↓↓↓

https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/intruduction.html

 

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

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

 

若是讀者對於使用ServiceComb對於Zipkin支持的能力還不熟悉，可參考ServiceComb官網相關文檔↓↓↓

1.http://servicecomb.apache.org/docs/tracing-with-servicecomb/ 

2.https://servicecomb.apache.org/cn/docs/customized-tracing-with-servicecomb/ 

 

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分佈式調用鏈追蹤，已經解讀完畢。

連接參考

1.zipkin https://zipkin.io/

2.Distributed Tracing with ServiceComb and Zipkin 

http://servicecomb.apache.org/docs/tracing-with-servicecomb/

3.處理鏈參考

https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/intruduction.html

4.java-chassiss使用手冊——調用參考

https://docs.servicecomb.io/java-chassis/zh_CN/

 

文末小結

本文向社區讀者從源碼角度闡述了ServiceComb是如何支持Zipkin的。

咱們也很是歡迎愛好者們向社區提問和貢獻代碼。

下章咱們將介紹ServiceComb+SpringCloud Ribbon使用篇。

若是在閱讀代碼時有任何疑問想交流，歡迎掃碼加入進微信羣。

期待志同道合的朋友們加入

ServiceComb的大門爲大家敞開~

用心作開源，不忘初衷