一、簡介
sofa-rpc的全鏈路追蹤技術是基于Sofa-Tracer實現的，Sofa-Tracer是基于ZipKin(谷歌Dapper)實現的，Sofa-Tracer參考了ZipKin的Trace-span設計；提供了相應的異步處理機制，每次會將父線程的上下文復制到子線程，為了防止多此異步調用的場景下，上下文的串用，不會再客戶端相應階段才清理上下文，而是會提前清理。
sofa-rpc在Sofa-Tracer的基礎上，提供了以下新的特性

可插拔：基于Extension機制，用戶可以重寫，實現自己的trace，包括相應的Filter邏輯
總線設計：sofa-rpc的trace機制實現是基于其EventBus機制實現的，對于業務方來說是無侵入式的
trace/span：將一次系統調用用traceId標記，traceId通過IP地址+時間戳+自增+進程PID生成；而spanId將在一次服務間的調用分為了cs (client send)、cr (client recv)、sr (server recv)、ss (server send)，如此設計，是為了區分在一個服務發生的多次調用，通過spanID能區分
數據采樣設計：在高并發系統中，可能某個Error日志出現的時候，一定不會是一天，可能幾千幾萬條，但并不是所有都需要被持久化的，sofa-rpc提供了基于RingBuffer的機制，對數據進行隨機采樣，當然，你也可以通過Sofa-Tracer的Sampler自定義采用規則
異步刷新機制：通常，我們的日志的持久化都是同步操作，但是在高并發系統，這會對業務系統造成一定的影響，特別是日志內容較大的時候，sofa-rpc的RingBuffer機制，是通過異步線程，消費RingBuffer里的trace日志任務，將日志持久化到磁盤
耗時計算：sofa-rpc的trace在上下文中提供了對于RPC操作的耗時計算
埋點數據透傳：sofa-rpc每次request都會把traceId和spanId等信息帶在SofaRequest的requestProps里，以便下一次請求對ID進行繼承自增；此方式稱為帶內透傳,谷歌的Dapper默認采用的是帶外傳播，即通過單獨提供一個寬帶來傳播，不影響原調用數據和網絡
異步線程的鏈路調動：為了防止多此異步調用的場景下，上下文的串用，不會再客戶端相應階段才清理上下文，而是會提前清理。
文件存儲結構：sofa-rpc將日志按類型做了以下分類

二、源碼分析
ClientProxyInvoker.invoke //客戶端調用入口，Trace生產流程

//觸發事件總線
1.EventBus.post
//消費到從EventBus來的trace消息，onEvent內對上述trace/span機制細分出來的各類消息進行了相應的處理
2.SofaTracerSubscriber.onEvent
    //處理rpc調用前的消息，主要是生成當前調用的Span信息、生成上下游Span關系，并將新的Span放到SofaTracerThreadLocalTraceContext的ThreadLocal的變量里
    2.1 Tracers.startRpc
    //處理客戶端發送請求前的消息，將當前線程的trace和spand等信息放到SofaRequest的requestProps里
    2.2 Tracers.clientBeforeSend
    //從相應消息體獲取到trace和spand等信息并放到自己的線程上下文里
    2.3 Tracers.clientAsyncReceivedPrepare
    //處理客戶端收到響應或者異常的消息，通過相應結果，判定成功或失敗，失敗則組裝異常信息并拋出，異常包含服務端返回異常和客戶端信息異常而產生的異常，無論成功與否，結束本次調用Span
    2.4 Tracers.clientReceived
    //處理服務端收到請求后的消息，獲取請求體內的trace和spand等信息，并放到自己的當前線程
    2.5 Tracers.serverReceived
    //處理服務端返回請求或者異常的消息，判定自己的返回是否出現異常，異常則設置相應的返回的Span的code為（00=成功/01=業務異常/02=RPC邏輯錯誤）
    2.6 Tracers.serverSend
    //檢查狀態，在結束調用的時候進行調用，防止資源泄露
    2.7 Tracers.checkState

三、總結
1.sofa-rpc的全鏈路追蹤依靠sofa-trace實現，包含上述說的trace/span、數據采樣設計、異步刷新機制等設計，核心功能還是在sofa-trace里