Dubbo 3.0 前瞻系列：服務發現支持百萬集羣，帶來可伸縮微服務架構

做者 | 劉軍（陸龜）
來源|阿里巴巴雲原生公衆號

本文是一篇關於 Dubbo 地址推送性能的壓測文章，咱們指望經過對比的方式展示 Dubbo3 在性能方面的提高，尤爲是新引入的應用級地址模型。但要注意，這並非官方正式版本的性能參考基線，而且因爲環境和時間緣由，部分對比數據咱們並無採集，但只要記住咱們只是在定性的檢測階段成果，這些限制整體上並不會有太大影響。

摘要

本文主要圍繞下一代微服務框架 Dubbo 3.0 在地址推送鏈路的性能測試展開，也是在性能層面對 Dubbo 3.0 在阿里落地過程當中的一個階段性總結，本輪測試了 Dubbo2 接口級地址發現、Dubbo3 接口級地址發現、Dubbo3 應用級地址發現。壓測數據代表，在百萬實例地址的壓測場景下：

• 基於接口級地址發現模型，Dubbo3 與 Dubbo2 對比，有超過 50% 常駐內存降低，Full GC 間隔更是明顯拉長。

• Dubbo3 新引入的應用級服務發現模型，能夠進一步實如今資源佔用方面的大幅降低，常駐內存比 Dubbo3 接口級地址進一步降低 40%，應用實例擴縮容場景增量內存分配基本爲零，相同週期內（1 小時） Full GC 減小爲 2 次。

Dubbo 3.0 做爲將來支撐業務系統的核心中間件，其自身對資源佔用率以及穩定性的提高對業務系統毫無疑問將帶來很大的幫助。

背景介紹

1. 下一代服務框架 Dubbo 3.0 簡介

一句話歸納 Dubbo 3.0：它是 HSF & 開源 Dubbo 後的融合產品，在兼容兩款框架的基礎上作了全面的雲原生架構升級，它將成爲將來面向阿里內部與開源社區的主推產品。

Dubbo 3.0 誕生的大背景是阿里巴巴在推進的全站業務上雲，這爲咱們中間件產品全面擁抱雲上業務，提供內部、開源一致的產品提出了要求也提供了契機，讓中間件產品有望完全擺脫自研體系、開源體系多線做戰的局面，有利於實現價值最大化的局面。一方面阿里電商系統大規模實踐的經驗能夠輸出到社區，另外一方面社區優秀的開發者也能參與到項目貢獻中。以服務框架爲例，HSF 和 Dubbo 都是很是成功的產品：HSF 在內部支撐歷屆雙十一，性能優異且久經考驗；而在開源側，Dubbo 坐穩國內第一開源服務框架寶座，用戶羣體很是普遍。

同時維護兩款高度同質化的產品，對研發效率、業務成本、產品質量與穩定性都是很是大的考驗。舉例來講，首先，Dubbo 與 HSF 體系的互通是一個很是大的障礙，在阿里內部的一些生態公司如考拉、餓了麼等都在使用 Dubbo 技術棧的狀況下，要實現順利平滑的與 HSF 的互調互通一直以來都是一個很是大的障礙；其次，產品不兼容致使社區輸出成本太高、質量驗收等成本也隨之增加，內部業務積累的服務化經驗與成果沒法直接賦能社區，二次改造適配 Dubbo 後功能性、穩定性驗收都要從新投入驗證。爲完全解決以上問題，結合上文提到的阿里集團業務總體上雲、開源以及雲產品輸出戰略，咱們制定了全面發展 Dubbo 3.0 的計劃。

2. Dubbo 不一樣版本在地址推送鏈路上的性能壓測與對比

下圖是服務框架的基本工做原理，橙色路徑即爲咱們這次重點壓測的地址推送鏈路，咱們重點關注在百萬地址實例推送的狀況下，Dubbo 不一樣版本 Consumer 間的差別，尤爲是 Dubbo 3.0 的實際表現。

做爲對比，咱們選取了如下場景進行壓測：

• Dubbo2，這次壓測的參考基線
• Dubbo3 接口級地址發現模型，與 Dubbo2 採用的模型相同
• Dubbo3 應用級地址發現模型，由雲原生版本引入，詳細講解請參見這篇文章

壓測環境與方法

• 壓測數據

本次壓測模擬了 220w（接口級）集羣實例地址推送的場景，即單個消費端進程訂閱 220w 地址。

• 壓測環境

8C16G Linux，JVM 參數中堆內存設置爲 10G。

• 壓測方法

Consumer 進程訂閱 700 個接口，ConserverServer 做爲註冊中心按必定比例持續模擬地址變動推送，持續時間 1 hour+，在此過程當中統計 Consumer 進程以及機器的各項指標。

優化結果分析與對比

1. GC 耗時與分佈

Dubbo2 接口級地址模型

Dubbo3 接口級地址模型

Dubbo3 應用級地址模型

2. 增量內存分配狀況

Dubbo2 接口級地址模型

Dubbo 3.0 接口級地址模型

Dubbo3 應用級地址模型

3. OLD 區與常駐內存

Dubbo2 接口級模型

Dubbo3 接口級模型

Dubbo3 應用級模型

4. Consumer 負載

Dubbo3 接口級模型

Dubbo3 應用級模型

詳細對比與分析

1. Dubbo2 接口模型 VS Dubbo3 接口模型

在 200w 地址規模下，Dubbo2 很快吃滿了整個堆內存空間，而且大部分都沒法獲得釋放，而由此觸發的頻繁的 GC，使得整個 Dubbo 進程已沒法響應，所以咱們壓測數據採集也沒有持續很長時間。

一樣保持接口級地址模型不變，通過優化後的 Dubbo3 ，在 1 個小時以內只有 3 次 Full GC，而且持續推送期間不可釋放內存大概降低在 1.7G。

2. Dubbo3 接口模型 VS Dubbo3 應用模型

當切換到 Dubbo3 應用級服務發現模型後，整個資源佔用狀況又出現了明顯降低，這體如今：

• 應用進程上下線場景，增量內存增加很小 (接口級的 MetadataData 基本獲得徹底複用，新增部分僅來自新擴容機器或部分服務的配置變動)。

• 常駐內存相比 Dubbo3 接口級又降低了近 40%，維持在 900M 左右。

值得一提的是，當前的應用級地址推送模型在代碼實現還有進一步優化的空間，好比 Metadata 複用、URL 對象複用等，這部分工做將是咱們後續探索的重點。

總結

Dubbo 3.0 目前已經實現了 Dubbo&HSF 的全面融合，雲原生方案也在全面推動中。在剛剛過去的雙十一中，Dubbo 3.0 平穩支撐了考拉業務，而且也已經經過阿里其餘一些電商應用的部分線上試點。後續咱們將專一在推進 Dubbo 3.0 的進一步完善，一方面兌現應用級服務發現、全新服務治理規則、下一代 Triple 協議等，另外一方面兌現咱們立項之初設定的資源佔用、性能、集羣規模等非功能性目標。

這次推送鏈路的性能壓測，是落地/研發過程當中的一次階段性驗收，應用級服務發如今資源佔用方面大幅降低，讓咱們看到了新架構對將來構建真正可伸縮集羣的可行性，這更堅決了咱們對應用級服務發現架構的信心。後續迭代中，在繼續完善接口級、應用級兩種模型並實現 Dubbo 3.0 的全面性能領前後，咱們將專一在遷移方案的實現上，以支持老模型到新模型的平滑、透明遷移。