來(lái)自公眾號(hào)： 碼海

來(lái)自公眾號(hào)： 碼海

前言

在微服務(wù)架構(gòu)中，一次請(qǐng)求往往涉及到多個(gè)模塊，多個(gè)中間件，多臺(tái)機(jī)器的相互協(xié)作才能完成。這一系列調(diào)用請(qǐng)求中，有些是串行的，有些是并行的，那么如何確定這個(gè)請(qǐng)求背后調(diào)用了哪些應(yīng)用，哪些模塊，哪些節(jié)點(diǎn)及調(diào)用的先后順序？如何定位每個(gè)模塊的性能問(wèn)題？本文將為你揭曉答案。

本文將會(huì)從以下幾個(gè)方面來(lái)闡述

分布式追蹤系統(tǒng)原理及作用

SkyWalking的原理及架構(gòu)設(shè)計(jì)

我司在分布式調(diào)用鏈上的實(shí)踐

分布式追蹤系統(tǒng)原理及作用

SkyWalking的原理及架構(gòu)設(shè)計(jì)

我司在分布式調(diào)用鏈上的實(shí)踐

如何衡量一個(gè)接口的性能好壞，一般我們至少會(huì)關(guān)注以下三個(gè)指標(biāo)

接口的 RT 你怎么知道?

是否有異常響應(yīng)?

主要慢在哪里?

接口的 RT 你怎么知道?

是否有異常響應(yīng)?

主要慢在哪里?

在初期，公司剛起步的時(shí)候，可能多會(huì)采用如下單體架構(gòu)，對(duì)于單體架構(gòu)我們?cè)撚檬裁捶绞絹?lái)計(jì)算以上三個(gè)指標(biāo)呢?

展開全文

最容易想到的顯然是用 AOP

使用 AOP 在調(diào)用具體的業(yè)務(wù)邏輯前后分別打印一下時(shí)間即可計(jì)算出整體的調(diào)用時(shí)間，使用 AOP 來(lái) catch 住異常也可知道是哪里的調(diào)用導(dǎo)致的異常。

微服務(wù)架構(gòu)

在單體架構(gòu)中由于所有的服務(wù)，組件都在一臺(tái)機(jī)器上，所以相對(duì)來(lái)說(shuō)這些監(jiān)控指標(biāo)比較容易實(shí)現(xiàn)，不過(guò)隨著業(yè)務(wù)的快速發(fā)展，單體架構(gòu)必然會(huì)朝微服務(wù)架構(gòu)發(fā)展，如下

如圖示：一個(gè)稍微復(fù)雜的微服務(wù)架構(gòu)

如果有用戶反饋某個(gè)頁(yè)面很慢，我們知道這個(gè)頁(yè)面的請(qǐng)求調(diào)用鏈?zhǔn)?A ----- C ----- B ----- D，此時(shí)如何定位可能是哪個(gè)模塊引起的問(wèn)題。每個(gè)服務(wù) Service A,B,C,D 都有好幾臺(tái)機(jī)器。怎么知道某個(gè)請(qǐng)求調(diào)用了服務(wù)的具體哪臺(tái)機(jī)器呢？

可以明顯看到，由于無(wú)法準(zhǔn)確定位每個(gè)請(qǐng)求經(jīng)過(guò)的確切路徑，在微服務(wù)這種架構(gòu)下有以下幾個(gè)痛點(diǎn)

排查問(wèn)題難度大，周期長(zhǎng)

特定場(chǎng)景難復(fù)現(xiàn)

系統(tǒng)性能瓶頸分析較難

分布式調(diào)用鏈就是為了解決以上幾個(gè)問(wèn)題而生，它主要的作用如下

自動(dòng)采取數(shù)據(jù)

分析數(shù)據(jù)產(chǎn)生 完整調(diào)用鏈：有了請(qǐng)求的完整調(diào)用鏈，問(wèn)題有很大概率可復(fù)現(xiàn)

數(shù)據(jù)可視化：每個(gè)組件的性能可視化，能幫助我們很好地定位系統(tǒng)的瓶頸，及時(shí)找出問(wèn)題所在

自動(dòng)采取數(shù)據(jù)

分析數(shù)據(jù)產(chǎn)生 完整調(diào)用鏈：有了請(qǐng)求的完整調(diào)用鏈，問(wèn)題有很大概率可復(fù)現(xiàn)

數(shù)據(jù)可視化：每個(gè)組件的性能可視化，能幫助我們很好地定位系統(tǒng)的瓶頸，及時(shí)找出問(wèn)題所在

通過(guò)分布式追蹤系統(tǒng)能很好地定位如下請(qǐng)求的每條具體請(qǐng)求鏈路，從而輕易地實(shí)現(xiàn)請(qǐng)求鏈路追蹤，每個(gè)模塊的性能瓶頸定位與分析。

分布式調(diào)用鏈標(biāo)準(zhǔn) - OpenTracing

知道了分布式調(diào)用鏈的作用，那我們來(lái)看下如何實(shí)現(xiàn)分布式調(diào)用鏈的實(shí)現(xiàn)及原理， 首先為了解決不同的分布式追蹤系統(tǒng) API 不兼容的問(wèn)題，誕生了 OpenTracing 規(guī)范，OpenTracing 是一個(gè)輕量級(jí)的標(biāo)準(zhǔn)化層，它位于應(yīng)用程序/類庫(kù)和追蹤或日志分析程序之間。

這樣 OpenTracing 通過(guò)提供平臺(tái)無(wú)關(guān)，廠商無(wú)關(guān)的 API，使得開發(fā)人員能夠方便地添加追蹤系統(tǒng)的實(shí)現(xiàn)。

說(shuō)到這大家是否想過(guò) Java 中類似的實(shí)現(xiàn)？還記得 JDBC 吧，通過(guò)提供一套標(biāo)準(zhǔn)的接口讓各個(gè)廠商去實(shí)現(xiàn)，程序員即可面對(duì)接口編程，不用關(guān)心具體的實(shí)現(xiàn)。這里的接口其實(shí)就是標(biāo)準(zhǔn)，所以制定一套標(biāo)準(zhǔn)非常重要，可以實(shí)現(xiàn)組件的可插拔。

接下來(lái)我們來(lái)看 OpenTracing 的數(shù)據(jù)模型，主要有以下三個(gè)

Trace：一個(gè)完整請(qǐng)求鏈路

Span：一次調(diào)用過(guò)程(需要有開始時(shí)間和結(jié)束時(shí)間)

SpanContext：Trace 的全局上下文信息, 如里面有traceId

Trace：一個(gè)完整請(qǐng)求鏈路

Span：一次調(diào)用過(guò)程(需要有開始時(shí)間和結(jié)束時(shí)間)

SpanContext：Trace 的全局上下文信息, 如里面有traceId

理解這三個(gè)概念非常重要，為了讓大家更好地理解這三個(gè)概念，我特意畫了一張圖

如圖示，一次下單的 完整請(qǐng)求完整就是一個(gè) Trace, 顯然對(duì)于這個(gè)請(qǐng)求來(lái)說(shuō)，必須要有一個(gè)全局標(biāo)識(shí)來(lái)標(biāo)識(shí)這一個(gè)請(qǐng)求，每一次調(diào)用就稱為一個(gè) Span，每一次調(diào)用都要帶上全局的 TraceId, 這樣才可把全局 TraceId 與每個(gè)調(diào)用關(guān)聯(lián)起來(lái)，這個(gè) TraceId 就是通過(guò) SpanContext 傳輸?shù)?，既然要傳輸顯然都要遵循協(xié)議來(lái)調(diào)用。如圖示，我們把傳輸協(xié)議比作車，把 SpanContext 比作貨，把 Span 比作路應(yīng)該會(huì)更好理解一些。

理解了這三個(gè)概念，接下來(lái)我看看分布式追蹤系統(tǒng)如何采集統(tǒng)一圖中的微服務(wù)調(diào)用鏈

我們可以看到底層有一個(gè) Collector 一直在默默無(wú)聞地收集數(shù)據(jù)，那么每一次調(diào)用 Collector 會(huì)收集哪些信息呢。

全局 trace_id：這是顯然的，這樣才能把每一個(gè)子調(diào)用與最初的請(qǐng)求關(guān)聯(lián)起來(lái)

span_id: 圖中的 0，1，1.1，2,這樣就能標(biāo)識(shí)是哪一個(gè)調(diào)用

parent_span_id：比如 b 調(diào)用 d 的 span_id 是 1.1，那么它的 parent_span_id 即為 a 調(diào)用 b 的 span_id 即 1，這樣才能把兩個(gè) 緊鄰的調(diào)用關(guān)聯(lián)起來(lái)。

有了這些信息，Collector 收集的每次調(diào)用的信息如下

根據(jù)這些圖表信息顯然可以據(jù)此來(lái)畫出調(diào)用鏈的可視化視圖如下

于是一個(gè)完整的分布式追蹤系統(tǒng)就實(shí)現(xiàn)了。

以上實(shí)現(xiàn)看起來(lái)確實(shí)簡(jiǎn)單，但有以下幾個(gè)問(wèn)題需要我們仔細(xì)思考一下

怎么 自動(dòng)采集 span 數(shù)據(jù)：自動(dòng)采集，對(duì)業(yè)務(wù)代碼無(wú)侵入

如何跨進(jìn)程傳遞 context

traceId 如何保證全局唯一

請(qǐng)求量這么多采集會(huì)不會(huì)影響性能

接下我來(lái)看看 SkyWalking 是如何解決以上四個(gè)問(wèn)題的

SkyWalking的原理及架構(gòu)設(shè)計(jì)怎么自動(dòng)采集 span 數(shù)據(jù)

SkyWalking 采用了 插件化+ javaagent的形式來(lái)實(shí)現(xiàn)了 span 數(shù)據(jù)的自動(dòng)采集，這樣可以做到對(duì)代碼的 無(wú)侵入性，插件化意味著可插拔，擴(kuò)展性好（后文會(huì)介紹如何定義自己的插件）

如何跨進(jìn)程傳遞 context

我們知道數(shù)據(jù)一般分為 header 和 body, 就像 http 有 header 和 body, RocketMQ 也有 MessageHeader，Message Body, body 一般放著業(yè)務(wù)數(shù)據(jù)，所以不宜在 body 中傳遞 context，應(yīng)該在 header 中傳遞 context，如圖示

dubbo 中的 attachment 就相當(dāng)于 header ,所以我們把 context 放在 attachment 中，這樣就解決了 context 的傳遞問(wèn)題。

小提示：這里的傳遞 context 流程均是在 dubbo plugin 處理的，業(yè)務(wù)無(wú)感知，這個(gè) plugin 是怎么實(shí)現(xiàn)的呢，下文會(huì)分析 traceId 如何保證全局唯一

要保證全局唯一 ，我們可以采用分布式或者本地生成的 ID，使用分布式話需要有一個(gè)發(fā)號(hào)器，每次請(qǐng)求都要先請(qǐng)求一下發(fā)號(hào)器，會(huì)有一次網(wǎng)絡(luò)調(diào)用的開銷，所以 SkyWalking 最終采用了本地生成 ID 的方式，它采用了大名鼎鼎的 snowflow 算法，性能很高。

圖示: snowflake 算法生成的 id

不過(guò) snowflake 算法有一個(gè)眾所周知的問(wèn)題： 時(shí)間回?fù)埽@個(gè)問(wèn)題可能會(huì)導(dǎo)致生成的 id 重復(fù)。那么 SkyWalking 是如何解決時(shí)間回?fù)軉?wèn)題的呢。

每生成一個(gè) id，都會(huì)記錄一下生成 id 的時(shí)間（lastTimestamp），如果發(fā)現(xiàn)當(dāng)前時(shí)間比上一次生成 id 的時(shí)間（lastTimestamp）還小，那說(shuō)明發(fā)生了時(shí)間回?fù)埽藭r(shí)會(huì)生成一個(gè)隨機(jī)數(shù)來(lái)作為 traceId。這里可能就有同學(xué)要較真了，可能會(huì)覺(jué)得生成的這個(gè)隨機(jī)數(shù)也會(huì)和已生成的全局 id 重復(fù)，是否再加一層校驗(yàn)會(huì)好點(diǎn)。

這里要說(shuō)一下系統(tǒng)設(shè)計(jì)上的方案取舍問(wèn)題了，首先如果針對(duì)產(chǎn)生的這個(gè)隨機(jī)數(shù)作唯一性校驗(yàn)無(wú)疑會(huì)多一層調(diào)用，會(huì)有一定的性能損耗，但其實(shí)時(shí)間回?fù)馨l(fā)生的概率很?。òl(fā)生之后由于機(jī)器時(shí)間紊亂，業(yè)務(wù)會(huì)受到很大影響，所以機(jī)器時(shí)間的調(diào)整必然要慎之又慎），再加上生成的隨機(jī)數(shù)重合的概率也很小，綜合考慮這里確實(shí)沒(méi)有必要再加一層全局惟一性校驗(yàn)。對(duì)于技術(shù)方案的選型，一定要避免過(guò)度設(shè)計(jì)，過(guò)猶不及。

請(qǐng)求量這么多，全部采集會(huì)不會(huì)影響性能?

如果對(duì)每個(gè)請(qǐng)求調(diào)用都采集，那毫無(wú)疑問(wèn)數(shù)據(jù)量會(huì)非常大，但反過(guò)來(lái)想一下，是否真的有必要對(duì)每個(gè)請(qǐng)求都采集呢，其實(shí)沒(méi)有必要，我們可以設(shè)置采樣頻率，只采樣部分?jǐn)?shù)據(jù)，SkyWalking 默認(rèn)設(shè)置了 3 秒采樣 3 次，其余請(qǐng)求不采樣,如圖示

這樣的采樣頻率其實(shí)足夠我們分析組件的性能了，按 3 秒采樣 3 次這樣的頻率來(lái)采樣數(shù)據(jù)會(huì)有啥問(wèn)題呢。理想情況下，每個(gè)服務(wù)調(diào)用都在同一個(gè)時(shí)間點(diǎn)（如下圖示）這樣的話每次都在同一時(shí)間點(diǎn)采樣確實(shí)沒(méi)問(wèn)題

但在生產(chǎn)上，每次服務(wù)調(diào)用基本不可能都在同一時(shí)間點(diǎn)調(diào)用，因?yàn)槠陂g有網(wǎng)絡(luò)調(diào)用延時(shí)等，實(shí)際調(diào)用情況很可能是下圖這樣

這樣的話就會(huì)導(dǎo)致某些調(diào)用在服務(wù) A 上被采樣了，在服務(wù) B，C 上不被采樣，也就沒(méi)法分析調(diào)用鏈的性能，那么 SkyWalking 是如何解決的呢。

它是這樣解決的：如果上游有攜帶 Context 過(guò)來(lái)（說(shuō)明上游采樣了），則下游 強(qiáng)制采集數(shù)據(jù)。這樣可以保證鏈路完整。

SkyWalking 的基礎(chǔ)架構(gòu)

SkyWalking 的基礎(chǔ)如下架構(gòu)，可以說(shuō)幾乎所有的的分布式調(diào)用都是由以下幾個(gè)組件組成的

首先當(dāng)然是節(jié)點(diǎn)數(shù)據(jù)的定時(shí)采樣，采樣后將數(shù)據(jù)定時(shí)上報(bào)，將其存儲(chǔ)到 ES, MySQL 等持久化層，有了數(shù)據(jù)自然而然可根據(jù)數(shù)據(jù)做可視化分析。

SkyWalking 的性能如何

接下來(lái)大家肯定比較關(guān)心 SkyWalking 的性能，那我們來(lái)看下官方的測(cè)評(píng)數(shù)據(jù)

圖中藍(lán)色代表未使用 SkyWalking 的表現(xiàn)，橙色代表使用了 SkyWalking 的表現(xiàn)，以上是在 TPS 為 5000 的情況下測(cè)出的數(shù)據(jù)，可以看出，不論是 CPU，內(nèi)存，還是響應(yīng)時(shí)間，使用 SkyWalking 帶來(lái)的性能損耗幾乎可以忽略不計(jì)。

接下來(lái)我們?cè)賮?lái)看 SkyWalking 與另一款業(yè)界比較知名的分布式追蹤工具 Zipkin, Pinpoint 的對(duì)比（在采樣率為 1 秒 1 個(gè)，線程數(shù) 500，請(qǐng)求總數(shù)為 5000 的情況下做的對(duì)比）,可以看到在關(guān)鍵的響應(yīng)時(shí)間上， Zipkin（117ms）,PinPoint（201ms） 遠(yuǎn)遜色于 SkyWalking（22ms）!

從性能損耗這個(gè)指標(biāo)上看，SkyWalking 完勝！

再看下另一個(gè)指標(biāo)：對(duì)代碼的侵入性如何，ZipKin 是需要在應(yīng)用程序中埋點(diǎn)的，對(duì)代碼的侵入強(qiáng)，而 SkyWalking 采用 javaagent + 插件化這種修改字節(jié)碼的方式可以做到 對(duì)代碼無(wú)任何侵入，除了性能和對(duì)代碼的侵入性上 SkyWaking 表現(xiàn)不錯(cuò)外，它還有以下優(yōu)勢(shì)幾個(gè)優(yōu)勢(shì)

對(duì)多語(yǔ)言的支持，組件豐富：目前其支持 Java, .Net Core, PHP, NodeJS, Golang, LUA 語(yǔ)言，組件上也支持dubbo, mysql 等常見組件，大部分能滿足我們的需求。

擴(kuò)展性：對(duì)于不滿足的插件，我們按照 SkyWalking 的規(guī)則手動(dòng)寫一個(gè)即可，新實(shí)現(xiàn)的插件對(duì)代碼無(wú)入侵。

對(duì)多語(yǔ)言的支持，組件豐富：目前其支持 Java, .Net Core, PHP, NodeJS, Golang, LUA 語(yǔ)言，組件上也支持dubbo, mysql 等常見組件，大部分能滿足我們的需求。

擴(kuò)展性：對(duì)于不滿足的插件，我們按照 SkyWalking 的規(guī)則手動(dòng)寫一個(gè)即可，新實(shí)現(xiàn)的插件對(duì)代碼無(wú)入侵。

由上文可知 SkyWalking 有很多優(yōu)點(diǎn)，那么是不是我們用了它的全部組件了呢，其實(shí)不然，來(lái)看下其在我司的應(yīng)用架構(gòu)

從圖中可以看出我們只采用了 SkyWalking 的 agent 來(lái)進(jìn)行采樣，放棄了另外的「數(shù)據(jù)上報(bào)及分析」，「數(shù)據(jù)存儲(chǔ)」，「數(shù)據(jù)可視化」三大組件，那為啥不直接采用 SkyWalking 的整套解決方案呢，因?yàn)樵诮尤?SkyWalking 之前我們的 Marvin 監(jiān)控生態(tài)體系已經(jīng)相對(duì)比較完善了，如果把其整個(gè)替換成 SkyWalking，一來(lái)沒(méi)有必要，Marvin 在大多數(shù)場(chǎng)景下都能滿足我們的需求，二來(lái)系統(tǒng)替換成本高，三來(lái)如果重新接入用戶學(xué)習(xí)成本很高。

這也給我們一個(gè)啟示：任何產(chǎn)品搶占先機(jī)很重要，后續(xù)產(chǎn)品的替換成本會(huì)很高，搶占先機(jī)，也就是搶占了用戶的心智，這就像微信雖然 UI，功能上制作精良，但在國(guó)外照樣干不過(guò) Whatsapp 一樣，因?yàn)橄葯C(jī)已經(jīng)沒(méi)了。

從另一方面來(lái)看，對(duì)架構(gòu)來(lái)說(shuō)，沒(méi)有最好的，最有最合適的，結(jié)合當(dāng)前業(yè)務(wù)場(chǎng)景去平衡折中才是架構(gòu)設(shè)計(jì)的本質(zhì)

我司對(duì) SkyWalking 作了哪些改造和實(shí)踐

我司主要作了以下改造和實(shí)踐

預(yù)發(fā)環(huán)境由于調(diào)試需要強(qiáng)制采樣

實(shí)現(xiàn)更細(xì)粒度的采樣?

日志中嵌入traceId

自研實(shí)現(xiàn)了 SkyWalking 插件

從上文分析可知 Collector 是在后臺(tái)定時(shí)采樣的，這不挺好的嗎，為啥要實(shí)現(xiàn)強(qiáng)制采樣呢。還是為了排查定位問(wèn)題，有時(shí)線上出現(xiàn)問(wèn)題，我們希望在預(yù)發(fā)上能重現(xiàn)，希望能看到這個(gè)請(qǐng)求的完整調(diào)用鏈，所以在預(yù)發(fā)上實(shí)現(xiàn)強(qiáng)制采樣很有必要。所以我們對(duì) Skywalking 的 dubbo 插件進(jìn)行了改造，實(shí)現(xiàn)強(qiáng)制采樣

我們?cè)谡?qǐng)求的 Cookie 上帶上一個(gè)類似 force_flag = true這樣的鍵值對(duì)來(lái)表示我們希望強(qiáng)制采樣，在網(wǎng)關(guān)收到這個(gè) Cookie 后，就會(huì)在 dubbo 的 attachment 里帶上force_flag = true 這個(gè)鍵值對(duì)，然后 skywalking 的 dubbo 插件就可以據(jù)此來(lái)判斷是否是強(qiáng)制采樣了，如果有這個(gè)值即強(qiáng)制采樣，如果沒(méi)有這個(gè)值，則走正常的定時(shí)采樣。

實(shí)現(xiàn)更細(xì)粒度的采樣?

哈叫更細(xì)粒度的采樣。先來(lái)看下 skywalking 默認(rèn)的采樣方式 ，即統(tǒng)一采樣

我們知道這種方式默認(rèn)是 3 秒采樣前 3 次，其他請(qǐng)求都丟棄，這樣的話有個(gè)問(wèn)題，假設(shè)在這臺(tái)機(jī)器上在 3 秒內(nèi)有多個(gè) dubbo，mysql，redis 調(diào)用，但在如果前三次都是 dubbo 調(diào)用的話，其他像 mysql, redis 等調(diào)用就采樣不到了，所以我們對(duì) skywalking 進(jìn)行了改造，實(shí)現(xiàn)了分組采樣，如下

就是說(shuō) 3 秒內(nèi)進(jìn)行 3 次 redis, dubbo, mysql 等的采樣，也就避免了此問(wèn)題日志中如何嵌入traceId?

輸出日志中嵌入 traceId 便于我們排查問(wèn)題，所以打出出 traceId 非常有必要，該怎么在日志中嵌入 traceId 呢？我們用的是 log4j，這里就要了解一下 log4j 的插件機(jī)制了，log4j 允許我們自定義插件來(lái)輸出日志的格式，首先我們需要定義日志的格式，在自定義的日志格式中嵌入 %traceId, 作為占位符，如下

然后我們?cè)賹?shí)現(xiàn)一個(gè) log4j 的插件，如下

首先 log4j 的插件要定義一個(gè)類，這個(gè)類要繼承 LogEventPatternConverter 這個(gè)類，并且用標(biāo)準(zhǔn) Plugin 將其自身聲明為 Plugin，通過(guò) @ConverterKeys 這個(gè)注解指定了要替換的占位符，然后在 format 方法里將其替換掉。 這樣在日志中就會(huì)出現(xiàn)我們想要的 TraceId ,如下我司自研了哪些 skywalking 插件

SkyWalking 實(shí)現(xiàn)了很多插件，不過(guò)未提供 memcached 和 druid 的插件，所以我們根據(jù)其規(guī)范自研了這兩者的插件

插件如何實(shí)現(xiàn)呢，可以看到它主要由三個(gè)部分組成

插件定義類: 指定插件的定義類，最終會(huì)根據(jù)這里的定義類打包生成 plugin

Instrumentation: 指定切面，切點(diǎn)，要對(duì)哪個(gè)類的哪個(gè)方法進(jìn)行增強(qiáng)

Interceptor,指定步驟 2 中要在方法的前置，后置還是異常中寫增強(qiáng)邏輯

可能大家看了還是不懂，那我們以 dubbo plugin 來(lái)簡(jiǎn)單講解一下，我們知道在 dubbo 服務(wù)中，每個(gè)請(qǐng)求從 netty 接收到消息，遞交給業(yè)務(wù)線程池處理開始，到真正調(diào)用到業(yè)務(wù)方法結(jié)束，中間經(jīng)過(guò)了十幾個(gè) Filter 的處理

而 MonitorFilter 可以攔截所有客戶端發(fā)出請(qǐng)求或者服務(wù)端處理請(qǐng)求，所以我們可以對(duì) MonitorFilter 作增強(qiáng)，在其調(diào)用 invoke 方法前，將全局 traceId 注入到其 Invocation 的 attachment 中，這樣就可以確保在請(qǐng)求到達(dá)真正的業(yè)務(wù)邏輯前就已經(jīng)存在全局 traceId。

所以顯然我們需要在插件中指定我們要增強(qiáng)的類（MonitorFilter）,對(duì)其方法（invoke）做增強(qiáng)，要對(duì)這個(gè)方法做哪些增強(qiáng)呢，這就是攔截器（Inteceptor）要做的事，來(lái)看看 Dubbo 插件中的 instrumentation（DubboInstrumentation）

我們?cè)倏纯聪麓a中描寫的攔截器（Inteceptor）干了什么事，以下列出關(guān)鍵步驟

首先 beforeMethod 代表在執(zhí)行 MonitorFilter 的 invoke 方法前會(huì)調(diào)用這里的方法，與之對(duì)應(yīng)的是 afterMethod，代表在執(zhí)行 invoke 方法后作增強(qiáng)邏輯。

其次我們從第 2，3點(diǎn)可以看到，不管是 consumer 還是 provider, 都對(duì)其全局 ID 作了相應(yīng)處理，這樣確保到達(dá)真正的業(yè)務(wù)層的時(shí)候保證有了此全局 traceid，定義好 Instrumentation 和 Interceptor 后，最后一步就是在 skywalking.def 里指定定義的類

// skywalking-plugin.def 文件

dubbo=org.apache.skywalking.apm.plugin.asf.dubbo.DubboInstrumentation

這樣打包出來(lái)的插件就會(huì)對(duì) MonitorFilter 的 invoke 方法進(jìn)行增強(qiáng)，在 invoke 方法執(zhí)行前對(duì)期 attachment 作注入全局 traceId 等操作，這一切都是靜默的，對(duì) 代碼無(wú)侵入的。

總結(jié)

本文由淺入深地介紹了分布式追蹤系統(tǒng)的原理，相信大家對(duì)其作用及工作機(jī)制有了比較深的理解，特別需要注意的是，引入某項(xiàng)技巧，一定要結(jié)合現(xiàn)有的技術(shù)架構(gòu)作出最合理的選擇，就像 SkyWalking 有四個(gè)模塊，我司只采用其 agent 采樣功能一樣， 沒(méi)有最好的技術(shù)，只有最合適的技術(shù)，通過(guò)此文，相信大家應(yīng)該對(duì) SkyWalking 的實(shí)現(xiàn)機(jī)制有了比較清晰的認(rèn)識(shí)，文中只是介紹了一下 SkyWalking 的插件實(shí)現(xiàn)方式，不過(guò)其畢竟是工業(yè)級(jí)軟件，要了解其博大精深，還要多讀源碼哦。

---END---

推薦↓↓↓