kl个人博客 首页>>分布式,架构>>dubbo升级2.7.4.1平滑迁移到nacos

dubbo升级2.7.4.1平滑迁移到nacos

dubbo升级2.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?
  1. 从2.5.6到2.7.x,中间修复非常多的bug,带来了非常多的新特性。
  2. 2.5.x版本不在作为一个保留维护的版本,目前主力维护的就2.6.x和2.7.x版本,还有探索版本3.0.也就是说即使2.5.x以后有问题了,官方也不会在修复了。
  3. 之所以选择2.7.4.1版本,是因为经过研究了官方issue和关注了dubbo群里的情况后,发现这个版本相对比较稳定,而且官方也推荐升级到这个版本。
为什么迁移注册中心到nacos?
  1. 目前redis注册中心虽然经过了趟坑之后《dubbo使用redis注册中心的系列问题》,趋于稳定了,但是因为太小众,使用的人太少导致很多问题并没有暴露出来(在升级的过程中又发现了一个redis注册中心的问题), 如果继续使用redis注册中心,将会一直处在不断自我趟坑的过程中无法自拔。
  2. nacos是dubbo官方主推的注册中心项目,虽然现在还在迭代磨合,但是一旦发现问题官方反应还是比较及时的。使用nacos人越来越多,相当于趟坑的人也多了,隐藏的bug就无处可藏了。而且nacos和dubbo有天生的血缘关系, 查看nacos近期的release情况,发现有几个特意修复dubbo注册的问题
  3. 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
结语
dubbo升级的方案虽然简单,但是真正升级平滑过渡不是一蹴而就的,期间还是遇到了很多问题,这是一个不断优化稳定的过程。截止目前我们还没全线铺开上生产,只是个别应用推上生产做验证,升级有风险,需要小心又谨慎
kl个人博客