但行好事继榆，莫問(wèn)前程巾表。互聯(lián)網(wǎng)的前程如何網(wǎng)絡(luò)上各種大神從十萬(wàn)八千個(gè)緯度已經(jīng)分析過(guò)了略吨，但是作為技術(shù)人員集币，我們需要的是練好內(nèi)功，厚積薄發(fā)翠忠。
一鞠苟、為什么要用鏈路跟蹤
微服務(wù)大行其道的今天，如果做的是一個(gè)單體應(yīng)用秽之，甚至三個(gè)以內(nèi)的服務(wù)当娱，對(duì)于問(wèn)題的排查上，使用原始的登錄服務(wù)器考榨，一個(gè)一個(gè)日志文件對(duì)比當(dāng)然可行跨细，并且一般結(jié)合用戶的資金情況，大概率是要使用這種方案的河质。
然后當(dāng)有了五個(gè)冀惭、十個(gè)申鱼、五十個(gè)服務(wù)，每個(gè)服務(wù)有10個(gè)節(jié)點(diǎn)的集群時(shí)候云头，怎么破？一臺(tái)一臺(tái)去查淫半？當(dāng)然不現(xiàn)實(shí)溃槐。這時(shí)候就需要一個(gè)分布式日志系統(tǒng)來(lái)幫忙收集、清洗科吭、分析日志昏滴，并提供良好的查詢方式。
日志可以查詢了对人，那么所有的都集中到一起谣殊，微服務(wù)又是網(wǎng)格狀調(diào)用關(guān)系，怎么知道哪個(gè)服務(wù)的上下游關(guān)系呢牺弄？知道了上下游之后又怎么對(duì)應(yīng)到某一次請(qǐng)求上呢姻几？顧名思義：鏈路跟蹤解決某一次請(qǐng)求從頭到尾（經(jīng)歷N個(gè)微服務(wù)調(diào)用）的整個(gè)鏈路狀況，包括各服務(wù)上時(shí)間消耗势告、調(diào)用順序等蛇捌。
二、方案選擇
基于以上需求咱台，日志管理系統(tǒng)當(dāng)前有多種解決方案：阿里系络拌、騰訊系。當(dāng)然對(duì)于更多的應(yīng)該是開(kāi)源系回溺，開(kāi)源環(huán)境中當(dāng)前最流行的莫過(guò)于ELK架構(gòu)春贸。但是對(duì)于這個(gè)系列文章，只針對(duì)日志系統(tǒng)中鏈路跟蹤這一個(gè)小的點(diǎn)進(jìn)行討論遗遵。網(wǎng)上有多種方案萍恕，zipkin+sleuth、skywalking瓮恭、CAT雄坪、Pinpoint等，各有優(yōu)缺點(diǎn)屯蹦，大家可以參考下圖自行比較選擇维哈。
由于我使用springboot+spring cloud，因此決定走全家桶的模式登澜，選擇zipkin+sleuth阔挠，理論上應(yīng)該會(huì)支持的更好，然鵝······
現(xiàn)實(shí)很骨感脑蠕，因?yàn)槲业腞PC框架選擇了dubbo购撼，而阿里早已將dubbo交給apache跪削，包路徑已從com.alibaba.dubbo 2.6.6 升級(jí)為org.apache.dubbo 2.7.12，而sleuth的進(jìn)展比較緩慢迂求，如今仍不支持dubbo2.7+碾盐，因此暫時(shí)舍棄sleuth，只集成zipkin來(lái)進(jìn)行手動(dòng)跟蹤揩局。
三毫玖、原理
通過(guò)攔截器生成(或放入)traceId,spanId,parentId，其中traceId作為整個(gè)請(qǐng)求過(guò)程的跟蹤依據(jù)凌盯，貫穿整個(gè)請(qǐng)求過(guò)程付枫；spanId為某個(gè)服務(wù)唯一，作為下游服務(wù)的parentId驰怎，用于構(gòu)建上下游調(diào)用關(guān)系阐滩。
四、預(yù)期效果
構(gòu)建web應(yīng)用A县忌，dubbo服務(wù)B掂榔，dubbo服務(wù)C。
A作為請(qǐng)求入口芹枷，調(diào)用服務(wù)B衅疙，服務(wù)B作為消費(fèi)者，調(diào)用服務(wù)C鸳慈。
希望可以通過(guò)traceId,spanId,parentId來(lái)分析整個(gè)調(diào)用過(guò)程饱溢。
希望得到如下結(jié)構(gòu)，便可根據(jù)traceId=1獲取整個(gè)請(qǐng)求過(guò)程由A走芋、B绩郎、C組成，且調(diào)用關(guān)系為A-->B-->C：
A: traceId = 1,spanId = 1,parentId='';
B: traceId = 1,spanId = 2, parentId = 1;
C: traceId = 1,spanId = 3, parentId = 2;
