本篇是 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（https://github.com/apache/dubbo/issues/9436） 進?登記，想參與社區的同學們也可以關注 Dubbo 官?公眾號（搜索 Apache Dubbo）了解更多關于dubbo社區的進展，

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

標籤：Java

上一篇：Spring Boot+Mybatis：實作資料庫登錄注冊與兩種properties配置引數讀取

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