这篇文章主要介绍“如何升级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.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群里的情况后,发现这个版本相对比较稳定,而且官方也推荐升级到这个版本。
目前redis注册中心虽然经过了趟坑之后《dubbo使用redis注册中心的系列问题》,趋于稳定了,但是因为太小众,使用的人太少导致很多问题并没有暴露出来(在升级的过程中又发现了一个redis注册中心的问题), 如果继续使用redis注册中心,将会一直处在不断自我趟坑的过程中无法自拔。
nacos是dubbo官方主推的注册中心项目,虽然现在还在迭代磨合,但是一旦发现问题官方反应还是比较及时的。使用nacos人越来越多,相当于趟坑的人也多了,隐藏的bug就无处可藏了。而且nacos和dubbo有天生的血缘关系, 查看nacos近期的release情况,发现有几个特意修复dubbo注册的问题
nacos自带了web管理控制台,可以非常方便的查询dubbo的注册情况,可以作为一个简易的dubbo治理中心来使用
由于我们目前维护了自己的spring-boot-dubbo-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直接升级,这样,后面有版本升级不用在投入人力维护自研的和官方的一致。
官方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
去掉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
利用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”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注亿速云行业资讯频道,小编每天都会为大家更新不同的知识点。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。