對服務進行實時監控，了解服務當前的運行指標和健康狀態，是微服務體系中不可或缺的環節。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",method="sayHello"}，也可以是機器的 IP、機房信息等。這樣的數據存儲是時間序列數據庫親和的，基于這些數據可以輕松實現任意維度的聚合，篩選等操作。

P.s. 2017年12月底，Dropwizard Metrics4.0 開始支持 Tag，Dubbo Metrics 中 ag 的實現參考了Dropwizard。spring-boot 2.0中提供的 MicroMeter 和 Prometheus 也均已引入了 Tag 的概念。

二、添加精準統計功能
Dubbo Metrics 的精準統計是和 Dropwizard，或者其他開源項目埋點統計庫實現不太一樣的地方。下面分別通過時間窗口的選擇和吞吐率統計方式這兩個緯度進行闡述。

在統計吞吐率(如 QPS)的時候，Dropwizard的實現方式是滑動窗口+指數加權移動平均，也就是所謂的EWMA，在時間窗口上只提供1分鐘、5分鐘、15分鐘的選擇。

固定窗口 vs 滑動窗口
在數據統計的時候，我們需要事先定義好統計的時間窗口，通常有兩種確立時間窗口的方法，分別是固定窗口和滑動窗口。

固定時間窗口指的是以絕對時間為參考坐標系，在一個絕對時間窗口內進行統計，無論何時訪問統計數據，時間窗口不變；而滑動窗口則是以當前時間為參考系，從當前時間往前推一個指定的窗口大小進行統計，窗口隨著時間，數據的變化而發生變化。

固定窗口的優點在于：一是窗口不需要移動，實現相對簡單；二是由于不同的機器都是基于相同的時間窗口，集群聚合起來比較容易，只需按照相同的時間窗口聚合即可。其缺點是：如果窗口較大，實時性會受到影響，無法立即得到當前窗口的統計信息。例如，如果窗口為1分鐘，則必須等到當前1分鐘結束，才能得到這1分鐘內的統計信息。

滑動窗口的優點在于實時性更好，在任意時刻，能都看到當前時刻往前推演一個時間窗口內統計好的信息。相對而言，由于不同機器的采集時刻不同，要把不同機器上的數據聚合到一起，則需要通過所謂的 Down-Sampling 來實現。即按照固定時間窗口把窗口內收集到的數據應用到某一個聚合函數上。舉個例子來說，假設集群有5臺機器，按照15秒的頻率按照平均值進行 Down-Sampling，若在00:00~00:15的時間窗口內，在00:01，00:03，00:06，00:09，00:11各收集到一個指標數據，則把這5個點的加權平均認為是00:00這個點的經過 Down- Sampling 之后的平均值。

但在我們的實踐過程中，滑動窗口仍會遇到了以下問題：

• 很多業務場景都要求精確的時間窗口的數據，比如在雙11的時候，想知道雙11當天0點第1秒創建了多少訂單，這種時候 Dropwizard 的滑動窗口很明顯就不適用了。
• Dropwizard 提供的窗口僅僅是分鐘級，雙11的場景下需要精確到秒級。
• 集群數據聚合的問題，每臺機器上的滑動時間窗口可能都不一樣，數據采集的時間也有間隔，導致聚合的結果并不準確。

為了解決這些問題，Dubbo Metrics 提供了 BucketCounter 度量器，可以精確統計整分整秒的數據，時間窗口可以精確到1秒。只要每臺機器上的時間是同步的，那么就能保證集群聚合后的結果是準確的。同時也支持基于滑動窗口的統計。

瞬時速率(Rate) vs 指數移動加權平均(EWMA)
經過多年的實踐，我們逐漸發現，用戶在觀察監控的時候，首先關注的其實是集群數據，然后才是單機數據。然而單機上的吞吐率其實并沒有太大意義。怎么理解呢？

比如有一個微服務，共有2臺機器，某個方法在某一段時間內產生了5次調用，所花的時間分別是機器1上的[5，17]，機器2上的[6,8,8]（假設單位為毫秒）。如果要統計集群范圍內的平均 RT，一種方法可以先統計單機上的平均 RT，然后統計整體的平均 RT，按照這種方法，機器1上平均 RT 為11ms，機器2的平均 RT 為7.33ms，兩者再次平均后，得到集群平均 RT 為9.17ms，但實際的結果是這樣嗎？

如果我們把機器1和機器2上的數據整體拉到一起整體計算的話，會發現實際的平均 RT 為（5+17+6+8+8)/5=8.8ms，兩者相差很明顯。而且考慮到計算浮點數的精度丟失，以及集群規模擴大，這一誤差會愈加明顯。因此，我們得出一個結論：單機上的吞吐率對于集群吞吐率的計算沒有意義，僅在在單機維度上看才是有意義的。

而 Dropwizard 提供的指數加權移動平均其實也是一種平均，同時考慮了時間的因素，認為距離當前時間越近，則數據的權重越高，在時間拉的足夠長的情況下，例如15分鐘，這種方式是有意義的。而通過觀察發現，其實在較短的時間窗口內，例如1s、5s，考慮時間維度的權重并沒有太大的意義。**因此在內部改造的過程中，Dubbo Metrics 做了如下改進：
**

• 提供瞬時速率計算，反應單機維度的情況，同時去掉了加權平均，采用簡單平均的方式計算；
• 為了集群聚合需要，提供了時間窗口內的總次數和總 RT 的統計，方便精確計算集群維度的吞吐率；

三、極致性能優化
在大促場景下，如何提升統計性能，對于 Dubbo Metrics 來說是一個重要話題。在阿里的業務場景下，某個統計接口的 QPS 可能達到數萬，例如訪問 Cache 的場景，因此這種情況下 metrics 的統計邏輯很可能成為熱點，我們做了一些針對性的優化：

高并發場景下，數據累加表現最好的就是java.util.concurrent.atomic.LongAdder，因此幾乎所有的操作最好都會歸結到對這個類的操作上。

避免調用 LongAdder#reset
當數據過期之后，需要對數據進行清理，之前的實現里面為了重用對象，使用了LongAdder#reset進行清空，但實測發現LongAdder#reset其實是一個相當耗費cpu的操作，因此選擇了用內存換 CPU，當需要清理的時候用一個新的 LongAdder 對象來代替。

去除冗余累加操作
某些度量器的實現里面，有些統計維度比較多，需要同時更新多個 LongAdder，例如 Dropwizard Metrics的 meter 實現里面計算1分/5分/15分移動平均，每次需要更新3個 LongAdder，但實際上這3次更新操作是重復的，只需要更新一次就行了。

RT為0時避免調用Add方法
大多數場景下對 RT 的統計都以毫秒為單位，有些時候當 RT 計算出來小于1ms的時候，傳給metrics的 RT 為0。當我們發現 JDK 原生的 LongAdder 并沒有對add(0)這個操作做優化，即使輸入為0，還是把邏輯都走一遍，本質上調用的是sun.misc.Unsafe.UNSAFE.compareAndSwapLong。如果這個時候，metrics 判斷 RT 為0的時候不對計數器進行 Add 操作，那么可以節省一次 Add 操作。這對于并發度較高的中間件如分布式緩存很有幫助，在我們內部某個應用實測中發現，在30%的情況下，訪問分布式緩存的 RT 都是0ms。通過這個優化可以節約大量無意義的更新操作。

QPS 和 RT 合并統計
只需要對一個Long的更新，即可實現同時對調用次數和時間進行統計，已經逼近理論上的極限。

經過觀測發現，通常對于中間件的某些指標，成功率都非常高，正常情況下都在100%。為了統計成功率，需要統計成功次數和總次數，這種情況下幾乎一樣多，這樣造成了一定的浪費，白白多做了一次加法。而如果反過來，只統計失敗的次數，只有當失敗的情況才會更新計數器，這樣能大大降低加法操作。

事實上，如果我們把每一種情況進行正交拆分，例如成功和失敗，這樣的話，總數可以通過各種情況的求和來實現。這樣能進一步確保一次調用只更新一次計數。

但別忘了，除了調用次數，還有方法執行 RT 要統計。還能再降低嗎？

答疑是可以的！假設 RT 以毫秒為單位進行統計，我們知道1個 Long 有64個bits（實際上Java里面的Long是有符號的，所以理論上只有63個 bits 可用），而 metrics 的一個統計周期最多只統計60s的數據，這64個 bits 無論怎樣用都是用不掉的。那能不能把這63個 bits 拆開來，同時統計 count 和 RT 呢？實際上是可以的。

我們把一個 Long 的63個 bits 的高25位用來表示一個統計周期內的總 count，低38位用于表示總 RT。

------------------------------------------ | 1 bit | 25 bit | 38 bit | | signed bit | total count | total rt | ------------------------------------------

當一次調用過來來的時候，假設傳過來的 RT 是n，那么每次累加的數不是1，也不是n，而是

1 * 2^38 + n

這么設計主要有一下幾個考慮：

• count是每調用一次加一，RT 是每調用一次加N的操作，如果 count 在高位的話，每次加一，實際是一個固定的常數，而如果rt放在高位的話，每次都加的內容不一樣，所以每次都要計算一次；
• 25 bits 最多可以表示 2^25 = 33554432 個數，所以1分鐘以內對于方法調用的統計這種場景來說肯定是不會溢出的；
• RT 可能會比較大，所以低位給了38bits， 2^38=274877906944 基本也是不可能超的。

如果真的overflow了怎么辦？?
由于前面分析過，幾乎不可能overflow，因此這個問題暫時沒有解決，留待后面在解決。

無鎖 BucketCounter
在之前的代碼中，BucketCounter 需要確保在多線程并發訪問下保證只有一個線程對 Bucket 進行更新，因此使用了一個對象鎖，在最新版本中，對 BucketCounter 進行了重新實現，去掉了原來實現中的鎖，僅通過 AtomicReference 和 CAS 進行操作，本地測試發現性能又提升了15%左右。

四、全面的指標統計

Dubbo Metrics 全面支持了從操作系統，JVM，中間件，再到應用層面的各級指標，并且對統一了各種命名指標，可以做到開箱即用，并支持通過配置隨時開啟和關閉某類指標的收集。目前支持的指標，主要包括：

操作系統
支持Linux/Windows/Mac，包含CPU/Load/Disk/Net Traffic/TCP。

JVM
支持classload, GC次數和時間, 文件句柄，young/old區占用，線程狀態, 堆外內存，編譯時間，部分指標支持自動差值計算。

中間件
Tomcat: 請求數，失敗次數，處理時間，發送接收字節數，線程池活躍線程數等；
Druid: SQL 執行次數，錯誤數，執行時間，影響行數等；
Nginx: 接受，活躍連接數，讀，寫請求數，排隊數，請求QPS，平均 RT 等；

更詳細的指標可以參見這里， 后續會陸續添加對Dubbo/Nacos/Sentinel/Fescar等的支持。

五、REST支持

Dubbo Metrics 提供了基于 JAX-RS 的 REST 接口暴露，可以輕松查詢內部的各種指標，既可以獨立啟動HTTP Server提供服務（默認提供了一個基于Jersey+ sun Http server的簡單實現)，也可以嵌入已有的HTTP Server進行暴露指標。具體的接口可以參考這里：

https://github.com/dubbo/metrics/wiki/query-from-http

六、單機數據落盤

數據如果完全存在內存里面，可能會出現因為拉取失敗，或者應用本身抖動，導致數據丟失的可能。為了解決該問題，metrics引入了數據落盤的模塊，提供了日志方式和二進制方式兩種方式的落盤。

• 日志方式默認通過JSON方式進行輸出，可以通過日志組件進行拉取和聚合，文件的可讀性也比較強，但是無法查詢歷史數據；
• 二進制方式則提供了一種更加緊湊的存儲，同時支持了對歷史數據進行查詢。目前內部使用的是這種方式。

七、易用性和穩定性優化

• 將埋點的API和實現進行拆分，方便對接不用的實現，而用戶無需關注；
• 支持注解方式進行埋點；
• 借鑒了日志框架的設計，獲取度量器更加方便；
• 增加Compass/FastCompass，方便業務進行常用的埋點，例如統計qps，rt，成功率，錯誤數等等指標；
• Spring-boot-starter，即將開源，敬請期待；
• 支持指標自動清理，防止長期不用的指標占用內存；
• URL 指標收斂，最大值保護，防止維度爆炸，錯誤統計導致的內存。

如何使用

使用方式很簡單，和日志框架的Logger獲取方式一致。

Counter hello = MetricManager.getCounter("test", MetricName.build("test.my.counter")); hello.inc();

支持的度量器包括：

• Counter（計數器）
• Meter（吞吐率度量器）
• Histogram（直方分布度量器）
• Gauge(瞬態值度量器)
• Timer（吞吐率和響應時間分布度量器）
• Compass(吞吐率， 響應時間分布， 成功率和錯誤碼度量器)
• FastCompass(一種快速高效統計吞吐率，平均響應時間，成功率和錯誤碼的度量器)
• ClusterHistogram(集群分位數度量器)

后續規劃

• 提供Spring-boot starter
• 支持Prometheus，Spring MicroMeter
• 對接Dubbo，Dubbo 中的數據統計實現替換為 Dubbo Metrics
• 在 Dubbo Admin 上展示各種 metrics 數據
• 對接 Dubbo 生態中的其他組件，如Nacos, Sentinel, Fescar等

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

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

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