每生成一個(gè) id，都會(huì)記錄一下生成 id 的時(shí)間（lastTimestamp），如果發(fā)現(xiàn)當(dāng)前時(shí)間比上一次生成 id 的時(shí)間（lastTimestamp）還小，那說(shuō)明發(fā)生了時(shí)間回?fù)?，此時(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)（如下圖示）這樣的話(huà)每次都在同一時(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à)就會(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è)，線(xiàn)程數(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 等常見(jiàn)組件，大部分能滿(mǎn)足我們的需求。

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

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

SkyWalking 在我司的應(yīng)用架構(gòu)

由上文可知 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)景下都能滿(mǎn)足我們的需求，二來(lái)系統(tǒng)替換成本高，三來(lái)如果重新接入用戶(hù)學(xué)習(xí)成本很高。

這也給我們一個(gè)啟示：任何產(chǎn)品搶占先機(jī)很重要，后續(xù)產(chǎn)品的替換成本會(huì)很高，搶占先機(jī)，也就是搶占了用戶(hù)的心智，這就像微信雖然 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í)踐

1. 預(yù)發(fā)環(huán)境由于調(diào)試需要強(qiáng)制采樣
2. 實(shí)現(xiàn)更細(xì)粒度的采樣?
3. 日志中嵌入traceId
4. 自研實(shí)現(xiàn)了 SkyWalking 插件

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

從上文分析可知 Collector 是在后臺(tái)定時(shí)采樣的，這不挺好的嗎，為啥要實(shí)現(xiàn)強(qiáng)制采樣呢。還是為了排查定位問(wèn)題，有時(shí)線(xiàn)上出現(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è)類(lèi)似 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)求都丟棄，這樣的話(huà)有個(gè)問(wèn)題，假設(shè)在這臺(tái)機(jī)器上在 3 秒內(nèi)有多個(gè) dubbo，mysql，redis 調(diào)用，但在如果前三次都是 dubbo 調(diào)用的話(huà)，其他像 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è)類(lèi)，這個(gè)類(lèi)要繼承 LogEventPatternConverter 這個(gè)類(lèi)，并且用標(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è)部分組成

1. 插件定義類(lèi): 指定插件的定義類(lèi)，最終會(huì)根據(jù)這里的定義類(lèi)打包生成 plugin
2. Instrumentation: 指定切面，切點(diǎn)，要對(duì)哪個(gè)類(lèi)的哪個(gè)方法進(jìn)行增強(qiáng)
3. Interceptor,指定步驟 2 中要在方法的前置，后置還是異常中寫(xiě)增強(qiáng)邏輯

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

而 MonitorFilter 可以攔截所有客戶(hù)端發(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)的類(lèi)（MonitorFilter）,對(duì)其方法（invoke）做增強(qiáng)，要對(duì)這個(gè)方法做哪些增強(qiáng)呢，這就是攔截器（Inteceptor）要做的事，來(lái)看看 Dubbo 插件中的 instrumentation（DubboInstrumentation）

我們?cè)倏纯聪麓a中描寫(xiě)的攔截器（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 里指定定義的類(lèi)

//?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í)軟件，要了解其博大精深，還要多讀源碼哦。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝