温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

如何升级dubbo2.7.4.1版本平滑迁移到注册中心nacos

发布时间:2022-02-24 13:41:14 来源:亿速云 阅读:190 作者:iii 栏目:开发技术

这篇文章主要介绍“如何升级dubbo2.7.4.1版本平滑迁移到注册中心nacos”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“如何升级dubbo2.7.4.1版本平滑迁移到注册中心nacos”文章能帮助大家解决问题。

    前言       

    dubbo是一款非常优秀的服务治理型RPC框架,dubbo的优秀在于,庞大的架构体系、精湛的模块设计、灵活的SPI设计、丰富的组件实现,博主做微服务技术选型考察dubbo时,非常惊叹在那个年代别人就已经能够产出如此优秀的项目,以至于后面每逢别人说想要学习架构设计时,我都会推荐他读读dubbo的代码,学习下dubbo的架构设计原则。常说dubbo不仅仅是一款RPC框架,是因为他的服务治理特性相对于RPC通讯来说更加的突出,这个特性让我在2017年选型的时候果断选择了他,那个时候dubbo官方还没产出spring boot starter,而我们的项目大部分完成了从spring mvc改造到spring boot项目。为了简化开发集成dubbo组件,我们基于dubbo2.5.6版本自研了一套spring-boot-dubbo-starter组件,并且自定义dubbo服务暴露和引入的注解, 自定义了dubbo的配置装载方式。当时没有专业的运维、搭建高可用zk也费资源,为了简单方便少维护一个组件、当时我们直接选了redis(阿里云高可用实例)作为dubbo的注册中心。以上就是我们这次升级dubbo的背景情况

    为什么升级到2.7.4.1?

    从2.5.6到2.7.x,中间修复非常多的bug,带来了非常多的新特性。

    2.5.x版本不在作为一个保留维护的版本,目前主力维护的就2.6.x和2.7.x版本,还有探索版本3.0.也就是说即使2.5.x以后有问题了,官方也不会在修复了。

    之所以选择2.7.4.1版本,是因为经过研究了官方issue和关注了dubbo群里的情况后,发现这个版本相对比较稳定,而且官方也推荐升级到这个版本。

    为什么迁移注册中心到nacos?

    目前redis注册中心虽然经过了趟坑之后《dubbo使用redis注册中心的系列问题》,趋于稳定了,但是因为太小众,使用的人太少导致很多问题并没有暴露出来(在升级的过程中又发现了一个redis注册中心的问题), 如果继续使用redis注册中心,将会一直处在不断自我趟坑的过程中无法自拔。

    nacos是dubbo官方主推的注册中心项目,虽然现在还在迭代磨合,但是一旦发现问题官方反应还是比较及时的。使用nacos人越来越多,相当于趟坑的人也多了,隐藏的bug就无处可藏了。而且nacos和dubbo有天生的血缘关系, 查看nacos近期的release情况,发现有几个特意修复dubbo注册的问题

    nacos自带了web管理控制台,可以非常方便的查询dubbo的注册情况,可以作为一个简易的dubbo治理中心来使用

    两种升级方案

    由于我们目前维护了自己的spring-boot-dubbo-starter,所以在做升级时,我们产生了两种不同的升级方案,并且都做了完整的验证。

    方案一:魔改官方的starter组件

    为了做到开发侧基本无感知升级到2.7.4.1版本,我们做了两件事情

    注解兼容

    在做注解兼容时也考虑过两个方案,一个是在自研的starter上做兼容dubbo2.7.4.1的处理,一个是在官方2.7.4.1的starter上兼容我们的处理。后面果断选择了后者,因为dubbo2.7.4.1版本对于我们来说是个黑盒子不知道有哪些改动,正向兼容难度比较大,反向兼容却要容易的多。 我们将原来自研组件里的自定义注解,保留包路径完整的拷贝到官方的starter项目中,然后将 ReferenceAnnotationBeanPostProcessor和ServiceAnnotationBeanPostProcessor从dubbo的spring模块中挪了出来,做了兼容自定义注解的处理。这个地方再次夸下 dubbo的设计,dubbo在捐赠给apache后,包名都改了,为了兼容老的alibaba包下的注解,服务暴露和服务引入都做了非常简易的注解兼容设计。 得益于此,我们在做自定义注解兼容处理时非常轻松就搞定了。

    ReferenceAnnotationBeanPostProcessor的构造器传入自定义注解:

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

    ServiceAnnotationBeanPostProcessor扫描时添加自定义注解支持 

    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中的服务暴露和服务引入处理器为我们魔改的实现即可

    配置兼容

    自研的自定义配置加载以spring.dubbo.打头的,而官方是以dubbo.打头的,区别如下:

    自研的配置:
    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);
        }

    最后打包上传到私服,开发只需要升级下jar的版本,配置和代码都不用动就可以升级到2.7.4.1版本的dubbo,可能魔改的地方不止上面贴的这些代码,这里只是引出思路,这个方案到这里结束了,这个方案的优点是对开发比较透明 因为迁移到nacos的步骤是一样的,第二个方案会谈到

    方案二:直接使用官方的starter组件-最终采用的方案

    最终讨论下来,考虑到内部维护版本,当官方升级时联动升级会比较麻烦,不如,直接痛一次全线改造代码,改造配置,采用了官方的starter直接升级,这样,后面有版本升级不用在投入人力维护自研的和官方的一致。

    第一步:引入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>
    第二步:改造相关的注解

    启用dubbo时:@EnableDubbo 改成

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

    并建议添加scanBasePackages包路径,如:

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

    提高dubbo暴露服务和引入服务时的扫描速度

    服务暴露时:

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

    服务引入时:

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

    这里需要注意三点:

    1、官方的starter默认的服务引入会校验服务是否存在,不存在就抛异常,会影响应用启动,可添加全局的配置,覆盖默认行为,配置如下:dubbo.consumer.check=false

    2、自研starter中@AutowiredDubbo 的timeout等参数的单位为秒,官方注解@Reference的参数单位为毫秒,如以前配置为timeout=30, 则在官方starter中只有30毫秒的超时时间。

    3、在使用多注册中心时,dubbo会从两个注册中心同时引入服务,虽然你的URL是完全一样的,也会在本地产生两个服务实例,所以,当你的容错模式为广播模式(cluster="Broadcast")或者并行模式(cluster="Forking")时就会产生消费者一次触发,生产者收到两次的问题。而默认的集群策略为 Failover,会正常的走随机负载的方式调用,不会有这种问题。如果有广播模式、或者并行模式的使用,可以通过设置nacos注册中心,只注册不消费。配置方式如下,等所以服务都迁移到nacos上后及时移除这个配置:

    dubbo.registries.nacos.parameters.subscribe = false

    第三步:修改dubbo的配置

    去掉spring.前缀即可,注意,升级官方starter后,需要新增一个配置,用来设置redis的连接池大小,官方默认的8个, 

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

    下面示例了升级后的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注册中心

    利用dubbo支持多注册中心的功能,分两个阶段完成平滑的从redis迁移到nacos,第一阶段,全线升级修改配置为双注册中心,第二阶段,摘掉redis注册中心完成过渡,配置方式如下:

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

    注意一些问题

    使用redis注册中心时,如果只有一个redis实例,区分环境是通过redis的db来控制的,比如如下配置:

    dubbo.registry.parameters.db.index = 2

    而nacos注册中心通过命名空间来区分的,具体配置如下:

    dubbo.registry.parameters.namespace = xxxxxx

    如果是多注册中心配置,注意使用相关注册中心前缀,比如:

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

    关于“如何升级dubbo2.7.4.1版本平滑迁移到注册中心nacos”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注亿速云行业资讯频道,小编每天都会为大家更新不同的知识点。

    向AI问一下细节

    免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

    AI