自己動(dòng)手?jǐn)U展微服務(wù)分布式調(diào)用鏈

1、 跟著小程學(xué)微服務(wù)自己動(dòng)手?jǐn)U展微服務(wù)分布式調(diào)用鏈 一、說在前面微服務(wù)是當(dāng)下最火的詞語，現(xiàn)在很多公司都在推廣微服務(wù)，當(dāng)服務(wù)越來越多的時(shí)候，我們是否會(huì)糾結(jié)以下幾個(gè)問題：面對(duì)一筆超時(shí)的訂單，究竟是哪一步處理時(shí)間超長(zhǎng)呢？數(shù)據(jù)由于并發(fā)莫名篡改，到底都誰有重大嫌疑呢？處理遺漏了一筆訂單，曾經(jīng)是哪個(gè)環(huán)節(jié)出錯(cuò)把它落下了？系統(tǒng)莫名的報(bào)錯(cuò)，究竟是哪一個(gè)服務(wù)報(bào)的錯(cuò)誤？每個(gè)服務(wù)那么多實(shí)例服務(wù)器，如何快速定位到是哪一個(gè)實(shí)例服務(wù)器報(bào)錯(cuò)的呢？現(xiàn)在很多系統(tǒng)都要求可用性達(dá)到99.9%以上，那么我們除了增加系統(tǒng)健壯性減少故障的同時(shí)，我們又如何在真正發(fā)生故障的時(shí)候，快速定位和解決問題，也將是我們的重中之重。在做微服務(wù)框架選擇的時(shí)候

2、，Spring Cloud無疑是當(dāng)下最火的，但是因?yàn)镾pring Cloud是近二年的后起新秀，以及在使用方式上面的差別，目前在很多中小企業(yè)還是以dubbo為主，不過遺憾的是，dubbo從官方來講已經(jīng)不維護(hù)了，很多公司都是自己再去維護(hù)，那么今天我就來給大家介紹一下，我們是如何通過修改dubbo源碼實(shí)現(xiàn)了分布式調(diào)用鏈的第一階段：調(diào)用鏈日志的打印。二、什么是分布式調(diào)用鏈1、什么是調(diào)用鏈基于Google Dapper論文，用戶每次請(qǐng)求都會(huì)生成一個(gè)全局ID（traceId），通過它將不同系統(tǒng)的“孤立”的日志串在一起，重組成調(diào)用鏈。2、調(diào)用鏈的調(diào)用過程當(dāng)用戶發(fā)起一個(gè)請(qǐng)求時(shí)，首先到達(dá)前端A服務(wù)，然后分別對(duì)

3、B服務(wù)和C服務(wù)進(jìn)行RPC調(diào)用。B服務(wù)處理完給A做出響應(yīng)，但是C服務(wù)還需要和后端的D服務(wù)和E服務(wù)交互之后再返還給A服務(wù)，最后由A服務(wù)來響應(yīng)用戶的請(qǐng)求。Paste_Image.png3、對(duì)整個(gè)調(diào)用過程的追蹤請(qǐng)求到來生成一個(gè)全局TraceID，通過TraceID可以串聯(lián)起整個(gè)調(diào)用鏈，一個(gè)TraceID代表一次請(qǐng)求。除了TraceID外，還需要SpanID用于記錄調(diào)用父子關(guān)系。每個(gè)服務(wù)會(huì)記錄下Parent id和Span id，通過他們可以組織一次完整調(diào)用鏈的父子關(guān)系。一個(gè)沒有Parent id的span成為root span，可以看成調(diào)用鏈入口。所有這些ID可用全局唯一的64位整數(shù)表示；整個(gè)調(diào)用過程

4、中每個(gè)請(qǐng)求都要透?jìng)鱐raceID和SpanID。每個(gè)服務(wù)將該次請(qǐng)求附帶的TraceID和附帶的SpanID作為Parent id記錄下，并且將自己生成的SpanID也記錄下。要查看某次完整的調(diào)用則只要根據(jù)TraceID查出所有調(diào)用記錄，然后通過Parent id和Span id組織起整個(gè)調(diào)用父子關(guān)系。最終的TraceId和SpanId的調(diào)用關(guān)系圖如下所示：Paste_Image.png三、基于Dubbo的實(shí)現(xiàn)1、Dubbo的調(diào)用過程在我們分析源碼的時(shí)候，有一行代碼是：這行代碼實(shí)際上是利用SPI機(jī)制，動(dòng)態(tài)加載指定的Protocol注入到ProtocolFilterWrapper中，再通過Wrap

5、per訪問到可執(zhí)行的Invoker對(duì)象，Dubbo默認(rèn)使用的是DubboProtocol最終通過netty的方式進(jìn)行通信，具體調(diào)用過程請(qǐng)看下圖：Paste_Image.png可以看到基本的流程是：InvokerInvocationHandler -ClusterInvoker -LoadBalance - ProtocolFilterWrapper - Protocol - DubboInvoker而在調(diào)用鏈的實(shí)現(xiàn)過程中技術(shù)難點(diǎn)主要是有二個(gè)：在哪里暫存調(diào)用鏈調(diào)用鏈信息如何傳遞2、Dubbo協(xié)議下的調(diào)用鏈傳遞過程那么在默認(rèn)的Dubbo協(xié)議下，實(shí)現(xiàn)調(diào)用鏈的過程很簡(jiǎn)單只需要在應(yīng)用項(xiàng)目或者Dubbo源

6、碼中使用如下代碼就可以實(shí)現(xiàn)調(diào)用鏈的傳遞。在DubboInvoker中最終通信的時(shí)候會(huì)將上述代碼的RpcInvocation對(duì)象傳遞出去，那么我們只需要在接收端獲取既可。3、Hessian協(xié)議下的調(diào)用鏈傳遞過程大家都知道，Dubbo在實(shí)現(xiàn)通信的協(xié)議上使用的有Netty、Hessian、Rest等方式，由于我們項(xiàng)目的特殊性，目前采用的是Dubbo的Hessian協(xié)議。先看HessianProtocol的如下代碼：通過代碼可以看到，實(shí)際上在使用Hessian通信的時(shí)候并沒有將RpcInvocation里面設(shè)定的TraceId和SpanId傳遞出去，調(diào)用在這一塊中止了。那我們?nèi)绾巫约簛韺?shí)現(xiàn)呢?第一步、

7、我們?cè)贒ubbo源碼中自己實(shí)現(xiàn)了一個(gè)Filter（不是Dubbo的Filter），用來產(chǎn)生TraceId和SpanId，以及最后的清理工作，請(qǐng)看代碼如下：在Filter中產(chǎn)生TraceId和SpanId以后，會(huì)將二個(gè)值放到我們封裝好的CallChainContext中進(jìn)行暫存。第二步、我們將HessianProxyFactory進(jìn)行繼承改造我們將CallChainContext中暫存的TraceId和SpanId放入到Hessian的header中。繼承Dubbo的HessianProxyFactory這個(gè)類，新類名是HessianProxyFactoryWrapper，在create方法中將

8、HessianProxy替換為新封裝的HessianProxyWrapper，代碼如下：修改后的HessianProtocol的代碼如下：通過以上方式可以將我們產(chǎn)生的TraceId和SpanId通過Hessian的方式傳遞出去，我們?cè)诮邮照?qǐng)求的時(shí)候，只需要使用如下代碼的方式就可以獲取到二個(gè)值。第三步、如何打印調(diào)用鏈信息我們?cè)陧?xiàng)目中使用的是Logback的方式打印日志，首先想到的是繼承一個(gè)ClassicConverter對(duì)象，實(shí)現(xiàn)Logback的自定義格式轉(zhuǎn)換器，參考代碼如下：在Logback配置文件中進(jìn)行如下修改：最終打印的日志格式如下樣式：4、采集日志信息實(shí)現(xiàn)分布式調(diào)用鏈界面展示一個(gè)最簡(jiǎn)單的demo示意圖如下：Paste_Image.png通過logstash采集日志到kafkakafka負(fù)責(zé)提供數(shù)據(jù)給Hbase通過Hbase進(jìn)行數(shù)據(jù)分析最終效果展示圖如下：Paste_Image.png四、總結(jié)對(duì)于分布式調(diào)用鏈來說，目前市面上有很多開源的工具，比如：pinpoint，Cat以及sky-walking等等，將這些工具與我們擴(kuò)展的調(diào)用鏈日志結(jié)合起