*作者：劉軍*

中崙網路在 2022 年完成了服務框架從 Dubbo 2 到 Dubbo 3 的全站升級，深度使用了應用級服務發現、Kubernetes 原生服務部署、服務治理等核心能力。來自中崙網路的技術負責人來彬彬對整個 Dubbo 3 的選型、升級過程及收益等做了深入總結。

> *來彬彬，2020 年加入蘇州中崙網路科技有限公司，擔任架構部負責人/高階架構師，十四年架構開發經驗。曾任職於蘇寧易購七年參與商戶平臺、物流四方服務平臺等架構設計，為使用者提供億級 SaaS 服務。現重點保障中臺化實施、效能最佳化、業務架構、穩定性等，專注零售行業、網際網路、雲端計算、架構設計。*

值得一提的是近期 Dubbo 3 官網文件 整體有了本質的提升，並且社群承諾短期內文件還會投入大量精力完善文件，這點對於 Dubbo 3 的使用和使用者信心提升非常重要。

## 公司業務與技術架構簡介

蘇州中崙網路科技有限公司是一家“專注零售門店增收服務”的公司，一直以“解決中小零售門店經營難的問題”為初心，致力於為零售商戶提供門店運營一體化解決方案，幫助零售門店實現增收。中崙網路以零售技術為核心，為零售商戶打造出集收銀系統、中崙掌櫃、微商城、匯鄰生活平臺、大資料平臺、移動支付、智慧農貿、匯鄰門店運營服務等為一體的新零售生態體系，實現線上線下全方位融合，為零售商家賦能增收。技術團隊在構建之初選取 Dubbo 2.5.3+Zookeeper 版本構建公司微服務基座支撐公司業務發展，後期同阿里雲深度合作整體遷移使用阿里雲，使用雲原生基礎設施 ACK（Kubernetes）+MSE（Zookeeper）+Dubbo+PolarDB 等構建，實現可動態縮擴容的服務能力。

伴隨合作商擴充套件 3000+，市場遍及 300+城市，零售商戶 30 萬+，服務覆蓋餐飲、茶飲、服裝、母嬰、烘焙、生鮮、商超、美業、美妝、寵物等多個行業。伴隨著領域拓寬、商戶量快速增長上升，系統數量和部署節點也迎來了暴增，隨之在系統可用性上受到較大挑戰：微服務治理能力、微服務地址註冊發現，Kubernetes 平臺服務的無損上下線順滑度上問題與挑戰越來越多。架構圖見圖一。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dc8da2d1c0c44768ae7a85ce2b14998d~tplv-k3u1fbpfcp-zoom-1.image "1.png")

圖一

## Dubbo 3 升級總結

在升級微服務元件技術選型上主要考慮解決以前的痛點：服務治理能力、雲原生友好性、服務註冊發現，這幾個制約業務發展的緊要問題。比較下來 Dubbo 3 架構設計理念與我們較為契合，能較好的滿足我們業務發展要求。

### 1、服務治理能力

Dubbo 3 提供豐富的服務治理能力，可實現諸如服務發現、負載均衡、流量排程等服務治理訴求。在使用上我們有兩種選擇：

-   使用 Dubbo 管理控制檯管理配置

-   整合相關 API 能力到系統

同時 Dubbo 擴充套件性較好，可以在很多功能點（見圖二）去定製自己的實現，以改變框架的預設行為來滿足自己的業務需求。

Dubbo  SPI ( Service Provider Interface)將介面實現類的全限定名配置在檔案中，並由服務載入器讀取配置檔案，載入實現類。這樣可以在執行時，動態為介面替換實現類。基於此特性，我們可以很容易的透過 SPI 機制為我們的程式提供擴充功能，如我們在此基礎上實現了基於生產和消費者過濾器 Filter 實現全鏈路自定義的鏈路監控;基於路由擴充套件標籤路由方式進行測試環境的隔離方便快速多版本服務測試驗證。實操上我們基於生產者註冊服務時打標，如原系統 A  V1 版本部署在 fat 環境上，現在為了測試 V2 版本，我們將 V2 版本打標 tag=fat-v2；使用端在消費時指定 Invocation Attachment  引數，inv.setAttachment(TAG_KEY, routeTag)；基於此我們可以方便自測試，同時生產上我們也可以做簡單的生產灰度運用。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb992d89e93a4ac98d0a0e3f62778c1c~tplv-k3u1fbpfcp-zoom-1.image "2.png")

圖二

### 2、雲原生友好性

Dubbo 在設計上遵循雲原生微服務開發理念，微服務支援 Kubernetes 平臺排程，實現服務生命週期與容器生命週期的對齊，包括 Dubbo 的啟動、銷燬、服務註冊等生命週期事件。中崙網路微服務管理使用的是 MSE（Zookeeper）,因而我們服務暴露使用需與之對齊。具體操作上我們自定義 Startup 啟動探針、 Liveness 存活探針、Readiness 就緒探針。專案的正常切換需要保障無損的上下線，在實施中無損上線相對於下線來說會更麻煩點，專案的釋出上線過程大體會遵從如下流程（大致分成三個階段）：

第一階段升級少量（如 20% ）的例項，並切換少量流量到新版本，完成這個階段後先暫停升級。

經過人工確認之後繼續第二個階段，升級更大比例（如 90% ）的例項和流量，再次暫停等待人工確認。

最後階段將全量升級到新版本並驗證完畢，從而完成整個釋出過程。如果升級期間發現包括業務指標在內的任何異常，例如 CPU 或 memory 異常使用率升高或請求 500 日誌過多等情況，可以快速回滾。

因為我們使用的是 MSE（Zookeeper）服務，Dubbo 服務自注冊在應用啟動過程暴露不受 Kubernetes 生命週期的控制，出現專案未完全就緒部分服務可被提前可被訪問問題。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1ac1139e4a6940e29002bd65771927f8~tplv-k3u1fbpfcp-zoom-1.image "3.png")

圖三

實施處理上我們主要利用 Dubbo Qos 指令,初始使用服務不暴露，在應用就緒後呼叫 Qos online 指令進行服務上線替換老節點，每次替換的節點數量基於釋出策略來制定;下線過程針對需下線節點我們會先使用 Qos 指令進行下線 offline 操作等待應用執行完服務，從而進行優雅停機，從實踐的效果來看能滿足我們的生產需求。

### 3、例項級別升級切換

相比於 2.x 版本中的基於介面粒度的服務發現機制，3.x 引入了全新的基於應用粒度的服務發現機制，進一步提升了 Dubbo 3 在大規模叢集實踐中的效能與穩定性。此次升級過程中我們也同步引入了配置中心與原資料中心，即將圖四置灰部分啟用：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2e905de0efd44d7a1b2a146bc8bb161~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖四

採用例項級別註冊管理，一個應用 N 個服務，介面級時 N 服務需監聽推送，應用級只關注單例項相關資訊。同時引入後設資料中心後極大降低介面配置資料資訊，減少介面資料傳輸大小，相關職責配置也更加清晰。根據測試新模型大幅提高系統資源利用率，降低 Dubbo 地址的單機記憶體消耗，大幅降低註冊中心叢集的儲存與推送壓力，上線後穩定性有較大的提升。

## 總結與展望

在中崙網路 Dubbo 2 升級 Dubbo 3 的過程中我們也有過一些遲疑，如把介面級換成應用級還是混合註冊；Dubbo 3.0 新特性新技術在專案中引入的時機與範圍。對公司來說大的升級意味風險和不可預知的問題，但同時也能為之帶來資源利用率提升、基礎功能的擴充套件與增強，作為技術人員我們需要反覆謹慎評估與論證。現在我們已經完成切換所有的業務領域。

## Dubbo 社群合作

在這裡再次感謝 Dubbo 社群人員的專業、高效，以及對中崙網路架構升級的大力支援，同時很榮幸能夠成為一名社群的貢獻者，感興趣的同學可以加入貢獻者釘釘群：31982034。

Dubbo 社群近期籌辦了每週一次的微服務純技術分享，講解 Dubbo 使用、原始碼，同時涵蓋眾多雲原生微服務知識，感興趣的同學可關注 Apache Dubbo 公眾號。

MSE 註冊配置首購 8 折，首購 1 年及以上 7 折。MSE 雲原生閘道器預付費全規格享 9 折優惠。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠。

中崙網路全站 Dubbo 2 遷移 Dubbo 3 總結

相關文章