實踐案例：平安健康的 Dubbo3 遷移歷程總結

• 2022 年 11 月 30 日
• 筆記

本篇是 Apache Dubbo 的實踐案例。感興趣的朋友可以訪問官網了解更多詳情，或搜索關注官方微信公眾號 Apache Dubbo 跟進最新動態。

1 背景

我們公司從15年開始就使⽤dubbo作為微服務框架，當社區推出dubbo3時，我們也⽴刻跟進並做了深⼊調研，發現dubbo3 的應⽤/實例級服務註冊和發現模式能夠在一定程度上解決我們當前註冊中⼼⾯臨的壓⼒，解決穩定性和安全性問題。同時dubbo3在服務治理上也做了升級，契合雲原⽣架構，⽽且dubbo3能夠向下兼容dubbo2，這也將降低升級的成本和⻛險。

升級項目有了階段性的進展，目前仍然在進行中。通過本⽂，我們對公司內部的Dubbo3 升級過程及收益等做了深⼊總結。

2 Dubbo3 核⼼功能介紹

dubbo社區關於dubbo3的文檔和資料越來越完善，以下是我們從社區引用的一些內容。

2.1 下一代雲原生服務框架

Dubbo3被社區寄予厚望，將其視為下一代雲原生服務框架打造，Dubbo3 提供的核心特性列表，主要包括四部分。

• 全新服務發現模型 。應用粒度服務發現，面向雲原生設計，適配基礎設施與異構系統；性能與集群伸縮性大幅提升。
• **下一代 **** RPC **協議 Triple 。基於 HTTP/2 的 Triple 協議，兼容 gRPC；網關穿透性強、多語言友好、支援 Reactive Stream。
• 統一流量治理模型 。面向雲原生流量治理，SDK、Mesh、VM、Container 等統一治理規則；能夠支援更豐富的流量治理場景。
• Service Mesh 。在最新的3.1.0的版本中支援Sidecar Mesh 與 Proxyless Mesh，提供更多架構選擇，降低遷移、落地成本。

首先是性能、資源利用率的提升。社區資料顯示，升級 Dubbo3 的應用預期能實現單機記憶體 50% 的下降，對於越大規模的集群效果將越明顯，Dubbo3 從架構上支援百萬實例級別的集群橫向擴展,同時依賴應用級服務發現、Triple協議等可以大大提供應用的服務治理效率和吞吐量。

其次， Dubbo3 讓業務架構升級變得更容易、更合理，尤其是RPC協議，在 2.x 版本中，web、移動端與後端的通訊都要經過網關代理，完成協議轉換、類型映射等工作，dubbo3的Triple 協議讓這些變得更容易與自然；並通過流式通訊模型滿足更多的使用場景。

最後，得益於 Dubbo3 的完善雲原生解決方案，Dubbo3的mesh架構可以幫助業務屏蔽底層雲原生基礎設施細節，讓業務更專註於業務，這也是mesh的最根本的優勢。

2.2 應用級服務發現核心原理

我們從 Dubbo 最經典的工作原理圖說起，Dubbo 從設計之初就內置了服務地址發現的能力，Provider 註冊地址到註冊中心，Consumer 通過訂閱實時獲取註冊中心的地址更新，在收到地址列表後，consumer 基於特定的負載均衡策略發起對 provider 的 RPC 調用。 在這個過程中

• 每個 Provider 通過特定的 key 向註冊中心註冊本機可訪問地址；
• 註冊中心通過這個 key 對 provider 實例地址進行聚合；
• Consumer 通過同樣的 key 從註冊中心訂閱，以便及時收到聚合後的地址列表；

再來看一下Provider向註冊中心註冊的 URL 地址的詳細格式，這裡把 URL 地址數據劃分成了幾份：

• 首先是實例可訪問地址，主要資訊包含 ip port，是消費端將基於這條數據生成 tcp 網路鏈接，作為後續 RPC 數據的傳輸載體。
• 其次是 RPC 元數據，元數據用於定義和描述一次 RPC 請求，表明這條地址數據是與某條具體的 RPC 服務有關的，它的版本號、分組以及方法相關資訊。
• 下一部分是 RPC 配置數據，部分配置用於控制 RPC 調用的行為，還有一部分配置用於同步 Provider 進程實例的狀態，典型的如超時時間、數據編碼的序列化方式等。
• 最後一部分是自定義的元數據，這部分內容區別於以上框架預定義的各項配置，給了用戶更大的靈活性，用戶可任意擴展並添加自定義元數據，以進一步豐富實例狀態。

結合以上對於 Dubbo2 介面級地址模型的分析，以及最開始的 Dubbo 基本原理圖，可以得出這麼幾條結論：

• 第一，地址發現聚合的 key 就是 RPC 粒度的服務。
• 第二，註冊中心同步的數據不止包含地址，還包含了各種元數據以及配置。
• 得益於 1 與 2，Dubbo 實現了支援應用、RPC 服務、方法粒度的服務治理能力。

這就是一直以來 Dubbo2 在易用性、服務治理功能性、可擴展性上強於很多服務框架的真正原因。

面對這樣的地址數量級放大的問題，在 Dubbo3 架構下，社區認真思考了兩個問題：

• 如何在保留易用性、功能性的同時，重新組織 URL 地址數據，避免冗餘數據的出現，讓 Dubbo3 能支撐更大規模集群水平擴容？
• 如何在地址發現層面與其他的微服務體系如 Kubernetes、Spring Cloud 打通？

最終，社區給出的方案也是非常巧妙和經典。Dubbo3 的應用級服務發現方案設計的基本思路是：地址發現鏈路上的聚合元素也就是之前提到的 Key 由服務調整為應用，這也是其名稱叫做應用級服務發現的由來,與kubernetes和spring cloud的服務註冊發現處於同一粒度，能夠平滑打通；另外，通過註冊中心同步的數據內容上做了大幅精簡，只保留最核心的 ip、port 地址數據。 經過上述調整，應用級別服務發現在保持介面級地址模型易用性的同時，實現了地址單條數據大小和總數量的下降。

元數據、配置數據以及自定義數據等通過元數據中心或者MetadataService進行同步，且將所有的數據生成一個metadata revision, metadata revision相同則認為元數據等資訊相同，通過這種方式來降低元數據中心或MetadataService的訪問頻次。

3 前期調研

了解了 Dubbo3 的核心功能以及應用級服務發現的工作原理後，我們開始進入前期工作階段。

3.1 性能壓測

從社區的資料來看，dubbo3各方面都非常不錯，但是我們還得自己檢驗一次，所以我們使用當前在用的dubbo2內部訂製版和dubbo3的性能壓測，壓測的主要場景在於同步調用，非同步場景只做了dubbo3的壓測， 以下壓測數據和結論僅供參考 。結果表明dubbo3在性能上面確實做了很多的優化，在相同cpu使用率的情況下，dubbo3的tps是要高於dubbo2的；tps相當的情況下，dubbo3的cpu使用率要低於dubbo2。尤其是dubbo2的介面級與dubbo3的實例級，在tps相當的情況下，dubbo3的cpu使用率要較訂製版的dubbo2低20%左右。

壓測環境：

測試場景：

使用的是Dubbo協議，介面沒有其它邏輯，直接將輸入返回給消費者, 介面數據包大小500B，每個場景壓30分鐘。

測試數據 (僅供參考)：

3.2 升級前調研

做了壓測得到dubbo2和dubbo3的壓測數據後，我們開始計劃將 Dubbo3 引入公司進行試點，此時，我們需要考慮dubbo3與dubbo2的兼容和遷移重構問題，升級目標，以及dubbo3提供有哪些能力支援升級和遷移。

3.2.1 升級的兼容和遷移重構問題

考慮到公司的系統規模，要將dubbo2升級到dubbo3卻不是一個簡單的過程，尤其是公司的dubbo2版本在原開源版本基礎之上做了不少優化和擴展，涵蓋了ops服務治理、monitor數據指標監控、服務註冊和發現、RPC灰度路由、鏈路分析、序列化編解碼、作為其他基礎框架的底層支援等多個方面，同時dubbo3社區也處於活躍的狀態，我們也希望能夠持續享受dubbo社區的技術紅利，在這樣的背景下不得不考慮三個問題：

1. 需要解決公司版本的dubbo2與dubbo3的兼容問題；
2. 原有功能的遷移重構問題；
3. 不在dubbo3的源碼上做改動，保持和社區版本一致。

得益於dubbo 良好的擴展能力，我們可以通過dubbo 的SPI和IoC模組在dubbo3的基礎之上優雅的兼容公司版本的dubbo2，不用改動dubbo3源碼，只要研發dubbo3擴展包跟隨dubbo3版本的API升級即可，這個升級改動的成本和從社區獲取紅利相比是比較小的。

3.2.2 升級目標

既然歷史包袱的解決方案已經有了，那麼就要思考升級的目標了。首先確定的是，最終我們將會採用實例級的服務註冊和服務發現，其次我們目前使用的註冊中心是zookeeper，而dubbo社區更推薦使用的註冊中心是nacos，而且我們在驗證階段時也暴露過幾個在zookeeper上出現而在nacos上沒有出現的問題，這也使得我們開始考慮將來是否將註冊中心最終也遷移到nacos上。

同時，我們也希望整個遷移過程是平滑、可控的，我們整體方案也要將風險把控作為核心要點考慮，儘可能的做到失敗降級、實時可控。

綜上，我們將升級的目標歸納為下面幾點：

1）平滑的從dubbo2升級到dubbo3。

2）將介面級服務註冊和發現模式平滑的遷移到應用級服務註冊和發現模式。

3）為後面平滑遷移註冊中心做好準備。

4）遷移過程可監控、可觀測。

5）遷移過程要可灰度、可實時管控。

6）統一dubbo3的通用配置規範，盡量適配原dubbo2的export和refer方式。

3.2.3 dubbo3對於遷移的支撐能力

前面介紹的是我們的目標，但是如何把dubbo3的原生設計理念融入到現實情況中呢？以下是我們的相關思考，並在驗證過程中。

首先dubbo3能夠支援在registryUrl上通過參數管理provider和consumer以不同的模式進行服務註冊和服務發現，其中核心參數名有: registry-type, registry-protocol-type, register-mode。

其次，dubbo3可以支援使用多個註冊中心，不同的註冊中心通過上面的registryUrl參數控制註冊中心的服務註冊模式和服務發現模式。而且還可以通過ProviderConfig和ConsumerConfig這兩個這兩個Config類分別管理provider側和consumer側使用的註冊中心。在consumer側，如果有使用多個註冊中心，默認會使用ZoneAwareCluster創建的ZoneAwareClusterInvoker來進行負載均衡，從類名上可以看出，該ClusterInvoker是有提供區域感知的能力，查看源碼時發現它還提供了preferred的功能，只在相應的registryUrl中添加了preferred=true，這個registryUrl創建的ClusterInvoker就會被優先調用。

在同一註冊中心進行介面級遷移到實例級的場景中，dubbo3的MigrationInvoker也提供了相應的支援，MigrationInvoker可以根據MigrationRule來控制實例級的RPC流量，並且根據MigrationRuleListener能夠實時監聽到指定應用的MigrationRule的變更。

關於RPC 的監控在dubbo中一直由MonitorFilter和DubboMonitor提供RPC監控數據的收集和上報，收集的數據有消費者的ip埠、提供者的ip埠、應用名稱、DubboService、Method、以及成功數、失敗數、輸入位元組數、輸出位元組數、耗時、並發數等，

這些能力能夠滿足基本的遷移工作，結合我們的現狀來看，相對升級目標要求的平滑遷移，遷移流量可觀測、可灰度、可管控還有一些距離，不過在梳理dubbo3這塊能力的時候，也找到了相對簡單的擴展方案。到此，對於整體的遷移方案也有了一個大致的雛形。

4 升級&遷移方案設計

方案的設計重點放在”平滑、可控”兩點，根據dubbo3的新架構，目前正在驗證中的遷移方案示意圖如下：

從上圖可以看出，在整個升級遷移的過程中，應用域中會存在多個dubbo版本，dubbo3是能夠兼容社區的dubbo2版本，而我們公司內部的dubbo2版本是基於dubbo2.5.3開源版本深度訂製過的，在ops服務治理、monitor數據指標監控、服務註冊和發現、RPC灰度路由、序列化編解碼等方面都做了擴展訂製，我們的思路是由dubbo3基於dubbo的SPI採用擴展的方式或者ExtensionLoader的Wrapper模式去兼容訂製版的dubbo2。

除了應用外，在dubbo3的架構基礎上劃分了3個邏輯域，分別是註冊域、配置管控域和監控域。註冊域主要服務於服務的註冊和發現，例如provider在DubboService暴露時，將服務資訊和元數據資訊上報到註冊域的註冊中心和元數據中心，consumer通過註冊中心和元數據中心來發現服務。配置管控域主要是管理應用配置和遷移流量管控，dubbo3提供的配置中心支援自身能力的配置，所以流量規則的配置由dubbo3的配置中心進行維護，dubbo3的DynamicConfigration提供了很多關於動態配置的方法可以直接使用。監控域除了原RPC流量的監控外，還細分了遷移流量的監控，在遷移過程中，可以通過監控直觀的看到遷移流量的現狀，出現問題時，也可以及時報警通知相關人員介入。

整個升級過程分為3個階段：

第一階段：將dubbo2升級到dubbo3的介面級，驗證功能、兼容性、性能和穩定性

第二階段：介面級和應用級雙註冊，通過MigrationRule和RegistryMigrationRule管理RPC流量

第三階段：全面切換到應用級，撤掉MigrationRule和RegistryMigrationRule

4.1 dubbo3擴展兼容dubbo2訂製版本

考慮到dubbo3社區版本的迭代情況，最終決定dubbo3兼容dubbo2訂製版本的插件以SDK的方式單獨維護，實現兼容的擴展功能主要有如下內容：

1. RPC 正向透遞與反向透傳

在consumer側和provider側擴展Filter介面實現類，為正向與反向透傳數據實現其發送和接收的功能。Dubbo2訂製版是在序列化編解碼層面對RpcResult進行了修改，要兼容這一邏輯也只能在序列化編解碼層面去支援，採用Wrapper模式對Codec2這個SPI進行增強，與其它擴展類一併實現該兼容功能。

2. RPC 灰度路由

擴展Dubbo 的Router、 Cluster和ConfiguratorFactory等SPI，與內部的eunomia灰度管控平台集成實現RPC灰度路由，替換併兼容掉原dubbo2訂製版在其源碼層面修改實現的灰度路由功能。

3. monitor數據指標監控

擴展Protocol、MonitorFilter、Monitor等SPI，與內部的監控中心完成對接，與dubbo2訂製版的監控邏輯保持一致。

4. ops 支援實例級

在ops層面，除了要兼容原介面級的服務管控外，還要添加實例級的服務管控。

5. 其它中間件兼容

除了dubbo本身的兼容外，內部還有部分自研的中間件也是有依賴dubbo或者跟dubbo有關聯的，還要對這些中間件進行改造升級。

4.2 遷移擴展

在dubbo3原有能力基礎上，也要另外進行擴展以提供平滑遷移的能力，我們構想的設計方案如下：

1. 擴展支援註冊中心的遷移可灰度、可管控

在dubbo3中，當consumer側應用了多個註冊中心時，默認會通過ZoneAwareCluster創建ZoneAwareClusterInvoker來進行負載均衡，參考其實現可以擴展一個Cluster實現類和一個ClusterInvoker實現類將ZoneAwareCluster替換掉，註冊中心遷移的流量管理、灰度、降級等能力都在擴展的ClusterInvoker中去實現

2. 擴展支援介面級到實例級遷移規則的全局配置管理

MigrationRule由MigrationRuleListener通過DynamicConfiguration監聽指定的應用的遷移規則，如果一個系統擁有成百上千個微服務應用時，由這種方式去管理，維護成本將會變高，我們借鑒這個方法實現了全局級別的MigrationRule管理能力。

3. 擴展遷移流量可觀測、可報警

dubbo RPC的流量監控已經有MonitorFilter和DubboMonitor實現了，只是MonitorFilter不能識別本次RPC請求的Invoker對象是通過哪個註冊中心進行服務發現的，以及該Invoke對象的服務發現模式是介面級還是實例級的；，我們在consumer側新增一個ClusterFilter介面和Filter介面去實現這個識別邏輯。

4. 遷移組件開關

在擴展的最後，要考慮遷移組件下線的問題，即使要下線也不可能再次調整業務工程將遷移組件全部從依賴中刪除掉，所以需要通過開關控制遷移組件的功能下線。

4.3 配置統一管理

在升級和遷移過程中，我們可能會隨時調整註冊中心和遷移規則的配置參數，為減少出錯的風險以及業務工程升級改動的工作量，這些公共的配置需要統一管理維護起來，dubbo3的配置中心正常能夠把這個任務較好的承接下來。

最終我們又擴展了一個配置載入的組件，通過我們公司內部的配置中心管理維護遷移組件的開關和配置中心的連接地址與超時等配置參數。有了這個組件後，新的應用可以不用擔心dubbo3和遷移的公共配置，老的應用也減少了這部分公共配置的調整工作量。

4.4 風險預案

dubbo作為一個提供底層支撐能力的微服務框架，我們始終把穩定性的要求放在首位，升級過程中任何一點意外，都可能導致線上問題，所以我們整個方案都是在面向失敗、面向風險設計的。除了在擴展的遷移組件中實現了主動降級外，也著重考慮了一些極端情況，同時為這些極端情況提供風險預案。線上環境可能會出現各種意想不到的情況，在遷移過程中需要預先思考各種風險，準備完善的應對處理預案，保證系統快速恢復。

4.5 小結

dubbo2是一個優秀的微服務框架，提供的SPI以及Extension機制能夠非常方便的讓用戶去擴展實現想要功能。dubbo3在其基礎之上，豐富了不少新的SPI，我們花了很長的時間去設計遷移方案，真正花在遷移組件上的開發時間較短。

dubbo3整體架構升級調整對於過去的服務註冊壓力也得到了解決。性能上也做了優化，架構升級後的dubbo3也更適應目前雲原生的架構，dubbo 3.1.x 版本支援sidecar和proxyless的mesh方案，而且社區也在準備開源java agent 方式的proxyless，這樣就能較好的將微服務架框的framework與數據面解耦，降低微服務框架的維護成本和升級成本。

5 社區協作

目前該項目仍然在持續升級中，我們跟社區保持著緊密的聯繫，期間碰到不少問題，都得到了社區開發同學耐⼼解答並最終給予解決。對於要升級 Dubbo3 的⽤戶，可以在社區的Github User Issue（//github.com/apache/dubbo/issues/9436） 進⾏登記，想參與社區的同學們也可以關注 Dubbo 官⽅公眾號（搜索 Apache Dubbo）了解更多關於dubbo社區的進展。

搜索關注官方微信公眾號：Apache Dubbo，了解更多業界最新動態，掌握大廠面試必備 Dubbo 技能