1.分布式鏈路追蹤的起源

當(dāng)周末躺在被窩里，點(diǎn)外賣(mài)時(shí)；雙 11 的零點(diǎn)，瘋狂提交訂單時(shí)；假期和基友激情開(kāi)黑，五殺超神…在這個(gè)精彩紛呈的互聯(lián)網(wǎng)世界里，這些應(yīng)用背后又隱藏著什么？每一次點(diǎn)擊行為在 IT 世界里會(huì)流經(jīng)哪些節(jié)點(diǎn)，調(diào)用哪些服務(wù)，帶來(lái)哪些變化？這一切龐雜且精密，超出了人力探索的邊界，而分布式鏈路追蹤就是追溯請(qǐng)求在 IT 系統(tǒng)間流轉(zhuǎn)路徑與狀態(tài)的一門(mén)技術(shù)。接下來(lái)，讓我們通過(guò)對(duì)分布式鏈路追蹤的來(lái)了解這個(gè) IT 世界！

說(shuō)到分布式鏈路追蹤，就繞不開(kāi)分布式系統(tǒng)與微服務(wù)的興起。早期 IT 系統(tǒng)非常簡(jiǎn)單，幾乎所有程序都運(yùn)行在同一個(gè)節(jié)點(diǎn)，互相之間也沒(méi)有什么依賴(lài)。但隨著硬件技術(shù)突飛猛進(jìn)，硬件成本大幅下降，軟件復(fù)雜度卻越來(lái)越高。單一系統(tǒng)性能無(wú)法滿(mǎn)足復(fù)雜的數(shù)據(jù)計(jì)算任務(wù)，而軟件邏輯的復(fù)雜性也導(dǎo)致維護(hù)成本大幅上升。另外，單節(jié)點(diǎn)的可靠性也難以保障，不可避免的會(huì)偶爾出現(xiàn)宕機(jī)等行為，影響軟件的可用性。“性能、可維護(hù)性和可用性”這三大因素促使了分布式系統(tǒng)與微服務(wù)的誕生。

為了解決上述問(wèn)題，人們很自然想到：既然一個(gè)硬件節(jié)點(diǎn)無(wú)法很好的運(yùn)行軟件，那能不能夠通過(guò)多個(gè)節(jié)點(diǎn)來(lái)共同完成？并且為不同節(jié)點(diǎn)分派不同任務(wù)去提高效率。就好比通過(guò)不同角色分工協(xié)同的汽車(chē)生產(chǎn)流水線，分布式系統(tǒng)與微服務(wù)的理念亦是如此，如下圖所示。

分布式系統(tǒng)與微服務(wù)自誕生就被廣泛應(yīng)用，主要得益于以下優(yōu)勢(shì)：

• 擴(kuò)展性

分布式系統(tǒng)天然具備“按需擴(kuò)展”的能力，比如雙 11 大促前通過(guò)添加機(jī)器實(shí)現(xiàn)快速水平擴(kuò)容，大促結(jié)束后釋放機(jī)器，充分利用云計(jì)算的分時(shí)復(fù)用能力，節(jié)約成本。利用微服務(wù)，還可以實(shí)現(xiàn)按需精準(zhǔn)擴(kuò)容，比如登錄服務(wù)擴(kuò)容 10 倍，下單服務(wù)擴(kuò)容3倍，最大化的節(jié)省資源。

• 可靠性

分布式系統(tǒng)可以有效抵抗“單點(diǎn)風(fēng)險(xiǎn)”，不會(huì)因?yàn)槟骋粋€(gè)節(jié)點(diǎn)的故障，影響整體的服務(wù)可用性。結(jié)合流量調(diào)度、離群實(shí)例摘除和彈性擴(kuò)容等技術(shù)，甚至可以實(shí)現(xiàn)故障自愈。

• 可維護(hù)性

分布式系統(tǒng)可維護(hù)性更強(qiáng)，一方面我們將一個(gè)復(fù)雜服務(wù)拆分成多個(gè)簡(jiǎn)單的微服務(wù)，每個(gè)微服務(wù)的邏輯都更加清晰、更易理解。就好比我們寫(xiě)代碼，將一個(gè)幾百行的復(fù)雜函數(shù)重構(gòu)成若干個(gè)簡(jiǎn)單函數(shù)，代碼可讀性就會(huì)直線上升。另一方面，一些通用的微服務(wù)可以被高度復(fù)用，無(wú)需重復(fù)開(kāi)發(fā)和維護(hù)，比如你在開(kāi)發(fā)一個(gè)電商 APP，可以直接調(diào)用第三方提供的支付、物流等服務(wù)接口，整體開(kāi)發(fā)和維護(hù)效率將大幅提升。

雖然分布式系統(tǒng)與微服務(wù)具有非常顯著優(yōu)勢(shì)，但凡事有利必有弊，它們?cè)谟行Ы鉀Q原有問(wèn)題基礎(chǔ)上，也為系統(tǒng)開(kāi)發(fā)和運(yùn)維帶來(lái)了新挑戰(zhàn)，主要包括以下幾點(diǎn)：

• 模糊性

隨著系統(tǒng)的分布式程度越來(lái)越高，異常表象與根因之間的邏輯聯(lián)系變得愈加模糊，問(wèn)題診斷的難度急劇上升。比如 A、B 兩個(gè)服務(wù)共享同一個(gè)數(shù)據(jù)庫(kù)實(shí)例，當(dāng) A 服務(wù)在壓測(cè)期間，大量占用數(shù)據(jù)庫(kù)的服務(wù)端連接和計(jì)算資源，會(huì)導(dǎo)致 B 服務(wù)出現(xiàn)連接超時(shí)或響應(yīng)變慢等問(wèn)題。如果 B 服務(wù)是通過(guò) C 服務(wù)間接依賴(lài)該數(shù)據(jù)庫(kù)實(shí)例，問(wèn)題的定位就會(huì)變得更加困難。

• 不一致

雖然分布式應(yīng)用從總體上變的更加可靠，但是每一個(gè)獨(dú)立節(jié)點(diǎn)的狀態(tài)卻難以保證。導(dǎo)致這種不一致的原因有很多，比如前文提到的單機(jī)故障這種預(yù)期外的不一致，或者應(yīng)用 Owner 執(zhí)行分批發(fā)布或流量灰度時(shí)導(dǎo)致的預(yù)期內(nèi)行為不一致。這種不一致性導(dǎo)致我們難以確定一個(gè)用戶(hù)請(qǐng)求在系統(tǒng)內(nèi)的準(zhǔn)確執(zhí)行路徑與行為邏輯，可能引發(fā)不可預(yù)知的邏輯災(zāi)難。

• 去中心化

當(dāng)你的系統(tǒng)擁有上千個(gè)微服務(wù)鏡像運(yùn)行在數(shù)百臺(tái)機(jī)器實(shí)例上，你該如何梳理它們之間的依賴(lài)關(guān)系，又該如何找到核心業(yè)務(wù)的關(guān)鍵執(zhí)行路徑？特別是在分布式的場(chǎng)景下，你沒(méi)有一個(gè)中心化的節(jié)點(diǎn)（Master）來(lái)保存每個(gè)服務(wù)之間的依賴(lài)與調(diào)度狀態(tài)，每個(gè)獨(dú)立節(jié)點(diǎn)都在自行其是，無(wú)法分辨自己在整個(gè)系統(tǒng)中的位置，只能“盲人摸象、管中窺豹”，缺乏全局視圖。

分布式系統(tǒng)與微服務(wù)帶來(lái)的新挑戰(zhàn)無(wú)疑讓人頭痛，但也帶來(lái)了新技術(shù)的發(fā)展契機(jī)，科技的發(fā)展總是這樣循環(huán)往復(fù)，螺旋式上升。它們帶來(lái)的新問(wèn)題，促使了分布式鏈路追蹤的誕生，使你能夠有效的觀察全局，追蹤流量。我們將在下個(gè)章節(jié)了解分布式鏈路追蹤的誕生歷程與核心理念。

2.分布式鏈路追蹤的誕生

為了應(yīng)對(duì)分布式環(huán)境下的不一致、模糊性等前文提到的各類(lèi)問(wèn)題問(wèn)題，人們?cè)噲D通過(guò)請(qǐng)求粒度的軌跡追蹤與數(shù)據(jù)透?jìng)?，?shí)現(xiàn)節(jié)點(diǎn)間的確定性關(guān)聯(lián)，分布式鏈路追蹤技術(shù)也由此誕生。

里程碑事件：Google Dapper

分布式鏈路追蹤誕生的標(biāo)志性事件就是 Google Dapper 論文的發(fā)表。2010 年 4 月，Benjamin H. Sigelman 等人在 Google Technical Report 上發(fā)表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，揭開(kāi)了分布式鏈路追蹤的技術(shù)大幕，開(kāi)啟了一段全新技術(shù)浪潮。

Dapper 首先明確了分布式鏈路追蹤的兩個(gè)目標(biāo)：任意部署和持續(xù)監(jiān)測(cè)。進(jìn)而給出了三個(gè)具體的設(shè)計(jì)準(zhǔn)則：

• 低開(kāi)銷(xiāo)：確保核心系統(tǒng)不會(huì)因?yàn)轭~外的性能開(kāi)銷(xiāo)拒絕使用。

• 應(yīng)用級(jí)透明：對(duì)應(yīng)用開(kāi)發(fā)透明，無(wú)需開(kāi)發(fā)人員的協(xié)助，降低接入門(mén)檻，提高迭代效率。

• 可擴(kuò)展：在未來(lái)相當(dāng)長(zhǎng)一段時(shí)間內(nèi)，隨著業(yè)務(wù)的高速發(fā)展，仍然可以有效運(yùn)轉(zhuǎn)。

下面幾張圖展示了 Dapper 對(duì)鏈路透?jìng)?、調(diào)用鏈結(jié)構(gòu)和數(shù)據(jù)采集流程的描述，我們將在后續(xù)章節(jié)詳細(xì)展開(kāi)介紹，對(duì) Dapper 感興趣的同學(xué)建議直接閱讀原作。

Dapper 論文有兩個(gè)重要的意義，一是詳細(xì)闡述了分布式鏈路追蹤的設(shè)計(jì)理念，為后來(lái)的實(shí)現(xiàn)者提供了重要的理論指導(dǎo)；二是通過(guò) Dapper 在 Google 生產(chǎn)環(huán)境的大規(guī)模落地實(shí)踐，證明了分布式鏈路追蹤技術(shù)的企業(yè)級(jí)價(jià)值，為分布式鏈路追蹤的推廣作出了不可磨滅的貢獻(xiàn)。

基本原理

分布式鏈路追蹤并不是無(wú)中生有、憑空誕生的新概念，而是軌跡追蹤在 IT 領(lǐng)域的又一次成功運(yùn)用。軌跡追蹤理念早已被廣泛應(yīng)用于社會(huì)生活方方面面，比如物流訂單追蹤。一個(gè)快遞包裹在發(fā)件站被賦予快遞單號(hào)，沿途中轉(zhuǎn)節(jié)點(diǎn)會(huì)記錄該快遞到達(dá)時(shí)間等信息，而用戶(hù)通過(guò)快遞單號(hào)就可以查詢(xún)自己的包裹途徑了哪些站點(diǎn)，耗時(shí)多久，是否存在滯留或丟件情況。下表對(duì)比了物流追蹤與鏈路追蹤的關(guān)聯(lián)與差異性，以便大家理解。

分布式鏈路追蹤的基本原理就是在分布式應(yīng)用的接口方法上設(shè)置一些觀察點(diǎn)（類(lèi)似快遞中轉(zhuǎn)站記錄點(diǎn)），然后在入口節(jié)點(diǎn)給每個(gè)請(qǐng)求分配一個(gè)全局唯一的標(biāo)識(shí) TraceId（類(lèi)似快遞單號(hào)），當(dāng)請(qǐng)求流經(jīng)這些觀察點(diǎn)時(shí)就會(huì)記錄一行對(duì)應(yīng)的鏈路日志（包含鏈路唯一標(biāo)識(shí)，接口名稱(chēng)，時(shí)間戳，主機(jī)信息等）。最后通過(guò) TraceId 將一次請(qǐng)求的所有鏈路日志進(jìn)行組裝，就可以還原出該次請(qǐng)求的鏈路軌跡，如下圖所示。

分布式鏈路追蹤實(shí)現(xiàn)請(qǐng)求回溯的關(guān)鍵點(diǎn)有兩個(gè)：一是低成本、高質(zhì)量的觀察點(diǎn)設(shè)置，也就是鏈路插樁，確保我們追蹤的信息足夠豐富，能夠快速定位異常根因；二是保證鏈路上下文在不同環(huán)境下都能夠完整透?jìng)鳎苊獬霈F(xiàn)上下文丟失導(dǎo)致的斷鏈現(xiàn)象。關(guān)于鏈路插樁和上下文透?jìng)鞯木唧w內(nèi)容我們將在實(shí)戰(zhàn)篇進(jìn)行詳細(xì)介紹。下面，我們來(lái)看一個(gè)高速公路例子，進(jìn)一步加深對(duì)鏈路追蹤實(shí)現(xiàn)原理的認(rèn)識(shí)。

一輛汽車(chē)飛馳在高速公路上

小明、小紅、小玉計(jì)劃在“五一”期間去自駕游，他們的旅游路線各不相同。如果我們想追蹤他們的行程軌跡與時(shí)間該如何實(shí)現(xiàn)？

可能你會(huì)建議在每輛車(chē)上安裝一個(gè)追蹤器。確實(shí)，這是一種行之有效的方法。但當(dāng)出行車(chē)輛擴(kuò)展到全國(guó)數(shù)以十億計(jì)的規(guī)模，安裝追蹤器成本就會(huì)很高。此時(shí)我們換個(gè)角度思考，高速公路的路線是固定的，每隔一段距離就會(huì)有一個(gè)收費(fèi)站，如果我們?cè)诿總€(gè)收費(fèi)站上安裝監(jiān)控，記錄車(chē)輛在每個(gè)收費(fèi)站的軌跡與時(shí)間，就可以很經(jīng)濟(jì)的實(shí)現(xiàn)車(chē)輛軌跡與行駛時(shí)間的追蹤。最終，我們得到了如下行程記錄：

如果我們將每個(gè)游客替換為服務(wù)請(qǐng)求，收費(fèi)站替換為服務(wù)接口，那我們就可以得到每次請(qǐng)求在分布式系統(tǒng)中的調(diào)用軌跡與狀態(tài)，這就是分布式鏈路追蹤的含義。

基礎(chǔ)術(shù)語(yǔ)

雖然分布式鏈路追蹤的實(shí)現(xiàn)方式多種多樣，不同開(kāi)源或商業(yè)化產(chǎn)品都有自己的數(shù)據(jù)模型和定義。但是仍然有一些基礎(chǔ)術(shù)語(yǔ)在業(yè)界具備廣泛的共識(shí)，以 OpenTracing 為例。

Trace

一條 Trace 代表一次入口請(qǐng)求在 IT 系統(tǒng)內(nèi)的完整調(diào)用軌跡及其關(guān)聯(lián)數(shù)據(jù)集合。其中，全局唯一的鏈路標(biāo)識(shí) TraceId，是最具代表的一個(gè)屬性。通過(guò) TraceId 我們才能將同一個(gè)請(qǐng)求分散在不同節(jié)點(diǎn)的鏈路數(shù)據(jù)準(zhǔn)確的關(guān)聯(lián)起來(lái)，實(shí)現(xiàn)請(qǐng)求粒度的“確定性關(guān)聯(lián)”價(jià)值。這也是 Trace 區(qū)別于 Metrics、Log 其他兩類(lèi)可觀測(cè)技術(shù)的關(guān)鍵屬性。

Span

光有 TraceId 還不夠，請(qǐng)求在每一跳的接口方法上執(zhí)行了什么動(dòng)作，耗時(shí)多久，執(zhí)行狀態(tài)是成功還是失?。砍休d這些信息的基礎(chǔ)對(duì)象就是 Span。通常一個(gè)完整的 Span 具有如下屬性：

• Operation Name：描述了當(dāng)前接口的行為語(yǔ)義，比如 /api/createOrder 代表執(zhí)行了一次創(chuàng)建訂單的動(dòng)作。

• SpanId/ParentSpanId：接口調(diào)用的層級(jí)標(biāo)識(shí)，用于還原 Trace 內(nèi)部的層次調(diào)用關(guān)系。

• Start/FinishTime：接口調(diào)用的開(kāi)始和結(jié)束時(shí)間，二者相減就是該次調(diào)用的耗時(shí)。

• StatusCode：響應(yīng)狀態(tài)，標(biāo)識(shí)當(dāng)次調(diào)用是成功或失敗。

• Tags & Events：調(diào)用附加信息，詳見(jiàn)下面的描述。

Tags

SpanName 的描述通常是高度抽象的，僅僅回答這個(gè)接口是做什么的。如果需要進(jìn)一步記錄請(qǐng)求的行為特征，可以使用 Tags 來(lái)擴(kuò)展語(yǔ)義。Tags 是一組由 {Key:Value} 組成的鍵值對(duì)集合，描述這一次接口調(diào)用的具體屬性，比如將 UserType 添加到 Tags 中，就可以觀察某一類(lèi)用戶(hù)（比如 VIP 用戶(hù)）的鏈路行為狀態(tài)。如果將設(shè)備類(lèi)型加到 Tags 中，可以對(duì)比不同設(shè)備的性能差異。

由于 Tags 只支持結(jié)構(gòu)化的 KV 鍵值對(duì)，因此，它可以作為標(biāo)簽添加到聚合后的鏈路指標(biāo)中，有效提升監(jiān)控告警的數(shù)據(jù)精度。更準(zhǔn)確的回答異常或性能問(wèn)題發(fā)生的原因，比如集中在某個(gè)地域、設(shè)備或版本。

Logs

Tags 會(huì)隨著鏈路上下文自動(dòng)向下游透?jìng)鳎绻Ｍ涗浺恍┎恍枰競(jìng)鞯氖录畔?，可以使?Logs 字段。每個(gè) Span 都可以進(jìn)行多次 Logs 操作，但每個(gè) Logs 對(duì)象都需要帶有一個(gè)時(shí)間戳，Logs 的內(nèi)容可以是非結(jié)構(gòu)化的復(fù)雜對(duì)象。為了節(jié)省成本，一般不會(huì)對(duì) Logs 字段建立索引，也不支持 Logs 的查詢(xún)或統(tǒng)計(jì)，僅僅作為附加信息關(guān)聯(lián)在調(diào)用鏈上，用于單請(qǐng)求診斷。

下圖展示了一個(gè) OpenTracing 的 Span 示例，不同開(kāi)源實(shí)現(xiàn)的鏈路模型我們將在后續(xù)章節(jié)再展開(kāi)介紹。

分布式鏈路追蹤已經(jīng)被廣泛應(yīng)用于中大型企業(yè)的 IT 運(yùn)維領(lǐng)域，為分布式應(yīng)用的性能診斷與穩(wěn)定性保障提供了有效的幫助。此外，分布式鏈路追蹤的開(kāi)源和商業(yè)化生態(tài)也發(fā)展迅猛，大量獨(dú)立服務(wù)商或云廠商紛紛跟進(jìn)，共同推動(dòng)了分布式鏈路追蹤技術(shù)的崛起。

3.分布式鏈路追蹤的應(yīng)用

狹義上分布式鏈路追蹤（Tracing）是指跟蹤請(qǐng)求在分布式系統(tǒng)中的流轉(zhuǎn)路徑與狀態(tài)，主要用途是協(xié)助開(kāi)發(fā)運(yùn)維人員進(jìn)行故障診斷、容量預(yù)估、性能瓶頸分析與調(diào)用鏈路梳理等工作。技術(shù)實(shí)現(xiàn)上包含了數(shù)據(jù)埋點(diǎn)、采集、存儲(chǔ)、分析、可視化等環(huán)節(jié)，形成了一套完整的技術(shù)體系。

而更廣義的分布式鏈路追蹤，則涵蓋了由數(shù)據(jù)透?jìng)髂芰ρ苌纳鷳B(tài)系統(tǒng)，比如全鏈路壓測(cè)、微服務(wù)流量路由、業(yè)務(wù)場(chǎng)景鏈路拆分等。我們可以為調(diào)用鏈路賦予業(yè)務(wù)語(yǔ)義，也可以將一次調(diào)用生命周期內(nèi)的所有數(shù)據(jù)進(jìn)行關(guān)聯(lián)整合，不再局限于鏈路數(shù)據(jù)本身。

由此可見(jiàn)，分布式鏈路追蹤的應(yīng)用場(chǎng)景廣闊，潛力巨大，它的核心屬性就是“關(guān)聯(lián)”。然而，分布式鏈路追蹤（Tracing）相對(duì)于統(tǒng)計(jì)指標(biāo)（Metrics）和應(yīng)用日志（Logging）來(lái)說(shuō)更加難以理解，不容易運(yùn)用，更難用好。接下來(lái)，我們通過(guò)一個(gè)生動(dòng)形象的例子，了解下分布式鏈路追蹤的經(jīng)典用法，加深對(duì)它的技術(shù)本質(zhì)的掌握。

游客、收費(fèi)站和交通局

分布式鏈路追蹤的用法有很多，但最經(jīng)典、最常用的有三種，還是以上一節(jié)的高速公路為例，不同角色對(duì)應(yīng)著不同的用法。

• 游客，只關(guān)心自身的行程路線，需要途經(jīng)哪些收費(fèi)站點(diǎn)？行駛時(shí)間有多長(zhǎng)？沿途是否有擁堵或危險(xiǎn)路段等。

• 收費(fèi)站，只關(guān)心自身站點(diǎn)的狀態(tài)，比如站點(diǎn)吞吐量、平均過(guò)閘時(shí)間等，以便于提前安排檢票口值班人數(shù)。

• 交通局，會(huì)將所有的出行記錄匯總，提前估算整個(gè)高速公路網(wǎng)的出行流量、易擁堵路段、事故多發(fā)路段等，以便于提前疏通或加固問(wèn)題路段，并給出合理的建議出行路線，有時(shí)還需要提前制定車(chē)輛限流策略等。

分布式鏈路追蹤的應(yīng)用和行程軌跡追蹤類(lèi)似，游客關(guān)心的是單次請(qǐng)求的軌跡回溯，收費(fèi)站關(guān)注的是服務(wù)接口維度的匯總統(tǒng)計(jì)，旅游局則類(lèi)似全局鏈路拓?fù)涫崂怼?/p>

單請(qǐng)求軌跡回溯

單請(qǐng)求軌跡回溯是分布式鏈路追蹤最基礎(chǔ)的功能，它記錄了一次請(qǐng)求經(jīng)過(guò)的所有服務(wù)節(jié)點(diǎn)以及對(duì)應(yīng)的節(jié)點(diǎn)狀態(tài)信息（接口名稱(chēng)、耗時(shí)、狀態(tài)碼等），這就好比記錄了游客自駕游時(shí)經(jīng)過(guò)的所有收費(fèi)站，以及沿途的路況與行駛時(shí)間等信息。單請(qǐng)求軌跡回溯是診斷特定請(qǐng)求異常/超時(shí)原因的有效手段，可以快速定位異常節(jié)點(diǎn)（擁堵的收費(fèi)站）。

比較成熟的 Tracing 產(chǎn)品（比如阿里云的應(yīng)用實(shí)時(shí)監(jiān)控服務(wù)?ARMS）除了基礎(chǔ)的鏈路數(shù)據(jù)外，還會(huì)記錄請(qǐng)求出入?yún)?、本地方法棧、關(guān)聯(lián) SQL 與異常堆棧等信息。這些細(xì)節(jié)信息就好比車(chē)輛的型號(hào)大小、駕駛員駕齡、是否醉酒、沿途每一路段的詳細(xì)路況等，當(dāng)調(diào)用不符合預(yù)期（行程異常）時(shí)，就可以精準(zhǔn)的定位根因，如下圖所示：

ARMS：

https://help.aliyun.com/document_detail/64995.html

服務(wù)監(jiān)控

假如你是收費(fèi)站的站長(zhǎng)，你會(huì)關(guān)注哪些信息？收費(fèi)站的車(chē)輛吞吐量？平均的過(guò)閘時(shí)間？車(chē)輛的來(lái)源與去向？同理，每一個(gè)服務(wù)節(jié)點(diǎn)，將途經(jīng)的所有調(diào)用信息匯總后，就可以得到當(dāng)前服務(wù)接口的吞吐量、耗時(shí)、來(lái)源與去向等統(tǒng)計(jì)指標(biāo)。這些指標(biāo)可以幫助我們快速識(shí)別當(dāng)前服務(wù)的健康狀態(tài)。在實(shí)際生產(chǎn)系統(tǒng)中，還可以與告警系統(tǒng)結(jié)合，實(shí)現(xiàn)風(fēng)險(xiǎn)的快速識(shí)別與處理，降低業(yè)務(wù)損失。

鏈路拓?fù)?/span>

假如你是交通局的局長(zhǎng)，你可能會(huì)關(guān)注全國(guó)高速公路網(wǎng)的整體運(yùn)行狀態(tài)，有哪些易擁堵或事故多發(fā)路段與站點(diǎn)，如何確保春運(yùn)高峰期核心路段運(yùn)行通暢，不會(huì)出現(xiàn)重大交通癱瘓事件等等。此時(shí)，你需要對(duì)所有的車(chē)輛行程軌跡進(jìn)行匯總分析。

同理，鏈路拓?fù)渚褪菍⑷只蚰骋蝗肟诜?wù)的所有調(diào)用鏈路進(jìn)行匯總，聚合為鏈路拓?fù)浯髨D，進(jìn)而分析當(dāng)前鏈路的性能瓶頸點(diǎn)、易故障點(diǎn)等，提前進(jìn)行性能優(yōu)化或風(fēng)險(xiǎn)防控，還可以根據(jù)歷史流量來(lái)指導(dǎo)未來(lái)（比如雙 11 大促）的容量評(píng)估。

分布式鏈路追蹤的發(fā)展現(xiàn)狀

截止到 2021年，分布式鏈路追蹤（Tracing）已經(jīng)成為主流軟件架構(gòu)不可或缺的基礎(chǔ)技術(shù)之一，它與指標(biāo)（Metrics）、日志（Logging）并稱(chēng)為可觀測(cè)領(lǐng)域的“三駕馬車(chē)”，它們?nèi)咧g的關(guān)系如下圖所示：

隨著 Kubenetes 容器技術(shù)與云計(jì)算的普及，未來(lái)的軟件架構(gòu)會(huì)更加趨向分布式云、微服務(wù)化的方向，軟件開(kāi)發(fā)、部署成本將大幅下降，但是系統(tǒng)維護(hù)和問(wèn)題診斷的難度卻急劇上升。因此，分布式鏈路追蹤以及由它提供的“確定性關(guān)聯(lián)”價(jià)值將愈加凸顯，如下圖所示：

Tracing 在開(kāi)源社區(qū)也頗受喜愛(ài)，擁有著旺盛的生命力，主流的開(kāi)源標(biāo)準(zhǔn)包括 OpenTelemetry、OpenTracing、OpenCensus 和國(guó)內(nèi)使用較多的 SkyWalking。其他影響力較強(qiáng)的實(shí)現(xiàn)還包括 Jaeger、Zipkin、Pinpoint 等，如下圖所示。

在商業(yè)化領(lǐng)域，Tracing 與 APM（Application Performance Mornitoring） 密切綁定，絕大部分廠商會(huì)面向應(yīng)用視角提供更加全面、易用的 APM 服務(wù)，而不僅僅是 Tracing 服務(wù)。參考 2021 年 Gartner 評(píng)測(cè)機(jī)構(gòu)給出的 APM 魔力象限，可以大致評(píng)估各大廠商的 APM 與 Tracing 產(chǎn)品能力，如下圖所示。

截止 2021年，阿里巴巴 98% 的 Java 應(yīng)用（上萬(wàn)級(jí)別）均已接入內(nèi)部自研的分布式鏈路追蹤系統(tǒng) EagleEye；阿里云上有近萬(wàn)家企業(yè)在持續(xù)使用 ARMS 提供的分布式鏈路追蹤服務(wù)。而從整個(gè)業(yè)界來(lái)看，無(wú)論是谷歌、亞馬遜這樣的國(guó)際大廠，還是新興的互聯(lián)網(wǎng)公司，或是傳統(tǒng)企業(yè)，都在大規(guī)模接入和應(yīng)用分布式鏈路追蹤技術(shù)，Tracing 生態(tài)正在蓬勃發(fā)展。

4.分布式鏈路追蹤的挑戰(zhàn)與限制

作為一門(mén)“新”技術(shù)，分布式鏈路追蹤的技術(shù)演進(jìn)史并不算長(zhǎng)，僅有十?dāng)?shù)年。目前，它仍處于不斷被探索、快速迭代的周期。為了更好的了解與應(yīng)用分布式鏈路追蹤技術(shù)，我們來(lái)看下它目前面臨的幾項(xiàng)關(guān)鍵挑戰(zhàn)與限制。

關(guān)鍵挑戰(zhàn)與應(yīng)對(duì)

分布式鏈路追蹤技術(shù)從誕生到大規(guī)模應(yīng)用，中間經(jīng)歷了一段較長(zhǎng)的蟄伏期，直到近幾年才逐漸被大家廣泛接受和認(rèn)可。影響其快速推廣的關(guān)鍵挑戰(zhàn)包括如下幾點(diǎn)：

• 前期建設(shè)成本高

無(wú)論是在不同組件接口上進(jìn)行插樁埋點(diǎn)，還是保證鏈路上下文能夠正確傳播，亦或是搭建一套穩(wěn)定可靠的鏈路數(shù)據(jù)后端處理系統(tǒng)，都不是一件易事，需要投入大量的研發(fā)人力。

• 數(shù)據(jù)處理成本高

由于鏈路數(shù)據(jù)與請(qǐng)求流量成正比，每一次請(qǐng)求都會(huì)記錄相應(yīng)的鏈路日志，當(dāng)系統(tǒng)流量爆炸式增長(zhǎng)，相應(yīng)的鏈路數(shù)據(jù)生成、采集、處理、存儲(chǔ)、查詢(xún)的成本也會(huì)急劇上升，帶來(lái)巨大的 IT 資源開(kāi)銷(xiāo)。

• 價(jià)值沒(méi)有得到普遍認(rèn)可

基礎(chǔ)的鏈路數(shù)據(jù)僅僅表達(dá)了接口間的調(diào)用依賴(lài)，沒(méi)有釋放足夠的業(yè)務(wù)價(jià)值，難以得到領(lǐng)導(dǎo)和同事們的全力支持。

• 鏈路標(biāo)準(zhǔn)不統(tǒng)一

分布式鏈路追蹤發(fā)展前期沒(méi)有統(tǒng)一的業(yè)界標(biāo)準(zhǔn)，各家廠商百花齊放，雖然一定程度上促進(jìn) Tracing 技術(shù)的多元化探索，但也為鏈路融合、遷移和推廣帶來(lái)了巨大的挑戰(zhàn)。

當(dāng)然，挑戰(zhàn)同樣也是機(jī)遇，為了應(yīng)對(duì)上述問(wèn)題，分布式鏈路追蹤近幾年實(shí)現(xiàn)了如下技術(shù)突破：

• 無(wú)侵入探針 + 一體化解決方案

類(lèi)似 JavaAgent 的探針插樁技術(shù)，實(shí)現(xiàn)了 0 代碼入侵，0 改造成本的鏈路自動(dòng)埋點(diǎn)，而類(lèi)似 SkyWalking 的開(kāi)源實(shí)現(xiàn)還提供了端到端的一體化解決方案，從鏈路數(shù)據(jù)生成到最后的可視化，中小企業(yè)可以快速搭建并享受到分布式鏈路追蹤技術(shù)的價(jià)值，大幅降低了 Tracing 的前期建設(shè)成本和接入門(mén)檻。

• 鏈路采樣 + 邊緣計(jì)算

鏈路采樣策略，例如固定比例采樣、限流采樣、錯(cuò)慢全采、自定義標(biāo)簽采樣等，可以大幅降低鏈路數(shù)據(jù)的傳輸、處理、存儲(chǔ)成本；結(jié)合用戶(hù)網(wǎng)絡(luò)內(nèi)的指標(biāo)聚合，長(zhǎng)文本編碼/壓縮等邊緣計(jì)算技術(shù)，可以合理控制分布式鏈路追蹤的數(shù)據(jù)成本，保障鏈路系統(tǒng)持續(xù)健康運(yùn)轉(zhuǎn)。

• 關(guān)聯(lián)分析 + 立體化可觀測(cè)

單條鏈路的價(jià)值難以凸顯，但是基于成千上萬(wàn)條鏈路的聚合/關(guān)聯(lián)分析卻能快速定位，導(dǎo)致系統(tǒng)異常的關(guān)鍵因素，比如版本、地域、用戶(hù)類(lèi)型等。同時(shí)，結(jié)合業(yè)務(wù)、容器、基礎(chǔ)設(shè)施等其他層面的可觀測(cè)數(shù)據(jù)，建立一套端到端、立體化的可觀測(cè)體系，能夠更加有效地釋放分布式鏈路追蹤的技術(shù)價(jià)值。

• 開(kāi)源標(biāo)準(zhǔn)趨向統(tǒng)一

自從 2019 年 OpenTelemetry 開(kāi)源立項(xiàng)，得到了兩大主流開(kāi)源實(shí)現(xiàn) OpenTracing 和 OpenCensus 的大力支持，開(kāi)啟了可觀測(cè)性的新時(shí)代。雖然，目前 OpenTelemetry 僅在 Tracing 領(lǐng)域擁有比較完善的技術(shù)標(biāo)準(zhǔn)，Metrics 和 Logging 仍在探索階段，但是可觀測(cè)性“三駕馬車(chē)”融合一統(tǒng)的趨勢(shì)已經(jīng)勢(shì)不可擋。未來(lái)基于統(tǒng)一完善的可觀測(cè)數(shù)據(jù)標(biāo)準(zhǔn)，分布式鏈路追蹤的“確定性關(guān)聯(lián)”將得到更加廣泛的應(yīng)用。

現(xiàn)階段能力限制

分布式鏈路追蹤現(xiàn)有的模型設(shè)計(jì)與實(shí)現(xiàn)，可以有效滿(mǎn)足許多經(jīng)典場(chǎng)景的分布式診斷訴求。但是，仍然有大量場(chǎng)景超出了現(xiàn)階段分布式鏈路追蹤的能力范疇，需要我們?nèi)ヌ剿鞲玫姆桨浮?/p>

樹(shù)形 YES！圖形 NO！

前文介紹了分布式鏈路追蹤是通過(guò) ParentSpanId 和 SpanId 來(lái)標(biāo)識(shí)依賴(lài)關(guān)系，從而準(zhǔn)確還原鏈路層級(jí)與順序。但是，每個(gè) Span 有且僅有一個(gè) ParentSpanId，這就限制了所有鏈路形態(tài)只能是單個(gè)父節(jié)點(diǎn)的樹(shù)形結(jié)構(gòu)，而不能是多個(gè)父節(jié)點(diǎn)的圖形結(jié)構(gòu)。

某些系統(tǒng)為了提供重復(fù)調(diào)用的效率，會(huì)將多次 RPC 調(diào)用打包成一次 RPC 調(diào)用合并發(fā)送，這種入度大于1的圖形結(jié)構(gòu)，就無(wú)法通過(guò)調(diào)用鏈真實(shí)還原調(diào)用狀態(tài)，而是會(huì)被拆成多條調(diào)用鏈，如下圖所示：

人工插樁 YES！智能插樁 NO！

無(wú)論是 SDK 或是 Agent 模式，目前工業(yè)界的鏈路插樁主要是依賴(lài)人工發(fā)現(xiàn)插樁點(diǎn)并實(shí)現(xiàn)插樁過(guò)程，很難通過(guò)算法自適應(yīng)的實(shí)現(xiàn)插樁點(diǎn)的智能發(fā)現(xiàn)。然而，學(xué)術(shù)界在這方面已經(jīng)進(jìn)行了一些有意思的探索，雖然在性能開(kāi)銷(xiāo)、安全等方面還不夠成熟，但是值得關(guān)注。

2019 年波士頓大學(xué)發(fā)表了一篇研究智能插樁的文章，他們實(shí)現(xiàn)的 Pythia 原型系統(tǒng)針對(duì)性能退化問(wèn)題，可以自動(dòng)發(fā)現(xiàn)更有價(jià)值的內(nèi)部插樁點(diǎn)。例如，我們?cè)谡?qǐng)求一個(gè)存儲(chǔ)系統(tǒng)時(shí)，可能會(huì)直接命中緩存快速返回結(jié)果，也可能未命中緩存導(dǎo)致加載磁盤(pán)花費(fèi)了較多時(shí)間。我們僅在 RPC 層面進(jìn)行插樁，只能看到請(qǐng)求耗時(shí)高低起伏，呈現(xiàn)一種雙峰式的分布，但無(wú)法確認(rèn)根因是什么。Pythia 通過(guò)比對(duì)分析不同的鏈路數(shù)據(jù)，會(huì)自動(dòng)發(fā)現(xiàn)影響性能的潛在插樁點(diǎn)，比如慢請(qǐng)求可能會(huì)額外調(diào)用一次 fetchFromDisk 方法，從而更清晰的解釋影響請(qǐng)求耗時(shí)的根因，如下圖所示。

分布式鏈路追蹤的能力限制遠(yuǎn)不止以上兩種場(chǎng)景，在離線分析、機(jī)器學(xué)習(xí)等多個(gè)領(lǐng)域也等待我們?nèi)ヌ剿鞴タ?。我們既要充分發(fā)揮現(xiàn)有的分布式鏈路追蹤技術(shù)價(jià)值，解決當(dāng)下的企業(yè)運(yùn)維困難；同時(shí)也要把視野放寬，在未來(lái)更多的領(lǐng)域中去拓展分布式鏈路追蹤的邊界。