螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

收藏待读

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

SOFA

S calable O pen F inancial A rchitecture

是螞蟻金服自主研發的金融級分佈式中間件,包含了構建金融級雲原生架構所需的各個組件,是在金融場景里錘鍊出來的最佳實踐。

SOFATracer 是一個用於分佈式系統調用跟蹤的組件,通過統一的 TraceId 將調用鏈路中的各種網絡調用情況以日誌的方式記錄下來,以達到透視化網絡調用的目的,這些鏈路數據可用於故障的快速發現,服務治理等。

本文為《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 團隊和源碼愛好者們出品,項目代號: 目前領取已經完成,感謝大家的參與。

SOFATracer:

https:// github.com/alipay/sofa- tracer
螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

0、前言

在《 螞蟻金服分佈式鏈路跟蹤組件 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 的類體系結構如下:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

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 span
    this.sofaTracer.reportSpan(this);
    SpanExtensionFactory.logStoppedSpan(this);
}

在 finish 方法中,通過 SofaTracer#reportSpan 將當前 span 進行了上報處理。以這個為入口,整個數據上報的調用鏈路如下圖所示:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

整個上報調用流程其實並不是很難,這裡留兩個問題:

  • 如何構造 clientRportor 和 serverReporter 的,依據是什麼?
  • 摘要日誌和統計日誌是怎麼落盤的?

第一個問題會在插件埋點解析篇中給出答案;第二個問題下面來看。

2、日誌落盤

前面已經提到,SOFATracer 本身提供了兩種上報模式,一種是落到磁盤,另外一種是上報到zipkin。在實現細節上,SOFATracer 沒有將這兩種策略分開以提供獨立的功能支持,而是將兩種上報方式組合在了一起,然後再通過配置參數來控制是否進行具體的上報邏輯,具體參考下圖:

螞蟻金服分佈式鏈路跟蹤組件 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(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 的:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析
  • 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() 阻塞模式申請序列。下面是一個簡易的模擬圖:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

2.1.6、小結

摘要日誌的落盤依賴於 Disruptor 的事件模型,當 span#finish 方法執行時,觸發 SofaTracer 的 report 行為;report 最終會將當前 span 數據放入 Disruptor 隊列中去,發佈一個 SofaTracerSpanEvent 事件。Disruptor 的消費者 EventHandler 實現類 Consumer 會監聽當前隊列事件,然後在回調函數 onEvent 中將 span 數據刷新到磁盤中。

2.2、統計日誌落盤實現

統計日誌的作用是為了監控統計使用,其記錄了當前跨度的調用次數、執行結果等數據。統計日誌是每隔一定時間間隔進行統計輸出的日誌,因此很容易想到是使用定期任務來執行的。這裡同樣來跟蹤下統計日誌打印的方法調用過程。

2.2.1、統計日誌的調用鏈路

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

AbstractSofaTracerStatisticReporter 的 doReportStat 方法是個抽象方法,那這裡又是與插件擴展部分聯繫在一塊的:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

可以看到 AbstractSofaTracerStatisticReporter 的實現類均是在 SOFATracer plugins 包下,也就是說統計日誌打印需要由不同的擴展插件來定義實現。但是實際上不同的插件在重寫 doReportStat 方法時也並非是直接將 span 數據 flush 到磁盤的,而是將 SofaTracerSpan 轉換成 StatMapKey 然後塞到了 AbstractSofaTracerStatisticReporter 中的一個 map 結構對象中。具體細節詳見:AbstractSofaTracerStatisticReporter#addStat。

2.2.2、統計日誌的打印模型

前面提到,統計日誌的落盤具有一定的周期性,因此在統計日誌落盤的設計上,SOFATracer 沒有像摘要日誌落盤那樣依賴於 Disruptor 來實現。下面先通過一張簡單的結構圖來看下摘要日誌的工作模型:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析
  • 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、上報 zipkin 的流程

接着上面的分析,SOFATracer 中的數據上報策略是以組合的形式共存的,這裡可以結合 第2節的第一張圖 來看。這裡先給出 zipkin 上報的流程,然後再結合流程展開分析:

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析
  • 在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.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.3、Zipkin 上報案例及展示

關於 SpringBoot 工程使用 zipkin 上報案例請參考:上報數據到 zipkin

關於 spring 應用中使用 zipkin 上報插件請參考:tracer-zipkin-plugin-demo

  • Services 展示
螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析
  • 鏈路依賴展示
螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

4、總結

4.1、SOFATracer 在數據上報模型上的考慮

了解或者使用過 SOFATracer 的同學應該知道, SOFATracer 目前並沒有提供數據採集器和 UI 展示的功能;主要有兩個方面的考慮:

  • SOFATracer 作為 SOFA 體系中一個非常輕量的組件,意在將 span 數據以日誌的方式落到磁盤,以便於用戶能夠更加靈活的來處理這些數據
  • UI 展示方面,SOFATracer 本身基於 OpenTracing 規範實現,在模型上與開源的一些產品可以實現無縫對接,在一定程度上可以彌補本身在鏈路可視化方面的不足。

因此在上報模型上,SOFATracer 提供了日誌輸出和外部上報的擴展,方便接入方能夠足夠靈活的方式來處理上報的數據。

4.2、文章小結

通過本文大家對 SOFATracer 數據上報功能應該有了一個大體的了解,對於內部的實現細節,由於篇幅和文章閱讀性等原因,不宜貼過多代碼,希望有興趣的同學可以直接閱讀源碼,對其中的一些細節進行了解。數據上報作為 SOFATracer 核心擴展能力之一,雖不同的上報途徑對應不同的上報模型,但是整體結構上還是比較清晰的,所以理解起來不是很難。

最後感謝大家對 SOFATracer 的關注,如果您在了解和使用此組件的過程中有任何疑問,歡迎聯繫我們。

歡迎加入,參與 SOFATracer 源碼解析【已領取完畢】

螞蟻金服分佈式鏈路跟蹤組件 SOFATracer 數據上報機制和源碼分析 | 剖析

本文作為《剖析 | SOFATracer 組件系列》第一篇,主要還是希望大家對 SOFATracer 組件有一個認識和了解,之後,我們會逐步詳細介紹每部分的代碼設計和實現,預計會按照如下的目錄進行:

  • 分佈式鏈路跟蹤組件 SOFATracer 概述【已完成】
  • SOFATracer API 組件埋點機制和源碼分析【已完成】
  • SOFATracer 鏈路透傳原理與 SLF4J MDC 的擴展能力分析【已領取】
  • SOFATracer 的採樣策略和源碼分析【已領取】
  • SOFATracer 數據上報機制和源碼分析【已領取】

文中提到的鏈接

公眾號:金融級分佈式架構(Antfin_SOFA)

原文 : sofastack

相關閱讀

免责声明:本文内容来源于進擊的Java新人,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。