螞蟻金服分散式鏈路跟蹤元件鏈路透傳原理與SLF4J MDC的擴充套件能力分析 | 剖析

slf4j 分散式系統 · 發表 2019-01-24 13:44:05

摘要： SOFA S calable O pen F inancial A rchitecture 是螞蟻金服自主研發的金融級分散式中介軟體，包含了構建金融級雲原生架構所需的各個元件，是在金融場景裡錘鍊出來的最佳實踐。 SOFATracer 是一個用於分散式系統呼叫跟...

SOFA

S calable O pen F inancial A rchitecture

是螞蟻金服自主研發的金融級分散式中介軟體，包含了構建金融級雲原生架構所需的各個元件，是在金融場景裡錘鍊出來的最佳實踐。

SOFATracer 是一個用於分散式系統呼叫跟蹤的元件，通過統一的 TraceId 將呼叫鏈路中的各種網路呼叫情況以日誌的方式記錄下來，以達到透視化網路呼叫的目的，這些鏈路資料可用於故障的快速發現，服務治理等。

本文為《剖析 | SOFATracer 框架》第三篇，本篇作者J.Queue，來自端點科技。《剖析 | SOFATracer 框架》系列由 SOFA 團隊和原始碼愛好者們出品，專案代號：<SOFA:TracerLab/> ，目前領取已經完成，感謝大家的參與。

SOFATracer：

https:// github.com/alipay/sofa- tracer

SOFATracer 是一個用於分散式系統呼叫跟蹤的元件，其核心作用就是能夠在分散式場景下將請求經過的各個的鏈路環節的相關資料記錄下來，通過這些資料將各個呼叫鏈路相關的元件串聯起來。

在日常的開發中，我們除了跟蹤鏈路外，可能還會遇到一些場景：

例如線上壓測，我們在已有的系統的中，模擬一些請求（壓測流量）對我們的系統進行壓力測試，那麼在整個鏈路中我們是如何讓所有的系統都識別出當前的請求是壓測流量而不是正式流量的呢？壓測流量的標記又是如何在整個鏈路傳遞的呢？

又例如我們已經有了鏈路資料分析能力，能夠快速定位到某個請求是在 A 系統裡出的問題，那麼我們怎麼從 A 系統的業務日誌裡找到當前請求對應的業務日誌呢？

帶著這些問題，讓我們先來看看 SOFATracer 的鏈路透傳以及支援 SLF4J MDC 擴充套件能力。

SOFATracer 鏈路透傳原理

SOFATracer 的鏈路透傳具體包括兩個點：

跨程序的透傳，即如何將鏈路資料從一個程序傳遞到下游程序中
程序內的透傳

當前請求跨程序呼叫結束之後，當前如何恢復 tracer 上下文資訊
如何實現跨執行緒的透傳，如在當前執行緒中起一個非同步執行緒的場景

跨程序鏈路透傳原理

跨程序透傳就是將上游系統的鏈路資料透傳到下游系統中，以便於提取出全域性的鏈路標記，如 TracerId 、取樣標記等，來實現將服務串聯起來並且保持傳輸過程中某些屬性的一致性。SOFATracer 基於 Opentracing 規範實現，因此在鏈路透傳部分，也是基於此規範；下面就先從 Opentracing 規範中的透傳開始說起。

Opentracing 中的定義

在 OT 原文有這麼一段描述，傳送門：

Programmers adding tracing support across process boundaries must understand the Tracer.Inject(...) and Tracer.Extract(...) capabilities of the OpenTracing specification . They are conceptually powerful, allowing the programmer to write correctand general cross-process propagation code without being bound to a particular OpenTracing implementation ; that said, with great power comes great opportunity for confusion.

大概意思就是：如果開發者要給應用新增跨程序的追蹤能力, 首先要理解 OpenTracing 規範中的 Tracer.Inject(...) 和 Tracer.Extract(…) 的功能。它們在概念抽象上非常強大，而且允許開發者編寫正確的、通用的跨程序傳輸的程式碼，而不需要繫結到特定的 OpenTracing 實現上去。

總的來說就是 Opentracing 的 Tracer 介面定義了跨程序的能力，但是就是沒具體實現，不同的基於此規範實現的元件，需要遵循此規範來實現具體的透傳邏輯，下面是 Tracer 介面定義的用於透傳的兩個方法：

程序透傳實現分析

SOFATracer 的 Tracer 的實現類是 SofaTracer， UML 圖如下：

從圖中可以看出 SofaTracer 除了有跨程序傳輸的能力，還擴充套件了資料上報的能力( Reporter )和取樣能力( Sampler )。資料上報能力可以參考 SOFATracer 資料上報機制和原始碼分析|剖析這篇文章；取樣將在下一篇文章中進行剖析。

跨程序透傳的就是 SpanContext 的內容， carrier 為傳輸的載體， SpanContext 的實現類為 SofaTracerSpanContext， UML 圖：

跨程序透傳處理流程

SOFATracer 中跨程序傳輸的總體流程如下圖所示：

透傳原理的實質就是： 呼叫方編碼將指定內容傳輸到被調方，被調方解碼獲取內容的過程。

跨程序透傳的方式有很多，在這裡以客戶端向服務端發起 HTTP 請求的方式來演示跨程序傳輸， fork 程式碼，開啟 sample/tracer-sample-with-httpclient 示例工程執行 HttpClientDemoApplication ，開啟 logs/tracelog/spring-mvc-stat.log 即可看到鏈路日誌，執行結果：

{"time":"2019-01-07 19:42:50.134","stat.key":{"method":"GET","local.app":"HttpClientDemo","request.url":"http://localhost:8080/httpclient"},"count":1,"total.cost.milliseconds":1563,"success":"true","load.test":"F"}
{"time":"2019-01-07 20:09:46.285","stat.key":{"method":"GET","local.app":"HttpClientDemo","request.url":"http://localhost:8080/httpclient"},"count":1,"total.cost.milliseconds":71,"success":"true","load.test":"F"}
{"time":"2019-01-07 20:14:52.628","stat.key":{"method":"GET","local.app":"HttpClientDemo","request.url":"http://localhost:8080/httpclient"},"count":2,"total.cost.milliseconds":111,"success":"true","load.test":"F"}

透傳鏈路如下：

1、客戶端

首先找到客戶端攔截的入口類

com.alipay.sofa.tracer.plugins.httpclient.interceptor.SofaTracerHttpInterceptor

& com.alipay.sofa.tracer.plugins.httpclient.interceptor.SofaTracerAsyncHttpInterceptor

以 SofaTracerHttpInterceptor 為例:

// 攔截請求
 public void process(HttpRequest httpRequest, HttpContext httpContext) throws HttpException, IOException {
//lazy init
 RequestLine requestLine = httpRequest.getRequestLine();
 String methodName = requestLine.getMethod();
 // 生成SpanContext和Span
 SofaTracerSpan httpClientSpan = httpClientTracer.clientSend(methodName);
// 把 SpanContext inject到Carrier中
 super.appendHttpClientRequestSpanTags(httpRequest, httpClientSpan);
}

生成 Span 的最後一步是

com.alipay.common.tracer.core.SofaTracer.SofaTracerSpanBuilder#start

public Span start() {
 SofaTracerSpanContext sofaTracerSpanContext = null;
 // 判斷當前Span是否為鏈路中的root節點, 如果不是則建立子Span上下文, 否則建立一個RootSpan上下文
 if (this.references != null && this.references.size() > 0) {
sofaTracerSpanContext = this.createChildContext();
} else {
sofaTracerSpanContext = this.createRootSpanContext();
}
 long begin = this.startTime > 0 ? this.startTime : System.currentTimeMillis();
 // 構建Span
 SofaTracerSpan sofaTracerSpan = new SofaTracerSpan(SofaTracer.this, begin,

 this.references, this.operationName, sofaTracerSpanContext, this.tags);
 // 取樣行為計算
 boolean isSampled = calculateSampler(sofaTracerSpan);
sofaTracerSpanContext.setSampled(isSampled);
 return sofaTracerSpan;
}

最後就是把 SpanContext 注入到 Carrier 中以 HTTP HEAD 的方式透傳到下游。

關於資料注入載體和從載體中提取資料可以參考

2、服務端

找到服務端的攔截入口 SpringMvcSofaTracerFilter ，功能很簡單：

獲取上游傳來的 SpanContext
構建服務端的 Span，在這裡和客戶端做了同樣的判斷，判斷當前 Span 是否為 RootSpan，這個操作很重要，如果是 RootSpan 則意味著一條新的鏈路要被構建；如果不是 RootSpan ，則會將當前服產生的 Span 通過 tracerId 關聯到當前鏈路中來。

執行緒透傳原理

在介紹執行緒透傳原理之前先來看個例子；對於 MVC 元件來說，如果我們想使用一個 Span 來記錄 mvc 的執行過程。一般我可以把 Span 的開始放在 Filter 中，filterChain.doFilter 方法執行之前產生，然後再 finally 塊中來結束這個 Span，大概如下：

 // Span span = null//1
try{
 // to create a new span
span = serverReceive()
 // do something
filterChain.doFilter(servletRequest, responseWrapper);
 // do something
 }finally{
 // to finish current span
serverSend();
 }

假如現在有個問題是，在 serverReceive 和 serverSend 這段過程中涉及到了其他元件也產生了 Span，比如說發起了一次 httpclient 呼叫。大概對應的 tracer 如下：

|mvcSpan|
.
|httpclientSpan|
...
|httpclientSpan|
.

|mvcSpan|

這是典型的 childof 關係， httpclientSpan 、 childof mvcSpan 且都在同一個執行緒中執行。OK，解法：

顯示的申明一個 Span ，如上面程式碼段中 1 的位置。這樣 Span 的作用域足夠大，可以在 finally 中通過顯示呼叫 span#finish 來結束。
使用 ThreadLocal 機制，在 serverReceive 中將當前 Span 放到 ThreadLocal 中，httpclientSpan 作用時，從 ThreadLocal 中先拿出 mvcSpan，然後作為 httpclientSpan 的父 Span 。此時將 httpclientSpan 塞到 ThreadLocal 中。當 httpclientSpan 結束時，再將 mvcSpan 復原到 ThreadLocal 中。

對於解法1 ，如果想在 httpclientSpan 的處理邏輯中使用 mvcSpan 怎麼辦呢？通過引數傳遞？那如果鏈路很長呢？顯然這種方式是不可取的。因此 SOFATracer 在實現上是基於解法2 的方案來實現的。

綜合上面的案例，執行緒透傳可以從以下兩個角度來理解：

當前執行緒中如果發生了跨程序呼叫(如 RPC 呼叫)，那麼跨程序呼叫結束之後如何恢復 Tracer 上下文資訊
當前執行緒執行過程中，又起了非同步執行緒來執行一些子任務(如任務排程)，如何將當前執行緒 Tracer 上下文傳遞到子執行緒中

下面就針對這兩個問題，來分析下 SOFATracer 的執行緒透傳實現。

執行緒透傳實現分析

在 SOFATracer 中定義了一個 SofaTraceContext 介面，允許應用程式訪問和操縱當前 Span 的狀態，預設實現是 SofaTracerThreadLocalTraceContext； UML 圖：

SofaTracerThreadLocalTraceContext 實際上就是使用了 ThreadLocal 來儲存當前執行緒 Tracer 上下文資訊的。下面以 AbstractTracer#serverReceive 程式碼片段來看下 SOFATracer 中存入 Span 的邏輯：

public SofaTracerSpan serverReceive(SofaTracerSpanContext sofaTracerSpanContext) {
 // 省略 ...
 SofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext();
 try {
 // ThreadLocal 初始化, 存入當前的Span
sofaTraceContext.push(sofaTracerSpanServer);
} catch (Throwable throwable) {
 // 省略 ...
} finally {
 // 省略 ...
}
 return sofaTracerSpanServer;
}

通過 SofaTraceContextHolder 或到 SofaTraceContext 的例項物件，本質上就是 SofaTracerThreadLocalTraceContext 的單例物件
將當前 Span 放入到
SofaTracerThreadLocalTraceContext，也就是存入 ThreadLocal 中

如果在後面的業務處理過程中需要用到此 Span ，那麼就可以通過SofaTraceContextHolder.getSofaTraceContext().getCurrentSpan() 這樣簡單的方式獲取到當前 Span 。

那麼既然是通過 ThreadLocal 來進行 tracer 上下文的儲存，為了保證 ThreadLocal 不被汙染，同時防止記憶體洩漏，需要在當前 Span 結束時清理掉當前執行緒上下文中的資料。下面通過 AbstractTracer#serverSend 程式碼片段來看下 SOFATracer 中清理執行緒上下文中透傳資料的邏輯：

public void serverSend(String resultCode) {

 try {
 // 或取當前 SofaTraceContext 例項
 SofaTraceContext sofaTraceContext = SofaTraceContextHolder.getSofaTraceContext();
 // 取出 span 資訊，這裡相當於就是恢復 tracer上下文狀態資訊
 SofaTracerSpan serverSpan = sofaTraceContext.pop();
 if (serverSpan == null) {
 return;
 //log

serverSpan.log(LogData.SERVER_SEND_EVENT_VALUE);
 // 結果碼
serverSpan.setTag(CommonSpanTags.RESULT_CODE, resultCode);
serverSpan.finish();
} finally {
 //處理完成要清空 TL
 this.clearTreadLocalContext();
}
}

所以在整個執行緒處理過程中，SOFATracer 在 tracer 上下文處理上均是基於 Threadlocal 來完成的。

PS：

SofaTraceContext 中封裝了一系列用於操作 threadlocal 的工具方法，上面提到的 getCurrentSpan 和 pop 的區別在於，getCurrentSpan 從 threadlocal 中取出 Span 資訊之後不會清理，也就是後面還可以通過getCurrentSpan 拿到當前執行緒上下文中的 Span 資料，因此在業務處理過程中，如果需要向 Span 中新增一些鏈路資料，可以通過 getCurrentSpan 方法進行設定。pop 方法與 getCurrentSpan 實際上都是通過 threadlocal#get 來取資料的，當時 pop 取完之後會進行 clear 操作，因此 pop 一般用於在請求結束時使用。

SpringMvcSofaTracerFilter 中在 finally 塊中呼叫了 serverSend ，serverSend 中就是使用的 pop 方法。

跨執行緒透傳

前一小節介紹了 tarcer 上下文如何實現線上程中透傳及恢復，那麼對於另外一種場景，即在當前執行緒處理過程中新起了子執行緒的情況，父執行緒如何將當前 tracer 上下文資訊傳遞到子執行緒中去呢？對於這種情況，SOFATracer 也提供了支援，下面就來看下，SOFATracer 是如何實現跨執行緒傳遞的。

跨執行緒傳遞相對於跨進行傳遞來說要簡單的多，我們不需要考慮載體、格式化方式等；無論是父執行緒還是子執行緒，在儲存 tracer 上下文資訊的實現上都是一樣的，都是基於 ThreadLocal 來儲存。但是為了保證當前 tracer 上下文的狀態能夠在不同的執行緒中保持一致，不受干擾，SOFATracer 在將 tracer 上下文傳遞到子執行緒中時，可以選擇使用的是當前父執行緒 tracer 上下文的克隆版本：

public SofaTracerSpanContext cloneInstance() {
 // 重新構建一個 SofaTracerSpanContext 物件例項
 // 這裡會以當前父執行緒中的 tracerId,spanId,parentId以及取樣資訊 作為構建構建引數
 SofaTracerSpanContext spanContext = new SofaTracerSpanContext(this.traceId, this.spanId,
 this.parentId, this.isSampled);
 // 系統透傳資料
spanContext.addSysBaggage(this.sysBaggage);
 // 業務透傳資料
spanContext.addBizBaggage(this.bizBaggage);
spanContext.childContextIndex = this.childContextIndex;
 return spanContext;
}

這裡會根據當前 SofaTracerSpanContext 例項的基本資訊，重新 new 一個新的物件出來，是一種深拷貝的方式，實現了不同執行緒 tracer 上下文處理的隔離。

另外，SOFATracer 還提供了 SofaTracerRunnable&SofaTracerCallable 這兩個類，封裝了底層手動將 Span 複製到被調執行緒的 ThreadLocal 中去的過程；需要注意的是這個傳遞的是 Span ，並非是 SpanContext，因此也就沒有上面隔離一說，具體使用參考官方文件：非同步執行緒處理。這裡以 SofaTracerRunnable 類來進行具體實現分析，SofaTracerCallable 大家可以自己去研究下。

關於非同步執行緒處理的案例，可以參考 SOFATracer 的測試用例。

private void initRunnable(Runnable wrappedRunnable, SofaTraceContext traceContext) {
// 任務 runnable
 this.wrappedRunnable = wrappedRunnable;
 // tracer 上下文，可以由外部指定，如果沒有指定則使用 SofaTraceContextHolder 獲取
 this.traceContext = traceContext;
 if (!traceContext.isEmpty()) {
 // 將當前上下文中的 span 賦值給子執行緒
 this.currentSpan = traceContext.getCurrentSpan();
} else {
 this.currentSpan = null;
}
}

這上面這段程式碼片段來看，在構建 SofaTracerRunnable 物件例項時，會把當前父執行緒中的 traceContext 、currentSpan 等傳遞到子執行緒中。SofaTracerRunnable#run 方法中，會根據執行緒 ID 進行判斷，如果與父執行緒的執行緒ID不等，則會將 currentSpan push 到 traceContext (注：currentSpan 和 traceContext 均是子執行緒屬性)，run 方法則是委託給使用者傳遞進來的 wrappedRunnable 來執行。

Opentracing 0.30.x 版本對於執行緒透傳的支援

對於在低版本 Opentracing 規範中並沒有對執行緒傳遞的支援，但是在 0.30.0 版本以後有支援。 SOFATracer 目前是基於 Opentracing 0.22.0 版本實現的；但是對於 Opentracing 新 API 中提供的執行緒透傳的特性的理解也會有助於 SOFATracer 線上程透傳方面的改進

在之前的文章中對於 Span 的層級關係有過介紹，如果按照時序關係來展示大概如下：

這裡以 A、B、D 來看，三個 Span 是逐級巢狀的；如果把這個模型理解成為一個棧的話，那麼各個 Span 的產生過程即為入棧的過程，如下：

由於棧的特性是 FILO ，因此當 span C 出棧時就意味著 span C 的生命週期結束了，此時會觸發 Span 資料的上報。這裡其實也很好的解釋了 ChildOf 這種關係的描述：父級 Span 某種程度上取決於子 Span (子 Span 的結果可能會對父 Span 產生影響) ；父 Span 的生命週期時間是包含了子 Span 生命週期時間的。

在 SOFATracer 0.30.x 版本中提供了對上述思路的封裝，用於解決 Span 線上程中傳遞的問題。兩個核心的介面是Scope 和 ScopeManager ，Opentracing 中對這兩個介面均提供了預設的實現類：

ThreadLocalScope 和 ThreadLocalScopeManager 。

使用 ThreadLocal 來儲存不同執行緒的 Scope 物件，在多執行緒環境下可以通過獲取到當前執行緒的 Scope 來獲取當前執行緒的活動的 Span。
管理著當前執行緒所有曾被啟用還未釋放的 Span（處於生命週期內的 Span ）

ThreadLocalScopeManager & ThreadLocalScope 的設計

ScopeManager 解決的是 Span 線上程中傳遞的問題。但是 ScopeManager 本身直接操作 Span 又會顯得有些不徹底。這個不徹底怎麼理解呢？結合 SOFATracer 的實現，我的理解是：

SOFATracer 中也是使用 ThreadLocal 的機制實現 Span 線上程中傳遞的。ThreadLocal 中就是 set & get 。Span 之間的父子關係以及當前 ThreadLocal 中應該存哪個 Span 都需要我們自己在程式碼中來管理。這種方式完全 OK，但是如果對於一個標準/規範來說，如果只是定義一個這樣的 ThreadLocal 完全是沒有意義的。
自己管理 ThreadLocal 中 Span 的關係是一個複雜的過程，尤其是在鏈路較長的情況下。

基於上述兩點，ot-api 沒有采用直接在 ScopeManager 中基於 ThreadLocal 使用 set&get span 的操作方案。而是使用了 Scope，對應的實現類是 ThreadLocalScope；那麼好處在哪呢？

ThreadLocalScope 的設計使用了棧的思想，這個怎麼理解呢？在一個執行緒中，每一個 Span 的產生到結束，裡面在巢狀子 Span 的產生到結束，這種巢狀關係可以很容器聯想到棧的概念；參考上圖，這個過程很好理解，棧的操作，有進有出，一進一出就是一個 Span 的生命週期。

相比於 SOFATracer 的實現來看，Opentracing 提供的執行緒透傳實現更具有全域性性；ThreadLocalScope 為 Span 線上程中傳遞提供了新的設計思路，但是如果僅基於 Span + ThreadLocal 來實現，是很難的。

MDC 的擴充套件能力分析

SLF4J 提供了 MDC（Mapped Diagnostic Contexts）功能，可以支援使用者定義和修改日誌的輸出格式以及內容。SOFATracer 集成了 SLF4J MDC 功能，方便使用者在只簡單修改日誌配置檔案的情況下就可以輸出當前 Tracer 上下文的 TraceId 和 SpanId。

SLF4J MDC 機制

MDC ( Mapped Diagnostic Contexts )，這個介面是為了便於我們診斷線上問題而出現的方法工具類。 MDC 的實現也是利用了 ThreadLocal 機制。在程式碼中，只需要將指定的值 put 到執行緒上下文的 Map 中，然後在對應的地方使用 get 方法獲取對應的值。

先看一個 logback.xml 的輸出模板配置：

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
 <encoder charset="UTF-8">
 <pattern>[%d{yyyy-MM-dd HH:mm:ss} %highlight(%-5p) %logger.%M\(%F:%L\)] %X{THREAD_ID} %msg%n</pattern>
 </encoder>
</appender>

在日誌模板 logback.xml 中，使用 %X{} 來佔位，內容替換為對應的 MDC 中 key 的值，在模板解析時會從 MDC 中去取 key 對應的 value 來替換佔位符以達到自定義日誌格式的效果。

MDC 在 SOFATracer 中的應用

SOFATracer 對 MDC 的擴充套件在 com.alipay.common.tracer.extensions.log.MDCSpanExtension，這個類利用了 SpanExtension 的擴充套件功能來實現。MDC 擴充套件的程式碼也比較簡單，就是對 MDC 執行緒上下文值的儲存和刪除操作，看兩段主要的：

 // span 開始時的MDC操作
 public void logStartedSpan(Span currentSpan) {
 if (currentSpan != null) {

SofaTracerSpan span = (SofaTracerSpan) currentSpan;
SofaTracerSpanContext sofaTracerSpanContext = span.getSofaTracerSpanContext();
if (sofaTracerSpanContext != null) {
// 把當前span的traceId 和 spanId 放到 MDC 中


MDC.put(MDCKeyConstants.MDC_TRACEID, sofaTracerSpanContext.getTraceId());
MDC.put(MDCKeyConstants.MDC_SPANID, sofaTracerSpanContext.getSpanId());
}}}
 // Span結束時的MDC操作
 public void logStoppedSpan(Span currentSpan) {
 // 把當前span的traceId 和 spanId 從 MDC 中移除
MDC.remove(MDCKeyConstants.MDC_TRACEID);
MDC.remove(MDCKeyConstants.MDC_SPANID);
 if (currentSpan != null) {
 SofaTracerSpan span = (SofaTracerSpan) currentSpan;
 SofaTracerSpan parentSpan = span.getParentSofaTracerSpan();
 if (parentSpan != null) {

SofaTracerSpanContext sofaTracerSpanContext = parentSpan.getSofaTracerSpanContext();


 if (sofaTracerSpanContext != null) {
 // 把父span的traceId 和 spanId 放入 MDC 中
MDC.put(MDCKeyConstants.MDC_TRACEID, sofaTracerSpanContext.getTraceId());
MDC.put(MDCKeyConstants.MDC_SPANID, sofaTracerSpanContext.getSpanId());
}}}}

然後修改 logback.xml 的格式表示式：

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
 <encoder charset="UTF-8">
 <!-- %X{SOFA-TraceId} %X{SOFA-SpanId} 對應的就是tracerId和spanId的佔位符-->
 <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [%X{SOFA-TraceId},%X{SOFA-SpanId}]%logger{50} - %msg%n</pattern>
 </encoder>
</appender>

對應的 Demo 在 tracer-samples/tracer-sample-with-slf4j 下。

小結

回頭看文章開頭的兩個問題，基於 SOFATracer 的資料透傳和 MDC 擴充套件能力已經有了解決方案：

線上壓測的時候，我們只需要在入口往 SOFATracer 內設定一個壓測標識，通過 SOFATracer 的鏈路資料透傳能力，將壓測標識透傳到整個呼叫鏈路，每個呼叫鏈路相關的元件識別這個壓測標識進行對應的處理即可。

在業務日誌中找到請求相關的日誌，只需要在業務日誌輸出的時候，同步輸出 SpanId 和 TracerId，就能標記業務日誌的位置，再通過和 Tracer 資訊的結合，快速定位問題。

本篇主要剖析了 SOFATracer 在資料透傳和 Slf4j MDC 擴充套件功能兩個點；在鏈路資料透傳部分，又分別對跨程序透傳、執行緒透傳和 Opentracing 提供的執行緒透傳等分別作了詳細的介紹和分析。Slf4j MDC 擴充套件部分介紹了 MDC 機制以及 MDC 在 SOFATracer 中的應用。通過本篇，希望可以幫助大家更好的理解 SOFATracer 在鏈路透傳方面的基本原理和實現。

文中涉及到的所有連結：

在 OT 原文描述傳送門：
https:// opentracing.io/docs/ove rview/inject-extract/
螞蟻金服分散式鏈路跟蹤元件 SOFATracer 資料上報機制和原始碼分析| 剖析： https:// zhuanlan.zhihu.com/p/54 510191
SOFATracer 原始碼：
https:// github.com/alipay/sofa- tracer
SOFAtrace的非同步處理：
https://www. sofastack.tech/sofa-tra cer/docs/Async
SOFATracer 的測試用例 :
https:// github.com/alipay/sofa- tracer/tree/master/tracer-core/src/test/java/com/alipay/common/tracer/core/async
SOFATracer 對 MDC 的擴充套件 demo ：
https:// github.com/alipay/sofa- tracer/tree/master/tracer-samples/tracer-sample-with-slf4j

公眾號：金融級分散式架構（Antfin_SOFA）