螞蟻金服分布式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析
SOFA
Scalable Open Financial Architecture 是螞蟻金服自主研發的金融級分布式中間件，包含了構建金融級雲原生架構所需的各個組件，是在金融場景裏錘煉出來的最佳實踐。
SOFATracer 是一個用於分布式系統調用跟蹤的組件，通過統一的 TraceId 將調用鏈路中的各種網絡調用情況以日誌的方式記錄下來，以達到透視化網絡調用的目的，這些鏈路數據可用於故障的快速發現，服務治理等。
本文為《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 團隊和源碼愛好者們出品，項目代號：<SOFA:TracerLab/>，目前領取已經完成，感謝大家的參與。SOFATracer：
https://github.com/alipay/sofa-tracer0、前言
在《螞蟻金服分布式鏈路跟蹤組件 SOFATracer 總覽|剖析》一文中已經對 SOFATracer 進行了概要性的介紹。從對 SOFATracer 的定義可以了解到，SOFATracer 作為一個分布式系統調用跟蹤的組件，是通過統一的 TraceId 將調用鏈路中的各種網絡調用情況以數據上報的方式記錄下來，以達到透視化網絡調用的目的。
本篇將針對SOFATracer的數據上報方式進行詳細分析，以幫助大家更好的理解 SOFATracer 在數據上報方面的擴展。
1、Reporter 整體模型
本節將對 SOFATracer 的 Report 模型進行整體介紹，主要包括兩個部分：
1、Reporter 的接口設計及實現；
2、數據上報流程。
1.1、Reporter 的接口設計及實現
數據上報是 SofaTracer 基於 OpenTracing Tracer 接口擴展實現出來的功能；Reporter 實例作為 SofaTracer 的屬性存在，在構造 SofaTracer 實例時，會初始化 Reporter 實例。
1.1.1、Reporter 接口設計
Reporter 接口是 SOFATracer 中對於數據上報的頂層抽象，核心接口方法定義如下：
//獲取 Reporter 實例類型 String getReporterType(); //輸出 span void report( SofaTracerSpan span); //關閉輸出 span 的能力 void close();
Reporter 接口的設計中除了核心的上報功能外，還提供了獲取 Reporter 類型的能力，這個是因為 SOFATracer 目前提供的埋點機制方案需要依賴這個實現。
1.1.2、Reporter 接口實現
Reporter 的類體系結構如下：
Reporter 的實現類有兩個，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：
-
SofaTracerCompositeDigestReporterImpl：
組合摘要日誌上報實現，上報時會遍歷當前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一執行 report 操作；可供外部用戶擴展使用。 - DiskReporterImpl：
數據落磁盤的核心實現類，也是目前 SOFATracer 中默認使用的上報器。
1.2、數據上報流程分析
數據上報實際都是由不同的鏈路組件發起，關於插件擴展機制及埋點方式不是本篇範疇，就不展開了。這裏直接來看數據上報的入口。
在 Opentracing 規範中提到，Span#finish 方法是 span 生命周期的最後一個執行方法，也就意味著一個 span 跨度即將結束。那麽當一個 span 即將結束時，也是當前 span 具有最完整狀態的時候。所以在 SOFATracer 中，數據上報的入口就是 Span#finish 方法，這裏貼一小段代碼：
//SofaTracerSpan#finish
@Override
public void finish(long endTime) {
this.setEndTime(endTime);
//關鍵記錄:report spanthis.sofaTracer.reportSpan(this);
SpanExtensionFactory.logStoppedSpan(this);
}在 finish 方法中，通過 SofaTracer#reportSpan 將當前 span 進行了上報處理。以這個為入口，整個數據上報的調用鏈路如下圖所示：
整個上報調用流程其實並不是很難，這裏留兩個問題：
- 如何構造 clientRportor 和 serverReporter 的，依據是什麽？
- 摘要日誌和統計日誌是怎麽落盤的？
第一個問題會在插件埋點解析篇中給出答案；第二個問題下面來看。
2、日誌落盤
前面已經提到，SOFATracer 本身提供了兩種上報模式，一種是落到磁盤，另外一種是上報到zipkin。在實現細節上，SOFATracer 沒有將這兩種策略分開以提供獨立的功能支持，而是將兩種上報方式組合在了一起，然後再通過配置參數來控制是否進行具體的上報邏輯，具體參考下圖：
本節將來剖析下日誌落盤的實現細節。日誌落盤又分為摘要日誌落盤 和 統計日誌落盤；摘要日誌是每一次調用均會落地磁盤的日誌；統計日誌是每隔一定時間間隔進行統計輸出的日誌。
2.1、摘要日誌落盤
摘要日誌落盤是基於 Disruptor 高性能無鎖循環隊列實現的。SOFATracer 中，AsyncCommonDigestAppenderManager 類對 disruptor 進行了封裝，用於處理外部組件的 Tracer 摘要日誌打印。
關於 Disruptor 的原理及其自身的事件模型此處不展開分析，有興趣的同學可以自行查閱相關資料。這裏直接看下 SOFATracer 中是如何使用 Disruptor 的。
2.1.1、消息事件模型
SOFATracer 使用了兩種不同的事件模型，一種是 SOFATracer 內部使用的 StringEvent，一種是外部擴展使用的 SofaTacerSpanEvent。詳見：SofaTracerSpanEvent & StringEvent 。
2.1.2、Consumer 消費者
Consumer 是 AsyncCommonDigestAppenderManager 的內部類；實現了 EventHandler 接口，這個 Consumer 作為消費者存在，監聽事件，然後通過 TraceAppender 將 span 數據 flush 到磁盤。詳見：AsyncCommonDigestAppenderManager
2.1.3、Disruptor 的初始化
-
Disruptor 的構建：在 AsyncCommonDigestAppenderManager 的構造函數中完成的。
//構建disruptor，使用的是 ProducerType.MULTI //等待策略是 BlockingWaitStrategy，考慮到的是CPU的使用率和一致性 disruptor = new Disruptor<SofaTracerSpanEvent>(new SofaTracerSpanEventFactory(), realQueueSize, threadFactory, ProducerType.MULTI, new BlockingWaitStrategy()); - 異常處理：如果在消費的過程中發生異常，SOFATracer 將會通過自定義的 ConsumerExceptionHandler 異常處理器把異常信息打到 tracer-self.log 中。
- 對於打印相關的參數條件設定，比如是否允許丟棄消息、是否記錄丟失日誌的數量、是否記錄丟失日誌的 TraceId 和 RpcId、丟失日誌的數量達到某閾值進行一次日誌輸出等。
2.1.4、啟動 Disruptor
Disruptor 的啟動委托給了 AsyncCommonDigestAppenderManager#start 方法來執行。
public void start(final String workerName) {
this.threadFactory.setWorkName(workerName);
this.ringBuffer = this.disruptor.start();
}查看調用棧，看下 SOFATracer 中具體是在哪裏調用這個 start 的：
- CommonTracerManager : 這裏面持有了 AsyncCommonDigestAppenderManager 類的一個單例對象，並且在 static 靜態代碼塊中調用了 start 方法；這個用來輸出普通中間件日誌。
- SofaTracerDigestReporterAsyncManager：這裏類裏面也是持有了AsyncCommonDigestAppenderManager 類的一個單例對像，並且提供了getSofaTracerDigestReporterAsyncManager 方法來獲取該單例，在這個方法中調用了 start 方法；該對象用來輸出摘要日誌。
2.1.5、發布事件
發布事件，也就意味著當前需要產生一個 span 記錄，這個過程也是在 finish 方法的調用棧中，也就是上圖中DiskReporterImpl#digestReport 這個方法。
AsyncCommonDigestAppenderManager asyncDigestManager = SofaTracerDigestReporterAsyncManager.getSofaTracerDigestReporterAsyncManager();
// ...
asyncDigestManager.append(span);
// ...這裏將 span 數據 append 到環形緩沖區，根據 AsyncCommonDigestAppenderManager 的初始化屬性，如果允許丟棄，則使用 tryNext 嘗試申請序列，申請不到拋出異常；否則使用 next() 阻塞模式申請序列。下面是一個簡易的模擬圖：
2.1.6、小結
摘要日誌的落盤依賴於 Disruptor 的事件模型，當 span#finish 方法執行時，觸發 SofaTracer 的 report 行為；report 最終會將當前 span 數據放入 Disruptor 隊列中去，發布一個 SofaTracerSpanEvent 事件。Disruptor 的消費者 EventHandler 實現類 Consumer 會監聽當前隊列事件，然後在回調函數 onEvent 中將 span 數據刷新到磁盤中。
2.2、統計日誌落盤實現
統計日誌的作用是為了監控統計使用，其記錄了當前跨度的調用次數、執行結果等數據。統計日誌是每隔一定時間間隔進行統計輸出的日誌，因此很容易想到是使用定期任務來執行的。這裏同樣來跟蹤下統計日誌打印的方法調用過程。
2.2.1、統計日誌的調用鏈路
AbstractSofaTracerStatisticReporter 的 doReportStat 方法是個抽象方法，那這裏又是與插件擴展部分聯系在一塊的：
可以看到 AbstractSofaTracerStatisticReporter 的實現類均是在 SOFATracer plugins 包下，也就是說統計日誌打印需要由不同的擴展插件來定義實現。但是實際上不同的插件在重寫 doReportStat 方法時也並非是直接將 span 數據 flush 到磁盤的，而是將 SofaTracerSpan 轉換成 StatMapKey 然後塞到了 AbstractSofaTracerStatisticReporter 中的一個 map 結構對象中。具體細節詳見：AbstractSofaTracerStatisticReporter#addStat。
2.2.2、統計日誌的打印模型
前面提到，統計日誌的落盤具有一定的周期性，因此在統計日誌落盤的設計上，SOFATracer 沒有像摘要日誌落盤那樣依賴於 Disruptor 來實現。下面先通過一張簡單的結構圖來看下摘要日誌的工作模型：
- xxxxxStatReporter : 插件擴展方實現的統計日誌 Reporter 類，重寫了 doStatReport 和 print 兩個方法。
- AbstractSofaTracerStatisticReporter ： 用於擴展的抽象類，xxxxxStatReporter 就是該類的子類；AbstractSofaTracerStatisticReporter 在其構造函數中，通過 SofaTracerStatisticReporterCycleTimesManager 將當前 statReporter 註冊到 SofaTracerStatisticReporterManager 中，統一存放在 statReporters 集合中。
- SofaTracerStatisticReporterManager ： 統計日誌 reporter 管理器，所有插件擴展的 reporter 都會被註冊到這個manager 類裏面來。其內部類 StatReporterPrinter 實現了runnable 接口，並在 run 方法中遍歷 statReporters，逐一調用 print 方法將數據刷到磁盤中。
- SofaTracerStatisticReporterManager 在構造函數中初始化了任務執行的周期、ScheduledExecutorService 實例初始化，並且將 StatReporterPrinter 提交到定時任務線程池中，從而實現了周期性輸出統計日誌的功能。
3、上報 Zipkin
前面對 SOFATracer 中的數據落盤進行了分析，最後再來看下 SOFATracer 中是如何把數據上報至 zipkin 的。
3.1.1、上報 zipkin 的流程
接著上面的分析，SOFATracer 中的數據上報策略是以組合的形式共存的，這裏可以結合 第2節的第一張圖 來看。這裏先給出 zipkin 上報的流程，然後再結合流程展開分析：
- 在SofaTracer#reportSpan 中有一個方法是 invokeReportListeners；該方法的作用就是遍歷當前所有的SpanReportListener 實現類，逐一回調 SpanReportListener 的 onSpanReport 方法。
- ZipkinSofaTracerSpanRemoteReporter 是 sofa-tracer-zipkin-plugin 插件中提供的一個實現了 SpanReportListener 接口的類，並在 onSpanReport 回調函數中通過 zipkin2.reporter.AsyncReporter 實例對象將 span 數據上報至 zipkin。
- 雖然 SOFATracer 和 zipkin 均是基於 OpenTracing 規範，但是在具體實現上 SOFATracer 做了很多擴展，因此需要通過一個 ZipkinV2SpanAdapter 將 SofaTracerSpan 適配成 zipkin2.Span。
zipkin2.reporter.AsyncReporter 是 zipkin 提供的一個數據上報抽象類，默認實現是 BoundedAsyncReporter，其內部通過一個守護線程 flushThread，一直循環調用 BoundedAsyncReporter 的 flush 方法，將內存中的 span 信息上報給 zipkin。
3.1.2、對非 SpringBoot 應用的上報支持
上報 zipkin 的能力做過一次改動，主要是對於在非SpringBoot應用(也就是Spring工程)的支持，具體參考 issue:建議不用spring boot也可以使用sofa-tracer並且上報zipkin 。
對於 SpringBoot 工程來說，引入 tracer-sofa-boot-starter 之後，自動配置類 SofaTracerAutoConfiguration 會將當前所有 SpanReportListener 類型的 bean 實例保存到 SpanReportListenerHolder 的 List 對象中。而SpanReportListener 類型的 Bean 會在 ZipkinSofaTracerAutoConfiguration 自動配置類中註入到當前 Ioc 容器中。這樣 invokeReportListeners 被調用時，就可以拿到 zipkin 的上報類，從而就可以實現上報。
對於非 SpringBoot 應用的上報支持，本質上是需要實例化 ZipkinSofaTracerSpanRemoteReporter 對象，並將此對象放在 SpanReportListenerHolder 的 List 對象中。所以 SOFATracer 在 zipkin 插件中提供了一個ZipkinReportRegisterBean，並通過實現 Spring 提供的 bean 生命周期接口 InitializingBean，在ZipkinReportRegisterBean 初始化之後構建一個 ZipkinSofaTracerSpanRemoteReporter 實例，並交給SpanReportListenerHolder 類管理。
3.1.3、Zipkin 上報案例及展示
關於 SpringBoot 工程使用 zipkin 上報案例請參考：上報數據到 zipkin
關於 spring 應用中使用 zipkin 上報插件請參考：tracer-zipkin-plugin-demo
-
Services 展示
- 鏈路依賴展示
4、總結
4.1、SOFATracer 在數據上報模型上的考慮
了解或者使用過 SOFATracer 的同學應該知道， SOFATracer 目前並沒有提供數據采集器和 UI 展示的功能；主要有兩個方面的考慮：
- SOFATracer 作為 SOFA 體系中一個非常輕量的組件，意在將 span 數據以日誌的方式落到磁盤，以便於用戶能夠更加靈活的來處理這些數據
- UI 展示方面，SOFATracer 本身基於 OpenTracing 規範實現，在模型上與開源的一些產品可以實現無縫對接，在一定程度上可以彌補本身在鏈路可視化方面的不足。
因此在上報模型上，SOFATracer 提供了日誌輸出和外部上報的擴展，方便接入方能夠足夠靈活的方式來處理上報的數據。
4.2、文章小結
通過本文大家對 SOFATracer 數據上報功能應該有了一個大體的了解，對於內部的實現細節，由於篇幅和文章閱讀性等原因，不宜貼過多代碼，希望有興趣的同學可以直接閱讀源碼，對其中的一些細節進行了解。數據上報作為 SOFATracer 核心擴展能力之一，雖不同的上報途徑對應不同的上報模型，但是整體結構上還是比較清晰的，所以理解起來不是很難。
文中提到的鏈接：
Disruptor ：
https://github.com/LMAX-Exchange/disruptor
SofaTracerSpanEvent：
https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/SofaTracerSpanEvent.java
StringEvent：
https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/StringEvent.java
AsyncCommonDigestAppenderManager：
https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/AsyncCommonDigestAppenderManager.java
[AbstractSofaTracerStatisticReporter#addStat]：
https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/reporter/stat/AbstractSofaTracerStatisticReporter.java
issue:建議不用spring boot也可以使用sofa-tracer並且上報zipkin：
https://github.com/alipay/sofa-tracer/issues/32
上報數據到 zipkin：
https://www.sofastack.tech/sofa-tracer/docs/ReportToZipkin
tracer-zipkin-plugin-demo：
https://github.com/glmapper/tracer-zipkin-plugin-demo
點擊閱讀更多，查看更多詳情
螞蟻金服分布式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析