前言       

dubbo是一款非常優(yōu)秀的服務(wù)治理型RPC框架，dubbo的優(yōu)秀在于，龐大的架構(gòu)體系、精湛的模塊設(shè)計(jì)、靈活的SPI設(shè)計(jì)、豐富的組件實(shí)現(xiàn)，博主做微服務(wù)技術(shù)選型考察dubbo時(shí)，非常驚嘆在那個(gè)年代別人就已經(jīng)能夠產(chǎn)出如此優(yōu)秀的項(xiàng)目,以至于后面每逢別人說(shuō)想要學(xué)習(xí)架構(gòu)設(shè)計(jì)時(shí)，我都會(huì)推薦他讀讀dubbo的代碼，學(xué)習(xí)下dubbo的架構(gòu)設(shè)計(jì)原則。常說(shuō)dubbo不僅僅是一款RPC框架，是因?yàn)樗姆?wù)治理特性相對(duì)于RPC通訊來(lái)說(shuō)更加的突出，這個(gè)特性讓我在2017年選型的時(shí)候果斷選擇了他,那個(gè)時(shí)候dubbo官方還沒(méi)產(chǎn)出spring boot starter，而我們的項(xiàng)目大部分完成了從spring mvc改造到spring boot項(xiàng)目。為了簡(jiǎn)化開(kāi)發(fā)集成dubbo組件，我們基于dubbo2.5.6版本自研了一套spring-boot-dubbo-starter組件，并且自定義dubbo服務(wù)暴露和引入的注解， 自定義了dubbo的配置裝載方式。當(dāng)時(shí)沒(méi)有專業(yè)的運(yùn)維、搭建高可用zk也費(fèi)資源，為了簡(jiǎn)單方便少維護(hù)一個(gè)組件、當(dāng)時(shí)我們直接選了redis（阿里云高可用實(shí)例）作為dubbo的注冊(cè)中心。以上就是我們這次升級(jí)dubbo的背景情況

為什么升級(jí)到2.7.4.1？

從2.5.6到2.7.x，中間修復(fù)非常多的bug，帶來(lái)了非常多的新特性。

2.5.x版本不在作為一個(gè)保留維護(hù)的版本，目前主力維護(hù)的就2.6.x和2.7.x版本，還有探索版本3.0.也就是說(shuō)即使2.5.x以后有問(wèn)題了，官方也不會(huì)在修復(fù)了。

之所以選擇2.7.4.1版本，是因?yàn)榻?jīng)過(guò)研究了官方issue和關(guān)注了dubbo群里的情況后，發(fā)現(xiàn)這個(gè)版本相對(duì)比較穩(wěn)定，而且官方也推薦升級(jí)到這個(gè)版本。

為什么遷移注冊(cè)中心到nacos？

目前redis注冊(cè)中心雖然經(jīng)過(guò)了趟坑之后《dubbo使用redis注冊(cè)中心的系列問(wèn)題》，趨于穩(wěn)定了，但是因?yàn)樘”?，使用的人太少?dǎo)致很多問(wèn)題并沒(méi)有暴露出來(lái)（在升級(jí)的過(guò)程中又發(fā)現(xiàn)了一個(gè)redis注冊(cè)中心的問(wèn)題）， 如果繼續(xù)使用redis注冊(cè)中心，將會(huì)一直處在不斷自我趟坑的過(guò)程中無(wú)法自拔。

nacos是dubbo官方主推的注冊(cè)中心項(xiàng)目，雖然現(xiàn)在還在迭代磨合，但是一旦發(fā)現(xiàn)問(wèn)題官方反應(yīng)還是比較及時(shí)的。使用nacos人越來(lái)越多，相當(dāng)于趟坑的人也多了，隱藏的bug就無(wú)處可藏了。而且nacos和dubbo有天生的血緣關(guān)系， 查看nacos近期的release情況，發(fā)現(xiàn)有幾個(gè)特意修復(fù)dubbo注冊(cè)的問(wèn)題

nacos自帶了web管理控制臺(tái)，可以非常方便的查詢dubbo的注冊(cè)情況，可以作為一個(gè)簡(jiǎn)易的dubbo治理中心來(lái)使用

兩種升級(jí)方案

由于我們目前維護(hù)了自己的spring-boot-dubbo-starter，所以在做升級(jí)時(shí)，我們產(chǎn)生了兩種不同的升級(jí)方案，并且都做了完整的驗(yàn)證。

方案一：魔改官方的starter組件

為了做到開(kāi)發(fā)側(cè)基本無(wú)感知升級(jí)到2.7.4.1版本，我們做了兩件事情

注解兼容

在做注解兼容時(shí)也考慮過(guò)兩個(gè)方案，一個(gè)是在自研的starter上做兼容dubbo2.7.4.1的處理，一個(gè)是在官方2.7.4.1的starter上兼容我們的處理。后面果斷選擇了后者，因?yàn)閐ubbo2.7.4.1版本對(duì)于我們來(lái)說(shuō)是個(gè)黑盒子不知道有哪些改動(dòng)，正向兼容難度比較大，反向兼容卻要容易的多。 我們將原來(lái)自研組件里的自定義注解，保留包路徑完整的拷貝到官方的starter項(xiàng)目中，然后將 ReferenceAnnotationBeanPostProcessor和ServiceAnnotationBeanPostProcessor從dubbo的spring模塊中挪了出來(lái)，做了兼容自定義注解的處理。這個(gè)地方再次夸下 dubbo的設(shè)計(jì)，dubbo在捐贈(zèng)給apache后，包名都改了，為了兼容老的alibaba包下的注解，服務(wù)暴露和服務(wù)引入都做了非常簡(jiǎn)易的注解兼容設(shè)計(jì)。 得益于此，我們?cè)谧鲎远x注解兼容處理時(shí)非常輕松就搞定了。

ReferenceAnnotationBeanPostProcessor的構(gòu)造器傳入自定義注解：

public ReferenceAnnotationBeanPostProcessor() {
        super(AutowiredDubbo.class, Reference.class, com.alibaba.dubbo.config.annotation.Reference.class);
    }

ServiceAnnotationBeanPostProcessor掃描時(shí)添加自定義注解支持 

scanner.addIncludeFilter(new AnnotationTypeFilter(Service.class));
        /**
         * Add the compatibility for legacy Dubbo's @Service
         *
         * The issue : https://github.com/apache/dubbo/issues/4330
         * @since 2.7.3
         */
        scanner.addIncludeFilter(new AnnotationTypeFilter(com.alibaba.dubbo.config.annotation.Service.class));
        // 兼容@DubboService注解
        scanner.addIncludeFilter(new AnnotationTypeFilter(DubboService.class));

最后修改DubboAutoConfiguration中的服務(wù)暴露和服務(wù)引入處理器為我們魔改的實(shí)現(xiàn)即可

配置兼容

自研的自定義配置加載以spring.dubbo.打頭的，而官方是以dubbo.打頭的，區(qū)別如下：

自研的配置：
spring.dubbo.application.name = xxx
spring.dubbo.registry.address = xxx
spring.dubbo.protocol.port = -1
官方starter配置
dubbo.application.name = xxx
dubbo.registry.address = xxx
dubbo.protocol.port = -1

為了做到配置兼容，修改了dubbo starter配置加載邏輯，去掉了spring.打頭，修改DubboUtils中的filterDubboProperties，如：

public static SortedMap filterDubboProperties(ConfigurableEnvironment environment) {
        SortedMap dubboProperties = new TreeMap<>();
        Map properties = EnvironmentUtils.extractProperties(environment);
        for (Map.Entry entry : properties.entrySet()) {
            String propertyName = entry.getKey();
            if (propertyName.startsWith(DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR)
                    && entry.getValue() != null) {
                dubboProperties.put(propertyName, entry.getValue().toString());
            }
            if (propertyName.startsWith("spring." + DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR)
                    && entry.getValue() != null) {
                propertyName = propertyName.substring(7);
                dubboProperties.put(propertyName, entry.getValue().toString());
            }
        }
        return Collections.unmodifiableSortedMap(dubboProperties);
    }

最后打包上傳到私服，開(kāi)發(fā)只需要升級(jí)下jar的版本，配置和代碼都不用動(dòng)就可以升級(jí)到2.7.4.1版本的dubbo，可能魔改的地方不止上面貼的這些代碼，這里只是引出思路，這個(gè)方案到這里結(jié)束了，這個(gè)方案的優(yōu)點(diǎn)是對(duì)開(kāi)發(fā)比較透明 因?yàn)檫w移到nacos的步驟是一樣的，第二個(gè)方案會(huì)談到

方案二：直接使用官方的starter組件-最終采用的方案

最終討論下來(lái)，考慮到內(nèi)部維護(hù)版本，當(dāng)官方升級(jí)時(shí)聯(lián)動(dòng)升級(jí)會(huì)比較麻煩，不如，直接痛一次全線改造代碼，改造配置，采用了官方的starter直接升級(jí)，這樣，后面有版本升級(jí)不用在投入人力維護(hù)自研的和官方的一致。

第一步：引入maven依賴

官方dubbo starter依賴

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>2.7.4.1</version>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>1.1.3</version>
</dependency>
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

第二步：改造相關(guān)的注解

啟用dubbo時(shí)：@EnableDubbo 改成

@EnableDubbo【org.apache.dubbo.config.spring.context.annotation.EnableDubbo】

并建議添加scanBasePackages包路徑，如：

@EnableDubbo(scanBasePackages = "cn.keking.service")。

提高dubbo暴露服務(wù)和引入服務(wù)時(shí)的掃描速度

服務(wù)暴露時(shí)：

@DubboService 改成 @Service 【org.apache.dubbo.config.annotation.Service】

服務(wù)引入時(shí)：

@AutowiredDubbo 改成 @Reference 【org.apache.dubbo.config.annotation.Reference】，

這里需要注意三點(diǎn)：

1、官方的starter默認(rèn)的服務(wù)引入會(huì)校驗(yàn)服務(wù)是否存在，不存在就拋異常，會(huì)影響應(yīng)用啟動(dòng)，可添加全局的配置，覆蓋默認(rèn)行為，配置如下：dubbo.consumer.check=false

2、自研starter中@AutowiredDubbo 的timeout等參數(shù)的單位為秒，官方注解@Reference的參數(shù)單位為毫秒，如以前配置為timeout=30, 則在官方starter中只有30毫秒的超時(shí)時(shí)間。

3、在使用多注冊(cè)中心時(shí)，dubbo會(huì)從兩個(gè)注冊(cè)中心同時(shí)引入服務(wù)，雖然你的URL是完全一樣的，也會(huì)在本地產(chǎn)生兩個(gè)服務(wù)實(shí)例，所以，當(dāng)你的容錯(cuò)模式為廣播模式（cluster="Broadcast"）或者并行模式（cluster="Forking"）時(shí)就會(huì)產(chǎn)生消費(fèi)者一次觸發(fā)，生產(chǎn)者收到兩次的問(wèn)題。而默認(rèn)的集群策略為 Failover，會(huì)正常的走隨機(jī)負(fù)載的方式調(diào)用，不會(huì)有這種問(wèn)題。如果有廣播模式、或者并行模式的使用，可以通過(guò)設(shè)置nacos注冊(cè)中心，只注冊(cè)不消費(fèi)。配置方式如下，等所以服務(wù)都遷移到nacos上后及時(shí)移除這個(gè)配置：

dubbo.registries.nacos.parameters.subscribe = false

第三步：修改dubbo的配置

去掉spring.前綴即可，注意，升級(jí)官方starter后，需要新增一個(gè)配置，用來(lái)設(shè)置redis的連接池大小，官方默認(rèn)的8個(gè)， 

dubbo.registries.redis.parameters.max.total = 200

下面示例了升級(jí)后的dubbo配置：

dubbo.application.name = xxx
dubbo.protocol.port = -1
dubbo.provider.timeout = 300000
dubbo.consumer.check = false
dubbo.registries.nacos.address = nacos://xxx:80
dubbo.registries.redis.address = redis://xxx:6379
dubbo.registries.redis.parameters.max.total = 200

平滑遷移到nacos注冊(cè)中心

利用dubbo支持多注冊(cè)中心的功能，分兩個(gè)階段完成平滑的從redis遷移到nacos，第一階段，全線升級(jí)修改配置為雙注冊(cè)中心，第二階段，摘掉redis注冊(cè)中心完成過(guò)渡，配置方式如下：

dubbo.registries.nacos.address=nacos://xxx:80
dubbo.registries.redis.address=redis://xx:6379

注意一些問(wèn)題

使用redis注冊(cè)中心時(shí)，如果只有一個(gè)redis實(shí)例，區(qū)分環(huán)境是通過(guò)redis的db來(lái)控制的，比如如下配置：

dubbo.registry.parameters.db.index = 2

而nacos注冊(cè)中心通過(guò)命名空間來(lái)區(qū)分的，具體配置如下：

dubbo.registry.parameters.namespace = xxxxxx

如果是多注冊(cè)中心配置，注意使用相關(guān)注冊(cè)中心前綴，比如：

dubbo.registries.nacos.parameters.namespace=adefa98f-f4d9-4af8-9eb3-e0cab5a39cc7

結(jié)語(yǔ)

dubbo升級(jí)的方案雖然簡(jiǎn)單，但是真正升級(jí)平滑過(guò)渡不是一蹴而就的，期間還是遇到了很多問(wèn)題，這是一個(gè)不斷優(yōu)化穩(wěn)定的過(guò)程。截止目前我們還沒(méi)全線鋪開(kāi)上生產(chǎn)，只是個(gè)別應(yīng)用推上生產(chǎn)做驗(yàn)證，升級(jí)有風(fēng)險(xiǎn)，需要小心又謹(jǐn)慎

以上就是升級(jí)dubbo2.7.4.1版本平滑遷移到注冊(cè)中心nacos的詳細(xì)內(nèi)容，更多關(guān)于dubbo遷移到nacos的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論