應用級服務發現基準測試

1 效能測試結論

與 2.x 版本相比，Dubbo3 版本

• 顯著提升了服務發現資源利用率。
  • 與介面級服務相比，發現單機常駐記憶體降低 50%，地址變更期間 GC 消耗降低一個數量級（百次 -> 十次）
  • 與應用級服務相比，發現單機常駐記憶體降低 75%，GC 次數趨近於零

以下是詳細的壓力測試過程與資料

2 應用級服務發現（地址推送鏈路）

這部分的壓力測試資料由工行 Dubbo 團隊基於內部生產資料提供。壓力測試過程模擬「生產環境地址 + zookeeper」的服務發現架構。

2.1 環境

| | 說明 | | ———— | ———————————— ———————— | | 壓力測試資料 | 提供者
500 個執行個體 ✖️ 8 個介面 ✖️ 5 個協定，即每個提供者向註冊中心註冊 40 個 URL，共 20,000 個 URL，每個 URL 長度約 1k 字元。

註冊中心
2 個獨立的 zookeeper 註冊中心，服務提供者和消費者採用平行設定。

消費者
設定 1c2g，xmx=768，啟用 GC，從 2 個註冊中心訂閱，每 5 秒呼叫一次服務。運行 20 小時。 | | 壓力測試環境 | Java 版本 “1.8.0”
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (Build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796, JIT enabled, AOT enabled) |

2.2 資料分析

圖 1 服務發現模型記憶體使用變化

• Dubbo3 介面級服務發現模型，常駐記憶體相比 2.x 版本降低約 50%
• Dubbo3 應用級服務發現模型，常駐記憶體相比 2.x 版本降低約 75%

圖 2 服務發現模型 GC 變化

• Dubbo3 介面級服務發現模型，相較於 2.x 版本，YGC 次數顯著下降，從數百次降低到十多次。
• Dubbo3 應用級服務發現模型，相較於 2.x 版本，FGC 次數顯著下降，從數百次降低到零次。