對服務進行實時監控，了解服務當前的運行指標和健康狀態，是微服務體系中不可或缺的環節。Metrics 作為微服務的重要組件，為服務的監控提供了全面的數據基礎。近日，Dubbo Metrics 發布了2.0.1版本，本文將為您探秘 Dubbo Metrics 的起源，及 7 大改進。

Dubbo Metrics 的起源

Dubbo Metrics(原Alibaba Metrics)是阿里巴巴集團內部廣泛使用的度量埋點基礎類庫，有 Java 和 Node.js 兩個版本，目前開源的是 Java 版本。內部版本誕生于2016年，經歷過近三年的發展和雙十一的考驗，已經成為阿里巴巴集團內部微服務監控度量的事實標準，覆蓋了從系統、JVM、中間件到應用各層的度量，并且在命名規則、數據格式、埋點方式和計算規則等方面，形成了一套統一的規范。

Dubbo Metrics 的代碼是基于 Dropwizard Metrics 衍生而來，版本號是3.1.0，當時決定 fork 到內部進行定制化開發的主要原因有兩個。

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

Dubbo Metrics 做了哪些改進

相對于 Dropwizard Metrics ，Dubbo Metrics 做的改進主要有以下幾個方面：

一、引入基于 Tag 的命名規范

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

• Metric Key：用英文點號分隔的字符串，來表征這個指標的含義
• Metric Tag：定義了這個指標的不同切分維度，可以是單個，也可以是多個；
• tag key：用于描述維度的名稱；
• tag value：用于描述維度的值；

同時，考慮到一個公司所有微服務產生的所有指標，都會統一匯總到同一個平臺進行處理，因此Metric Key 的命名方式為應當遵循同一套規范，避免發生命名沖突，其格式為appname.category[.subcategory]*.suffix

• appname: 應用名；
• category: 這個指標在該應用下的分類，多個單詞用'_'連接，字母采用小寫；
• subcategory: 這個指標在該應用下的某個分類下的子分類，多個單詞用'_'連接，字母采用小寫；
• suffix: 這個關鍵的后綴描述了這個指標所度量的具體類型，可以是計數，速率，或者是分布；

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。