dubbo-go中metrics的設(shè)計(jì)是怎樣的

dubbo-go中metrics的設(shè)計(jì)是怎樣的，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

最近因?yàn)橐?Apache/dubbo-go（以下簡(jiǎn)稱 dubbo-go ）里面實(shí)現(xiàn)類(lèi)似的這個(gè) metrics 功能，于是花了很多時(shí)間去了解現(xiàn)在 Dubbo 里面的 metrics 是怎么實(shí)現(xiàn)的。該部分，實(shí)際上是被放在一個(gè)獨(dú)立的項(xiàng)目里面，即 metrics 。

總體上來(lái)說(shuō)，Dubbo 的 metrics 是一個(gè)從設(shè)計(jì)到實(shí)現(xiàn)都非常優(yōu)秀的模塊，理論上來(lái)說(shuō)，大部分的 Java 項(xiàng)目是可以直接使用 metrics 的。但也因?yàn)榧骖櫺阅?、擴(kuò)展性等各種非功能特性，所以初看代碼會(huì)有種無(wú)從下手的感覺(jué)。

今天這篇文章將會(huì)從比較大的概念和抽象上討論一下 dubbo-go 中的 metrics 模塊的設(shè)計(jì)——實(shí)際上也就是 Dubbo 中的 metrics 的設(shè)計(jì)。因?yàn)槲覂H僅是將 Dubbo 里面的相關(guān)內(nèi)容在 dubbo-go 中復(fù)制一份。

目前 dubbo-go 的 metrics 剛剛開(kāi)始起步，第一個(gè) PR ，點(diǎn)擊這里。

總體設(shè)計(jì)

Metric

要想理解 metrics 的設(shè)計(jì)，首先要理解，我們需要收集一些什么數(shù)據(jù)。我們可以輕易列舉出來(lái)在 RPC 領(lǐng)域里面我們所關(guān)心的各種指標(biāo)，諸如每個(gè)服務(wù)的調(diào)用次數(shù)，響應(yīng)時(shí)間；如果更加細(xì)致一點(diǎn)，還有各種響應(yīng)時(shí)間的分布，平均響應(yīng)時(shí)間，999線……

但是上面列舉的是從數(shù)據(jù)的內(nèi)容上劃分的。 metrics 在抽象上，則是摒棄了這種劃分方式，而是結(jié)合了數(shù)據(jù)的特性和表現(xiàn)形式綜合劃分的。

從源碼里面很容易找到這種劃分的抽象。
cdn.com/e04497d2b6e9d78080a4571a066e231bd8d98e17.jpeg">

metrics 設(shè)計(jì)了 Metric 接口作為所有數(shù)據(jù)的頂級(jí)抽象

為了大家理解，這里我抄一下這些接口的用途：

• Gauge: 一種實(shí)時(shí)數(shù)據(jù)的度量，反映的是瞬態(tài)的數(shù)據(jù)，不具有累加性，例如當(dāng)前 JVM 的線程數(shù)；

• Counter: 計(jì)數(shù)器型指標(biāo)，適用于記錄調(diào)用總量等類(lèi)型的數(shù)據(jù)；

• Histogram : 直方分布指標(biāo)，例如，可以用于統(tǒng)計(jì)某個(gè)接口的響應(yīng)時(shí)間，可以展示 50%, 70%, 90% 的請(qǐng)求響應(yīng)時(shí)間落在哪個(gè)區(qū)間內(nèi)；

• Meter: 一種用于度量一段時(shí)間內(nèi)吞吐率的計(jì)量器。例如，一分鐘內(nèi)，五分鐘內(nèi)，十五分鐘內(nèi)的qps指標(biāo)；

• Timer: Timer相當(dāng)于Meter+Histogram的組合，同時(shí)統(tǒng)計(jì)一段代碼，一個(gè)方法的qps，以及執(zhí)行時(shí)間的分布情況；

目前 dubbo-go 只實(shí)現(xiàn)了 FastCompass ，它也是 Metric 的子類(lèi)：

這個(gè)接口功能很簡(jiǎn)單，就是用于收集一段時(shí)間之內(nèi)的 subCategory 執(zhí)行的次數(shù)和響應(yīng)時(shí)間。 subCategory 是一個(gè)比較寬泛的概念，無(wú)論是在 Dubbo 還是在 dubbo-go 里面，一個(gè)典型的 subCategory 就會(huì)是某個(gè)服務(wù)。

這里的設(shè)計(jì)要點(diǎn)在于，它是從什么角度上去做這些數(shù)據(jù)的抽象的。

很多人在開(kāi)發(fā)這種采集數(shù)據(jù)的相關(guān)系統(tǒng)或者功能的時(shí)候，最容易陷入的就是從數(shù)據(jù)內(nèi)容上做抽象，例如抽象一個(gè)接口，里面的方法就是獲得服務(wù)的調(diào)用次數(shù)或者平均響應(yīng)時(shí)間等。

這種抽象并非不可以，尤其是在簡(jiǎn)單系統(tǒng)里面，還非常好用。唯獨(dú)在通用性和擴(kuò)展性上要差很多。

MetricManager

在我們定義了 Metric 之后，很容易就想到，我要有一個(gè)東西來(lái)管理這些 Metric 。這就是 MetricManager ——對(duì)應(yīng)到 Dubbo 里面的 IMetricManager 接口。

MetricManager 接口目前在 dubbo-go 里面還很簡(jiǎn)單：

MetricRegistry

MetricRegistry 是一個(gè)對(duì) Metric 集合的抽象。 MetricManager 的默認(rèn)實(shí)現(xiàn)里面，就是使用 MetricRegistry 來(lái)管理 Metric 的

所以，本質(zhì)上它就是提供了一些注冊(cè) Metric 然后再?gòu)睦锩鎿瞥鰜?lái)的方法。

于是，這就有一個(gè)問(wèn)題了：為什么我在有了 MetricManager 之后，還有有一個(gè)MetricRegistry？似乎這兩個(gè)功能有些重疊？

答案大概是兩個(gè)方面：
1、除了管理所有的 Metric 之外，還承擔(dān)著額外的功能，這些功能典型的就是 IsEnabled 。而實(shí)際上，在未來(lái)我們會(huì)賦予它管理生命周期的責(zé)任，比如說(shuō)在 Dubbo 里面，該接口就還有一個(gè) clear 方法；
2、 metrics 里面還有一個(gè) group 的概念，而這只能由 MetricManager 來(lái)進(jìn)行管理，至少交給 MetricRegistry 是不合適的。

metrics 的 group 說(shuō)起來(lái)也很簡(jiǎn)單。比如在 Dubbo 框架里面采集的數(shù)據(jù)，都會(huì)歸屬于 Dubbo 這個(gè) group 。也就是說(shuō)，如果我想將非框架層面采集的數(shù)據(jù)——比如純粹的業(yè)務(wù)數(shù)據(jù)——分隔出來(lái)，就可以借用一個(gè) business group 。又或者我采集到的機(jī)器自身的數(shù)據(jù)，可以將其歸類(lèi)到 system 這個(gè) group 下。

所以 MetricManger 和 MetricRegistry 的關(guān)系是：

Clock

Clock 抽象是一個(gè)初看沒(méi)什么用，再看會(huì)覺(jué)得其抽象的很好。Clock 里面就兩個(gè)方法：

report 其實(shí)就是把 metrics reports 給 MetricManager ：

這是一個(gè)更加寬泛的抽象。也就是意味著，我們除了可以從這個(gè) metricFilter 里面收集數(shù)據(jù)，也可以從自身的業(yè)務(wù)里面去收集數(shù)據(jù)。比如說(shuō)統(tǒng)計(jì)某段代碼的執(zhí)行時(shí)間，一樣可以使用 FastCompass 。

而除了 Prometheus ，如果用戶自己的公司里面有監(jiān)控框架，那么他們可以自己實(shí)現(xiàn)自己的上報(bào)邏輯。而上報(bào)的數(shù)據(jù)則只需要拿到 MetricManager 實(shí)例就能拿到。

關(guān)于dubbo-go中metrics的設(shè)計(jì)是怎樣的問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。