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的大門爲你們敞開~
用心做開源，不忘初衷
————————————————
原文鏈接：https://blog.csdn.net/ServiceComb/article/details/87100917