如何做到方法的調用鏈

『壹』 idea怎麼查看jar里的類調用鏈

你要有這個jar對應的sources.jar才行，我這里以google的guava.jar為例，在maven倉庫中，有：

對於沒有相應的sources.jar的jar包，則看不到，jar包對應的sources.jar一般大公司的都會一起發布在網上。

『貳』 tt函數調用鏈怎麼用

載入時動態鏈接（load-time dynamic linking），模塊非常明確調用某個導出函數，使得他們就像本地函數一樣。這需要鏈接時鏈接那些函數所在DLL的導入庫，導入庫向系統提供了載入DLL時所需的信息及DLL函數定位。
運行時動態鏈接（run-time dynamic linking），運行時可以通過LoadLibrary或LoadLibraryEx函數載入DLL。DLL載入後，模塊可以通過調用GetProcAddress獲取DLL函數的出口地址，然後就可以通過返回的函數指針調用DLL函數了。如此即可避免導入庫文件了。
調用鏈有頭有尾執行從前往後，可以用一條線來表示，為簡化用一條直線表示。調用鏈的頭和尾是相對的，取決我們的觀察需要。一條鏈可以一分為二分別進行分析。

『叄』 深入探究ZIPKIN調用鏈跟蹤——拓撲Dependencies篇

Zipkin的拓撲服務zipkin-dependencies是作為zipkin的一個獨立的離線服務，也就是說，只啟動zipkin服務，是沒法看到拓撲的，還需要自己離線啟動zipkin-dependencues服務。

其中ES配置參數如下：

Zipkin出了支持elasticsearch存儲，還有mysql，cassard，詳細配置信息請看 源碼Readme

1、圖中線條說明

服務之間的線條，遵循以下原則：

2、主調被調次數說明

點開每一個服務，可以看到主調被調，比如我在拓撲圖中點擊
某個服務，可以與此服務有直接調用關系的服務有哪些，效果如下：

其中Uses by表示此服務作為被調服務，被哪些服務調用了；Uses表示此服務調用了哪些其他服務。

在上面的圖中點擊某個主調或被調服務，即可看到具體的調用次數，以及失敗次數，效果如下：

通過拓撲圖，宏觀上，我們可以快速了解服務之間的調用關系，同時也可以知道哪些服務間調用有問題，且可以知道出現問題的一個量級是多少（失敗數，調用總數）。

Zipkin拓撲denpendencies是基於上報的鏈路span數據再次構建出的描述鏈路拓撲的一種新的數據結構。

構建鏈路的第一步就是讀取Span數據。Zipkin外部數據源支持三種，分別是Mysql，Cassandra，Elasticsearch，因此構建拓撲時，將從這三種數據源中讀取Span數據。

讀取Span數據源後，需要對其處理，計算出鏈路的拓撲。因為Span的數據量很大，普通程序計算處理無法完成任務，因此需要用到大數據框架。Zipkin官方選用的是Spark框架。Spark對Span數據進行處理，最後生成拓撲數據DenpendencyLink，然後持久化到存儲中。

前端請求拓撲(DependencyLink)時，即按照查詢條件，查詢已經持久化後的DependencyLink，然後經過UI渲染，進行頁面展示。

啟動Zipkin-dependencies服務時，會傳入幾個參數，分別是時間day和存儲類型storageType。Zipkin-dependencies服務是以天為單位進行建立拓撲，因此day將決定建立那一天的拓撲；而storageType將決定從什麼儲存中讀取數據。

1、獲取日期：

2、獲取存儲類型：

3、根據不同的存儲啟動不同的jOb:

不同的存儲會定義不同Job類，因此有CassandraDependenciesJob，MySQLDependenciesJob，MySQLDependenciesJob，ElasticsearchDependenciesJob。 不同的Job主要區別在於讀取Span的方式不同，而Spark對Span進行處理計算的方式基本都是相同的。 本文主要分析ElasticsearchJOb。

Job中主要邏輯都在run方法中，ElastichserchJob的Run方法定義如下：

主要步驟如下：
1、首先通過Spark的配置屬性Conf，創建一個JavaSparkContext對象sc：

2、然後讀取elasticsearch span數據源：

3、讀取數據源後，就可以對Span進行處理了，首先按照TraceId 進行Group分組：

其中JSON_TRACE_ID Function定義如下：

4、Span按照TraceId Group 分組後，接著對Span進行處理， 創建出DenpendencyLink。

5、上面方法最終返回的是個Map類型，將其轉化為pari類型，再對其進行一個receByKey操作：

6、Spark對Span的計算操作到這兒基本就完成了，最後將DependencyLink轉化為Jso形式：

7、對於計算好的拓撲Links，將其持久化到Elasticsearch中：

整個過程到此完畢，其中最復雜也是最核心的邏輯就是計算出鏈路拓撲Denpendencylink，此步驟在Function (logInitializer, decoder)中。接下來詳細分析完成的工作。

首先介紹一下DenpendencyLink數據結構。DenpendencyLink就是最終與頁面交互的拓撲結構數據單元，字端有：

DenpendencyLink類定義如下：

類的定義如下：

其中call方法中，首先完成對同一TraceId的Span解碼：

然後，通過DependencyLinker類構造出DependendyLink，首先構造一個SpanNode Tree：

然後利用深度優先遍歷方法遍歷整個，統計出CallCounts和errorCounts:

其中callCounts和errorCounts定義如下：

最後，再通過callCounts和errorCounts生成List<DependencyLink>:

這樣，最終構建出了DependencyLink。

本文為我的調用鏈系列文章之一，已有文章如下：

祝大家工作順利，天天開心！