dubbo is a very good type RPC service management framework, dubbo outstanding that huge system architecture, exquisite modular design, flexible SPI design, implement rich component, micro-bloggers do service technology selection study dubbo time, was amazed at that time people have been able to grow such excellent project that behind every people say when you want to study architecture, I would recommend him to read dubbo code, learning architecture design principles under the dubbo. Often said dubbo not just a RPC framework, because of his service governance characteristics of the more prominent RPC communication is relative, this feature let me in 2017, when the selection decisively chose him, at that time the official did not dubbo output spring boot starter, and our project largely completed the transformation from spring mvc to spring boot project. In order to simplify the development of integrated dubbo components, based on our research dubbo2.5.6 version from a set of spring-boot-dubbo-starter components, and custom dubbo service exposure and the introduction of notes, customized dubbo configuration reload mode. There was no professional operation and maintenance, to build high availability zk have spent resources, in order to maintain a few simple components, we were directly elected redis (Ali cloud high availability instance) as a registration center dubbo of. And that this time we upgrade the background dubbo
Why upgrade to 2.7.4.1?
- From 2.5.6 to 2.7.x, intermediate fix a lot of bug, brought a lot of new features.
- 2.5.x version is not retained as a maintenance version, 2.6.x and 2.7.x versions, as well as explore the current version of the main maintenance on 3.0. In other words, even if there is a problem in the future 2.5.x, the official will not repair a.
- 2.7.4.1 version was chosen, because after study after official issue and focus on the dubbo the group's situation and found that this version is relatively stable, but the government has also recommended to upgrade to this version.
Why migrate registry to nacos?
- Currently redis registry after even after a trip pit "dubbo redis registry using a series of problems," stable, but because the public is too small, too few people use and do not cause a lot of problems exposed (in the process of upgrading I discovered a problem redis registry), if it continues to use redis registry, will always be in the process of continuous self-trip pit can not extricate themselves.
- nacos registry is the main thrust of the project dubbo official, although it is still running iteration, but once problems are official reaction is quite timely. Use nacos more and more people, the equivalent of times into the pit too much, nowhere to hide the bug hidden. And nacos and dubbo have a natural kinship, view recent release nacos case, found that there are several specially registered to fix the problem dubbo
- nacos comes with a web management console, can be very convenient to the registration of query dubbo it can be used as a simple to use dubbo Governance Center
Two upgrade program
Since we are currently maintaining their spring-boot-dubbo-starter, so when do the upgrade, we had two different upgrade scenarios, and have done a complete verification.
Program: starter assembly magic change official
In order to do the development side of the basic non-upgrade version 2.7.4.1 perceived, we did two things
- Notes compatible
In doing annotations compatible also considered two options, one is to do processing compatible dubbo2.7.4.1 in the self-development of starter, one is compatible with our process on the official starter of 2.7.4.1. Back decisively chose the latter, because dubbo2.7.4.1 version is a black box do not know what changes, forward compatible difficult, backward compatibility has to be much easier for us. Our original custom annotation from the research component in the retention package path to a complete copy of the official starter project, and then ReferenceAnnotationBeanPostProcessor and ServiceAnnotationBeanPostProcessor moved out from dubbo the spring modules, custom made processing compatible annotations. This place once again boast under dubbo design, dubbo after donated to apache, package names have changed, for compatibility notes under the old alibaba package, service exposure and the introduction of services have done a very simple annotations compatible design. Thanks to this, we are doing very easy to customize to get the notes when compatible processing.
ReferenceAnnotationBeanPostProcessor constructor incoming custom annotation:
public ReferenceAnnotationBeanPostProcessor() {
super(AutowiredDubbo.class, Reference.class, com.alibaba.dubbo.config.annotation.Reference.class); } Add custom annotations support when scanning ServiceAnnotationBeanPostProcessor
scanner.addIncludeFilter(new AnnotationTypeFilter(www.zhuyngyule.cn 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 www.yixingylzc.cn AnnotationTypeFilter(com.alibaba.dubbo.config.annotation.Service.class)); // 兼容@DubboService注解 scanner.addIncludeFilter(new AnnotationTypeFilter(DubboService.class)); Last Modified DubboAutoConfiguration of service exposed and services into our magic processor can achieve reform
- Configuration compatible
Custom research of self-configuration is loaded with spring.dubbo starts, and the Crown is dubbo beginning with distinction as follows:
自研的配置：
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 To achieve compatibility configuration, a modified configuration dubbo starter loading logic, removed the spring starts, the modified DubboUtils filterDubboProperties, such as:
public static SortedMap<String, Object> filterDubboProperties(ConfigurableEnvironment environment) {
SortedMap<String, Object> dubboProperties = new TreeMap<www.javachenglei.com>(); Map<String, Object> properties = EnvironmentUtils.extractProperties(environment); for (Map.Entry<String, Object> entry : properties.entrySet()) { String propertyName = entry.getKey(); if (propertyName.startsWith(DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR) && entry.getValue(www.tengyueylzc.cn) != null) { dubboProperties.put(propertyName, entry.getValue().toString()); } if (propertyName.startsWith("spring." + DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR) && entry.getValue(www.shentuylgw.cn ) != null) { propertyName = propertyName.substring(7); dubboProperties.put(propertyName, entry.getValue().toString()); } } return Collections.unmodifiableSortedMap(dubboProperties); } The last package upload to PW, developers only need to upgrade the jar next version, configuration and code do not move can upgrade to version 2.7.4.1 of dubbo, magic places may change more than the code posted above, but here leads to the idea that this this is the end of the program, the advantages of this program is to develop more transparent because the migration to nacos steps are the same, the second option to talks
Option II: Direct use of the official starter assembly - was finally adopted
The final discussion down, taking into account the internal maintenance releases, when the official upgrade linkage upgrade would be more trouble, as direct a pain across the board transformation code transformation configuration, using the official starter direct upgrade, so, followed by a version upgrade without the input of manpower maintain a consistent and self-development official.
The first step: introducing rely maven
Official dubbo starter dependent
<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.www.feishenbo.cn</version> </dependency> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.9.0<www.lecaixuanzc.cn /version> </dependency> <!-- 注意，引入dubbo官方依赖后，需要同时挪除我们维护的starter包--> Step two: the transformation of a related note
- When enabled dubbo: @EnableDubbo into @EnableDubbo [org.apache.dubbo.config.spring.context.annotation.EnableDubbo], and suggested adding scanBasePackages package path, such as: @EnableDubbo (scanBasePackages = "cn.keking.service") . When the scanning speed of services and improve dubbo exposed to introduce services
- When the service is exposed: @DubboService into @Service] [org.apache.dubbo.config.annotation.Service
- When introduced into service: @AutowiredDubbo into @Reference] [org.apache.dubbo.config.annotation.Reference, three points to note here:
1, the official starter default service introduced will verify the existence of the service, to throw an exception, that affect the application starts, you can add global configuration, override the default behavior, there is no configuration is as follows: dubbo.consumer.check = false
2, since the starter RESEARCH @AutowiredDubbo timeout parameters such as the seconds, the official annotation parameters @Reference milliseconds, as previously configured timeout = 30, then the timeout in the official starter only 30 milliseconds.
3, in the use of multi-registry, dubbo service will be introduced at the same time from two registration centers, while your URL is exactly the same, also have two service instances locally, so when you fault-tolerant mode is broadcast mode ( cluster = "Broadcast") or parallel mode is generated when (cluster = "Forking") is triggered once the consumer, the producer received a question twice. The default cluster policy for Failover, will take the normal load of random way calling, does not have this problem. If there is a broadcast mode, or use the parallel mode, you can set nacos registration center, registration is not only the consumer. Configuration as follows, and other services are so timely move to remove the configuration after nacos: dubbo.registries.nacos.parameters.subscribe = false
The third step: configuration modification dubbo
Removing the spring. To prefix, note that once the upgrade Official Starter, need to add a configuration to set the connection pool size redis, the official default 8, dubbo.registries.redis.parameters.max.total = 200
The following illustrates a configuration dubbo upgraded:
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 Smooth migration to nacos registry
Using dubbo supports multi-registry functions, two phases to smoothly migrate from redis nacos, the first stage, the upgrades modifying configured for dual registration center, a second phase, remove the transition redis registration center, arranged as follows :
dubbo.registries.nacos.address=nacos://www.jianjiylzc.com xxx:80
dubbo.registries.redis.address=redis://www.jiaaoylzc.cn xx:6379
Note that some of the problems
- When using redis registry, if there is only one instance of redis, distinguished by DB redis environment to control, for example as follows:
dubbo.registry.parameters.db.index = 2
- And nacos registry distinguished by namespace specific configuration is as follows:
dubbo.registry.parameters.namespace =www.pingguoyul.cn xxxxxx
- If it is multi-registry configuration, note the use of the relevant registry prefix, such as: dubbo.registries.nacos.parameters.namespace = adefa98f-f4d9-4af8-9eb3-e0cab5a39cc7
Epilogue
dubbo upgrade program is simple, but really smooth upgrade transition is not easy, or encountered many problems during this stable is a continuous optimization process. Up to now we have not spread across the board on production, but individual applications onto production do verify, upgrade risk, need to be careful and cautious