本篇內(nèi)容介紹了“平滑遷移Dubbo服務(wù)的過程是怎樣的”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

在濟寧等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供做網(wǎng)站、網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作按需求定制制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計,成都全網(wǎng)營銷,外貿(mào)網(wǎng)站制作,濟寧網(wǎng)站建設(shè)費用合理。

Consul 開源版是否收到影響？

上面的條款里只提到了商業(yè)軟件，那么開源的 Consul 是否受到影響呢？在 Github 的 Consul 倉庫上，可以得知項目的 license 是 Mozilla Public License 2.0 ，這款許可證在 Apache 官網(wǎng)上是 Category B , 屬于 Weak Copy Left 許可，那么它有哪些特點呢？

1. 任何可以使用，復(fù)制，修改，重新分發(fā)該代碼，包括商業(yè)目的使用。

2. 如果修改了 MPL 協(xié)議許可下的源碼，再重新發(fā)布這部分源碼的話，必須保留原來 MPL 許可證不得更換。

3. 如果基于該項目衍生出更大的項目，那么這部分工作可以使用新許可證的方式進行分發(fā)，只要沒有修改原來 MPL 許可下的代碼。（這也是為什么 Apache 項目的分發(fā)的源碼中可以包含 MPL 協(xié)議下二進制文件的原因）

可以看到，MPL 通常被認為是介于 Apache License 和 GPL/LGPL 之間的一個折中方案。相對于 Apache License，MPL 2.0 要求修改了源碼必須保持相同協(xié)議；相對于 GPL/LGPL, MPL 2.0 可以商用，同時衍生的作品在一定條件下也可以更換許可證類型。

總體來看的話，開源版 Consul 無論是私用還是商用都是不受限制的。但這也可能是一個警鐘，如果對 Consul 還是有所顧忌的話，如何替代掉它呢？

在微服務(wù)領(lǐng)域，Consul 主要被用來做充當(dāng)注冊中心和配置中心，例如 Dubbo 和 SpringCloud 都有對應(yīng)的支持。本文便以這個事為一個引子，介紹如何平滑地遷移 Dubbo 服務(wù)，達到替換注冊中心的效果。

平滑遷移服務(wù)的定義和意義

如果 Dubbo 應(yīng)用已經(jīng)部署到生產(chǎn)環(huán)境并處于正常運行狀態(tài)中，此時想將應(yīng)用的注冊中心替換，那么在遷移過程中，保證業(yè)務(wù)的平穩(wěn)運行不中斷一定是第一要義。我們將保證應(yīng)用運行不中斷，并最終達成注冊中心替換的過程稱為平滑遷移?？梢灶惐葹榻o飛行中的飛機替換引擎，在項目升級、框架調(diào)整等很多時候，現(xiàn)狀和終態(tài)之間往往都有一個過度方案。

• 平滑遷移可以避免終態(tài)方案一次性上線后出現(xiàn)和原有方案的不兼容性，規(guī)避了整體回歸的風(fēng)險

• 沒有哪個互聯(lián)網(wǎng)公司可以承擔(dān)的起：“自 xx 至 xx，系統(tǒng)維護一小時，期間服務(wù)將無法提供，請廣大用戶諒解” 這種停機升級方案。

平滑遷移過程

說到注冊中心遷移，可能很多人第一時間都能想到雙注冊雙訂閱這種方案

雙注冊和雙訂閱遷移方案是指在應(yīng)用遷移時同時接入兩個注冊中心（原有注冊中心和新注冊中心）以保證已遷移的應(yīng)用和未遷移的應(yīng)用之間的相互調(diào)用。

以 Consul 遷移到 Nacos 為例：

在遷移態(tài)下，一共有兩種應(yīng)用類型：未遷移應(yīng)用，遷移中應(yīng)用。我們所說的雙注冊雙訂閱都是指的【遷移中應(yīng)用】。明白下面幾個點，平滑遷移的過程一下子就清晰了：

• 【未遷移應(yīng)用】不做任何改動

• 為了讓【未遷移應(yīng)用】調(diào)用到【遷移中應(yīng)用】，要求【遷移中應(yīng)用】不僅要將數(shù)據(jù)寫到 Nacos，還要寫回舊的 Consul，這是雙注冊

• 為了讓【遷移中應(yīng)用】調(diào)用到【未遷移應(yīng)用】，要求【遷移中應(yīng)用】不僅要訂閱 Nacos 的數(shù)據(jù)，還要監(jiān)聽舊的 Consul，這是雙訂閱

• 當(dāng)所有應(yīng)用變成【遷移中應(yīng)用】時，舊的 Consul 就可以光榮下崗了，至此平滑遷移完成。

在這個過程中，還可以靈活的變換一些規(guī)則，例如在遷移中后期，大部分應(yīng)用在 Nacos 中已經(jīng)有服務(wù)了，可以切換雙訂閱為單訂閱，以驗證遷移情況。并且在真實場景下，還會并存配置中心、元數(shù)據(jù)中心的遷移，過程會更加復(fù)雜。

Dubbo 平滑遷移方案 -- 多注冊中心

Dubbo 多注冊中心配置文檔地址：http://dubbo.apache.org/zh-cn/docs/user/demos/multi-registry.html

本文的完整代碼示例將會在文末提供，其中 Consul 注冊中心搭建在本地，而 Nacos 注冊中心使用的是阿里云的云產(chǎn)品：微服務(wù)引擎 MSE，其可以提供托管的 Nacos/Zookeeper/Eureka 等集群。

Dubbo 支持多注冊中心的配置，這就為我們平滑遷移提供了很多的便利性。在使用 dubbo-spring-boot-starter 時，只需要增加如下的配置，即可配置多注冊中心：

dubbo.registries.first.protocol=consul
dubbo.registries.first.address=localhost:8500

dubbo.registries.second.protocol=nacos
dubbo.registries.second.address=mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

在 Consul 控制臺可以看到服務(wù)已經(jīng)注冊成功：

在 MSE 控制臺可以看到 Nacos 服務(wù)也已經(jīng)注冊成功

并且，服務(wù)調(diào)用一切正常。你可能會想：前面講了一堆，你告訴我改了兩行配置就是平滑遷移了？我還是得好好糾正下這種想法，改代碼從來都是最輕松的事，難的是在遷移中，時刻觀察業(yè)務(wù)狀況，確保服務(wù)不因為遷移有損。除此之外，還需要注意的是，Dubbo 自帶的多注冊中心方案因為框架實現(xiàn)的問題，存在一定的缺陷。

Dubbo 多注冊中心的缺陷

在 Dubbo 的實現(xiàn)中，多個注冊中心的地址是隔離的，地址不會融合。也就是說，當(dāng)消費者如下配置后：

dubbo.registries.first.protocol=consul
dubbo.registries.first.address=localhost:8500

dubbo.registries.second.protocol=nacos
dubbo.registries.second.address=mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

會永遠優(yōu)先從 Consul 中讀取服務(wù)地址，除非 Consul 中沒有服務(wù)，才會嘗試從 Nacos 中讀取，順序取決于配置文件中注冊中心聲明的先后。這可能不符合大多數(shù)人對多注冊中心的直觀認知，但沒辦法，Dubbo 就是這么設(shè)計的，我也嘗試猜想了幾個這么設(shè)計的可能性：

• 多個注冊中心沒有感知到對方存在的必要，所以只能串行讀取多個注冊中心

• Dubbo 本身模型不支持注冊中心聚合，除非專門搞一個 AggregationRegistry 代理多個注冊中心實現(xiàn)

• 多個注冊地址的 equals 方案難以確定，官方?jīng)]有給出契約規(guī)范，即 ip 和 port 相同就可以認為同一個地址嗎？

• Dubbo 的多注冊中心的設(shè)計并不只是為了適配平滑遷移方案，其他場景可能恰恰希望使用這種串行讀取的策略

為了讓讀者有一個直觀的感受，我用文末的 demo 進行了測試，讓服務(wù)提供者 A1（端口號 12346） 只注冊到 Nacos，服務(wù)提供者 A2（端口號為 12345） 只注冊到 Consul，消費者 B 雙訂閱 Nacos 和 Consul。如下圖所示，在測試初期，可以發(fā)現(xiàn)，穩(wěn)定調(diào)用到 A1；期間，我手動 kill 了 A1，圖中也清晰地打印出了一條地址下線通知，之后穩(wěn)定調(diào)用到 A2。

這樣的缺陷，會導(dǎo)致我們在平滑遷移過程中無法對未遷移應(yīng)用和遷移中應(yīng)用進行充分的測試。

Dubbo 平滑遷移方案 -- 注冊中心聚合

注冊中心聚合這個詞其實是我自己想的，因為 Dubbo 官方文檔并沒有直接給出這種方案，而是由阿里云的微服務(wù)商業(yè)化 EDAS 團隊提供的開源實現(xiàn)（ps，沒錯，就是我所在的團隊啦）。其基本思路就是前文提到的，聚合多個注冊中心的地址。使用方式也同樣簡單

引入依賴：

   com.alibaba.edas
   edas-dubbo-migration-bom
   2.6.5.1
   pom

增加配置：

在 application.properties 中添加注冊中心的地址。

dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=consul://localhost:8500,nacos://mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848&reference-registry=consul://localhost:8500,nacos://mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

說明 如果是非 Spring Boot 應(yīng)用，在 dubbo.properties 或者對應(yīng)的 Spring 配置文件中配置。

• edas-migration://30.5.124.15:9999
  

  多注冊中心的頭部信息。可以不做更改，ip 和 port 可以任意填寫，主要是為了兼容 Dubbo 對 ip 和 port 的校驗。啟動時，如果日志級別是 WARN 及以下，可能會拋一個 WARN 的日志，可以忽略。

• service-registry
  

  服務(wù)注冊的注冊中心地址。寫入多個注冊中心地址。每個注冊中心都是標(biāo)準(zhǔn)的 Dubbo 注冊中心格式；多個用,分隔。

• reference-registry
  

  服務(wù)訂閱的注冊中心地址。每個注冊中心都是標(biāo)準(zhǔn)的 Dubbo 注冊中心格式；多個用,分隔。

驗證該方案：

已經(jīng)變成了隨機調(diào)用，解決了多注冊中心的缺陷。

遷移完成后，建議刪除原注冊中心的配置和遷移過程專用的依賴edas-dubbo-migration-bom，在業(yè)務(wù)量較小的時間分批重啟應(yīng)用。edas-dubbo-migration-bom 是一個遷移專用的依賴，雖然長期使用對您業(yè)務(wù)的穩(wěn)定性沒有影響，但其并不會跟隨 Dubbo 的版本進

“平滑遷移Dubbo服務(wù)的過程是怎樣的”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！