本篇是 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%左右。
壓測環境：
| 類別 | 版本 | 機器配置 |
|---|---|---|
| Provider | dubbo 3.0.4 | 4C8G |
| Consumer | dubbo 3.0.4 | 4C8G |
| Provider | dubbo 2.5.3.22(基於2.5.3版本定製) | 4C8G |
| Consumer | dubbo 2.5.3.222(基於2.5.3版本定製) | 4C8G |
測試場景：
使用的是Dubbo協議，介面沒有其它邏輯，直接將輸入返回給消費者, 介面資料包大小500B，每個場景壓30分鐘。
測試資料 (僅供參考)：
3.2 升級前調研
做了壓測得到dubbo2和dubbo3的壓測資料後，我們開始計劃將 Dubbo3 引入公司進行試點，此時，我們需要考慮dubbo3與dubbo2的相容和遷移重構問題，升級目標，以及dubbo3提供有哪些能力支援升級和遷移。
3.2.1 升級的相容和遷移重構問題
考慮到公司的系統規模，要將dubbo2升級到dubbo3卻不是一個簡單的過程，尤其是公司的dubbo2版本在原開源版本基礎之上做了不少最佳化和擴充套件，涵蓋了ops服務治理、monitor資料指標監控、服務註冊和發現、RPC灰度路由、鏈路分析、序列化編解碼、作為其他基礎框架的底層支援等多個方面，同時dubbo3社群也處於活躍的狀態，我們也希望能夠持續享受dubbo社群的技術紅利，在這樣的背景下不得不考慮三個問題：
- 需要解決公司版本的dubbo2與dubbo3的相容問題；
- 原有功能的遷移重構問題；
- 不在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的方式單獨維護，實現相容的擴充套件功能主要有如下內容：
- RPC 正向透遞與反向透傳
在consumer側和provider側擴充套件Filter介面實現類，為正向與反向透傳資料實現其傳送和接收的功能。Dubbo2定製版是在序列化編解碼層面對RpcResult進行了修改，要相容這一邏輯也只能在序列化編解碼層面去支援，採用Wrapper模式對Codec2這個SPI進行增強，與其它擴充套件類一併實現該相容功能。
- RPC 灰度路由
擴充套件Dubbo 的Router、 Cluster和ConfiguratorFactory等SPI，與內部的eunomia灰度管控平臺整合實現RPC灰度路由，替換併相容掉原dubbo2定製版在其原始碼層面修改實現的灰度路由功能。
- monitor資料指標監控
擴充套件Protocol、MonitorFilter、Monitor等SPI，與內部的監控中心完成對接，與dubbo2定製版的監控邏輯保持一致。
- ops 支援例項級
在ops層面，除了要相容原介面級的服務管控外，還要新增例項級的服務管控。
- 其它中介軟體相容
除了dubbo本身的相容外，內部還有部分自研的中介軟體也是有依賴dubbo或者跟dubbo有關聯的，還要對這些中介軟體進行改造升級。
4.2 遷移擴充套件
在dubbo3原有能力基礎上，也要另外進行擴充套件以提供平滑遷移的能力，我們構想的設計方案如下：
- 擴充套件支援註冊中心的遷移可灰度、可管控
在dubbo3中，當consumer側應用了多個註冊中心時，預設會透過ZoneAwareCluster建立ZoneAwareClusterInvoker來進行負載均衡，參考其實現可以擴充套件一個Cluster實現類和一個ClusterInvoker實現類將ZoneAwareCluster替換掉，註冊中心遷移的流量管理、灰度、降級等能力都在擴充套件的ClusterInvoker中去實現
- 擴充套件支援介面級到例項級遷移規則的全域性配置管理
MigrationRule由MigrationRuleListener透過DynamicConfiguration監聽指定的應用的遷移規則，如果一個系統擁有成百上千個微服務應用時，由這種方式去管理，維護成本將會變高，我們借鑑這個方法實現了全域性級別的MigrationRule管理能力。
- 擴充套件遷移流量可觀測、可報警
dubbo RPC的流量監控已經有MonitorFilter和DubboMonitor實現了，只是MonitorFilter不能識別本次RPC請求的Invoker物件是透過哪個註冊中心進行服務發現的，以及該Invoke物件的服務發現模式是介面級還是例項級的；，我們在consumer側新增一個ClusterFilter介面和Filter介面去實現這個識別邏輯。
- 遷移元件開關
在擴充套件的最後，要考慮遷移元件下線的問題，即使要下線也不可能再次調整業務工程將遷移元件全部從依賴中刪除掉，所以需要透過開關控制遷移元件的功能下線。
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 技能