對(duì)服務(wù)進(jìn)行實(shí)時(shí)監(jiān)控，了解服務(wù)當(dāng)前的運(yùn)行指標(biāo)和健康狀態(tài)，是微服務(wù)體系中不可或缺的環(huán)節(jié)。Metrics 作為微服務(wù)的重要組件，為服務(wù)的監(jiān)控提供了全面的數(shù)據(jù)基礎(chǔ)。近日，Dubbo Metrics 發(fā)布了2.0.1版本，本文將為您探秘 Dubbo Metrics 的起源，及 7 大改進(jìn)。

Dubbo Metrics 的起源

Dubbo Metrics(原Alibaba Metrics)是阿里巴巴集團(tuán)內(nèi)部廣泛使用的度量埋點(diǎn)基礎(chǔ)類庫(kù)，有 Java 和 Node.js 兩個(gè)版本，目前開源的是 Java 版本。內(nèi)部版本誕生于2016年，經(jīng)歷過近三年的發(fā)展和雙十一的考驗(yàn)，已經(jīng)成為阿里巴巴集團(tuán)內(nèi)部微服務(wù)監(jiān)控度量的事實(shí)標(biāo)準(zhǔn)，覆蓋了從系統(tǒng)、JVM、中間件到應(yīng)用各層的度量，并且在命名規(guī)則、數(shù)據(jù)格式、埋點(diǎn)方式和計(jì)算規(guī)則等方面，形成了一套統(tǒng)一的規(guī)范。

Dubbo Metrics 的代碼是基于 Dropwizard Metrics 衍生而來(lái)，版本號(hào)是3.1.0，當(dāng)時(shí)決定 fork 到內(nèi)部進(jìn)行定制化開發(fā)的主要原因有兩個(gè)。

一是社區(qū)的發(fā)展非常緩慢，3.1.0之后的第3年才更新了下一個(gè)版本，我們擔(dān)心社區(qū)無(wú)法及時(shí)響應(yīng)業(yè)務(wù)需求；另一個(gè)更重要的原因是當(dāng)時(shí)的3.1.0還不支持多維度的 Tag，只能基于 a.b.c 這樣傳統(tǒng)的指標(biāo)命名方法，這就意味著 Dropwizard Metrics 只能在單維度進(jìn)行度量。然后，在實(shí)際的業(yè)務(wù)過程中，很多維度并不能事先確定，而且在大規(guī)模分布式系統(tǒng)下，數(shù)據(jù)統(tǒng)計(jì)好以后，需要按照各種業(yè)務(wù)維度進(jìn)行聚合，例如按機(jī)房、分組進(jìn)行聚合，當(dāng)時(shí)的 Dropwizard 也無(wú)法滿足，種種原因使得我們做了一個(gè)決定，內(nèi)部fork一個(gè)分支進(jìn)行發(fā)展。

Dubbo Metrics 做了哪些改進(jìn)

相對(duì)于 Dropwizard Metrics ，Dubbo Metrics 做的改進(jìn)主要有以下幾個(gè)方面：

一、引入基于 Tag 的命名規(guī)范

如前文所描述，多維度 Tag 在動(dòng)態(tài)埋點(diǎn)，數(shù)據(jù)聚合等方面相對(duì)于傳統(tǒng)的 metric 命名方法具有天然的優(yōu)勢(shì)，這里舉一個(gè)例子，要統(tǒng)計(jì)一個(gè) Dubbo 服務(wù) DemoService 調(diào)用次數(shù)和 RT，假設(shè)這個(gè)服務(wù)叫做 DemoService，那么按照傳統(tǒng)的命名方式，通常會(huì)命名為dubbo.provider.DemoService.qps和dubbo.provider.DemoService.rt。如果只有1個(gè)服務(wù)的話，這種方法并無(wú)太大的問題，但是如果一個(gè)微服務(wù)應(yīng)用同時(shí)提供了多個(gè) Dubbo 的 Service，那么要聚合統(tǒng)計(jì)所有Service 的 QPS 和 RT 就比較困難了。由于 metric 數(shù)據(jù)具有天然的時(shí)間序列屬性，因此數(shù)據(jù)非常適合存儲(chǔ)到時(shí)間序列數(shù)據(jù)庫(kù)當(dāng)中，要統(tǒng)計(jì)所有的 Dubbo 服務(wù)的 QPS，那么就需要查找所有名稱為dubbo.provider.*.qps的指標(biāo)，然后對(duì)他們進(jìn)行求和。由于涉及到模糊搜索，這對(duì)于絕大部分?jǐn)?shù)據(jù)庫(kù)的實(shí)現(xiàn)都是比較費(fèi)時(shí)的。如果要統(tǒng)計(jì)更加詳細(xì)的 Dubbo 方法級(jí)別的 QPS 和 RT，那么實(shí)現(xiàn)上就會(huì)更加復(fù)雜了。

• Metric Key：用英文點(diǎn)號(hào)分隔的字符串，來(lái)表征這個(gè)指標(biāo)的含義
• Metric Tag：定義了這個(gè)指標(biāo)的不同切分維度，可以是單個(gè)，也可以是多個(gè)；
• tag key：用于描述維度的名稱；
• tag value：用于描述維度的值；

同時(shí)，考慮到一個(gè)公司所有微服務(wù)產(chǎn)生的所有指標(biāo)，都會(huì)統(tǒng)一匯總到同一個(gè)平臺(tái)進(jìn)行處理，因此Metric Key 的命名方式為應(yīng)當(dāng)遵循同一套規(guī)范，避免發(fā)生命名沖突，其格式為appname.category[.subcategory]*.suffix

• appname: 應(yīng)用名；
• category: 這個(gè)指標(biāo)在該應(yīng)用下的分類，多個(gè)單詞用'_'連接，字母采用小寫；
• subcategory: 這個(gè)指標(biāo)在該應(yīng)用下的某個(gè)分類下的子分類，多個(gè)單詞用'_'連接，字母采用小寫；
• suffix: 這個(gè)關(guān)鍵的后綴描述了這個(gè)指標(biāo)所度量的具體類型，可以是計(jì)數(shù)，速率，或者是分布；

在上述例子中，同樣的指標(biāo)可以命名為dubbo.provider.service.qps{service="DemoService"}，其中前面部分的名稱是固定的，不會(huì)變化，括號(hào)里面的Tag，可以動(dòng)態(tài)變化，甚至增加更多的維度，例如增加 method 維度dubbo.provider.service.qps{service="DemoService

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的java mongo分组统计_探秘 Dubbo 的度量统计基础设施 - Dubbo Metrics的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。