前言

• 這篇文章主要是從pinpoint-web界面入手，我們的目標(biāo)是弄清楚兩個(gè)問(wèn)題：

- 1、 pinpoint左側(cè)服務(wù)地圖上的調(diào)用量數(shù)據(jù)是怎么查詢的？

- 2、界面查詢條件WasOnly是什么意思？

左側(cè)服務(wù)地圖調(diào)用量來(lái)源

從下圖可以看出，A顯示被USER調(diào)用299次,線上數(shù)值代表著調(diào)用量。

我們F12跟蹤一下接口地址：

http://webip:port/getServerMapDataV2.pinpoint?applicationName=A

&from=1575337980000&to=1575338040000

&callerRange=1&calleeRange=1

&bidirectional=false&wasOnly=false

&serviceTypeName=SPRING_BOOT

&_=1575337947426

web上顯示的數(shù)據(jù)，都是從hbase查詢出來(lái)的，所以跟蹤后端pinpoint-web工程源代碼，我們可以定位到hbase的一張表：ApplicationMapStatisticsCallee_Ver2。

調(diào)用者（caller）和被調(diào)用者callee

rowKey生成規(guī)則

• 細(xì)節(jié)可以跟蹤源代碼了解

rowKey生成規(guī)則：

ApplicationMapStatisticsUtils.makeRowKey(...);

Qualify列名生成規(guī)則：

ApplicationMapStatisticsUtils.makeColumnName(...);

我們都知道，界面查詢的時(shí)候可以選擇Inboud和outboud，并且最大顯示4X4的關(guān)系圖，所以在pinpoint設(shè)計(jì)的時(shí)候，就選擇存儲(chǔ)雙向關(guān)系：（目的就是構(gòu)造界面左側(cè)的服務(wù)地圖）。比如：

TOMCAT ===》調(diào)用 MYSQL則對(duì)調(diào)用者生成如下消息：

emeroad-app (TOMCAT) -> MySQL_DB_ID (MYSQL)[10.25.141.69:3306]

而對(duì)被調(diào)用者M(jìn)YSQL生成：

MySQL (MYSQL) <- emeroad-app (TOMCAT)[localhost:8080]

hbase存儲(chǔ)

hbase存儲(chǔ)結(jié)構(gòu)如上圖所示，因?yàn)槎际嵌M(jìn)制，所以列1，其實(shí)也是byte,而不是固定的字符名。

什么時(shí)候存儲(chǔ)這個(gè)雙向關(guān)系？

• 知道數(shù)據(jù)的底層存儲(chǔ)結(jié)構(gòu)了，下面，我們繼續(xù)來(lái)跟蹤，它是如何存進(jìn)來(lái)的，我們搜索一下引用，發(fā)現(xiàn)，有5個(gè)地方調(diào)用了這個(gè)存儲(chǔ)的api。

• 簡(jiǎn)單明了，那我們就逐個(gè)擊破把！

①SpanChunkHandler中

• 在chunk的結(jié)構(gòu)中，要求有spanEventList這個(gè)數(shù)據(jù)，（因?yàn)檎{(diào)用量 和它內(nèi)部的EVENTBo 條數(shù) 是1：1），并且需要滿足isRecordStatistics記錄條件。
• 當(dāng)滿足這兩個(gè)條件時(shí)，就會(huì)生成 A->B, B<--A, 兩個(gè)關(guān)系，使其左側(cè)服務(wù)地圖調(diào)用量+1。
• 其他位置邏輯類似，篇幅原因，這里不再細(xì)說(shuō)。
• ②　SpanHandler,112行
• ③　SpanHandler,117行
• ④　SpanHandler,127行
• ⑤　SpanHandler,189行

wasOnly的含義

• 還是通過(guò)上述的接口，我們可以跟蹤到，請(qǐng)求的參數(shù)，被封裝到了一個(gè)這些參數(shù)都被封裝到了SearchOption這個(gè)類。

private final int callerSearchDepth;

private final int calleeSearchDepth;

private final LinkSelectorType linkSelectorType;

private final boolean wasOnly;

怎么去看呢？這里提供一種思路，可能不適合所有人，大家參考一下。

從定義的變量，去理解它的含義，然后去“猜”。

callerSearchDepth: 調(diào)用者查詢深度。calleeSearchDepth：被調(diào)用者搜索深度。

除了wasOnly 和linkSelectorType不知道具體含義，上面兩個(gè)應(yīng)該就是用來(lái)控制搜索深度的。那我們繼續(xù)跟蹤代碼：這里通過(guò)判斷是否是Was，新建了一個(gè)處理器。也就是說(shuō)具體使用方法應(yīng)該是在這個(gè):callerLinkDataMapProcessor 類中。

if (searchOption.isWasOnly()) {

callerLinkDataMapProcessor = new WasOnlyProcessor();

}

看到這個(gè)類的accept方法相信大家，應(yīng)該會(huì)有所敏感，這應(yīng)該是用來(lái)判斷過(guò)濾條件的.

• 從代碼中可以看出，這里和Application有關(guān)，通過(guò)getServiceType
• 的兩個(gè)方法來(lái)判斷是否過(guò)濾。
• 有了這兩個(gè)方法，就好辦了，我們直接找它的實(shí)現(xiàn)就行了。
• 根據(jù)依賴關(guān)系，我們定位到了ServiceTypeFactory這個(gè)工廠類、DefaultServiceType及ServiceTypeProperty，具體查找方式可以通過(guò)觀察這幾個(gè)類了解，關(guān)系如下：

結(jié)論

• 粗略的理解：WAS ONLY會(huì)過(guò)濾類似于數(shù)據(jù)庫(kù)、或者是位置的節(jié)點(diǎn)，讓界面展示清楚一些。
• 用程序思維理解是：它會(huì)過(guò)濾掉serviceType為Unknown或者是Terminal的節(jié)點(diǎn)，具體哪些節(jié)點(diǎn)會(huì)有這兩個(gè)屬性呢，我想大家可以去自行研究研究。
• 我這里貼一個(gè)Unknown的，這個(gè)只有一個(gè)類型。

// Callee node that agent hasn't been installed

ServiceType UNKNOWN = of(1, "UNKNOWN", RECORD_STATISTICS);

• 研究的時(shí)候，貼的圖文太多，我整理了word，這里就不再多敘述了，有需要的小伙伴，可以加我，我發(fā)給你。歡迎關(guān)注俠夢(mèng)的開(kāi)發(fā)筆記

歡迎來(lái)公眾號(hào)【俠夢(mèng)的開(kāi)發(fā)筆記】 一起交流進(jìn)步