Background to the upgrade:

Recently, the project team is upgrading the Dubbo version. Since the previous duBBo version is basically 2.6, the version is relatively old, and the tag routing function after 2.7 is used, so we have done the upgrade of the DuBBo version and the research of the tag routing function. The following is to share with you the upgrade of DuBBo. And the realization of label routing function.

Dubbo2.7 introduction:

Dubbo.apache.org/zh-cn/blog/…

Official upgrade documents:

Dubbo.apache.org/zh-cn/docs/…

The current project is basically the version that Dubbo stopped updating, and then the Dubbo project was restarted. Dubbo has undergone a lot of optimization and solved many problems of the previous version. Besides, it wants to realize grayscale release and other functions of the project. The 2.7.4.1 version was selected after research, which provides tag routing, good project compatibility, and is officially recommended by Dubbo as a stable release for deployment to production.

An upgrade to the Dubbo version

Since this upgrade involves basically all systems of the company, at the same time, some old projects of the company are still springMVC version, only the subsequent development projects are Springboot version, the following is to introduce the upgrade of Dubbo version of SpringMVC version.

  1. Spring MVC upgrade dubbo 2.7.4.1

The upgrade of Dubbo version is mainly to upgrade two key places, one is the upgrade of Dubbo version; the other is that the company’s registry center is Zookpeer, and zkClient, which was used before, needs to be upgraded after the upgrade to version 2.7. If the project is not upgraded, an error will be reported.

< the dependency > < groupId > org. Apache. Dubbo < / groupId > < artifactId > dubbo < / artifactId > < version > 2.7.4.1 < / version > < / dependency >Copy the code

If zkClient is used in the system, replace it with a curator. Older zkClient launches with an error because it is incompatible with Dubbo2.7.4.1. Skip this step if ZK is used as a curator link. If hadoop is used in the system, manually exclude the curator to prevent conflicts.

< the dependency > < groupId > org. Apache. Curator < / groupId > < artifactId > curator - recipes < / artifactId > < version > 4.2.0 < / version > <exclusions> <exclusion> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> </exclusion> </exclusions></dependency>Copy the code

After upgrading the version and other information, we also need to modify the dubbo configuration file of the project. The client in the dubbo configuration file is changed to curator, and dubo.registry. Client =curator. Therefore, you need to modify the header information of the Dubbo configuration file.

When you refresh Maven, you can change the reference classes of the old version of Dubbo to the new one, introducing the new dubbo class.

2.Springboot upgraded Dubbo 2.7.4.1

Boot version of dubbo upgrade is basically the same as MVC version, can be said to be simpler, the same is the upgrade of dubbo version, as well as zooKeeper connection JAR, because the company’s project to introduce the relevant JAR is different, so only the key JAR information is introduced here.

(I) JAR version upgrade

Note: If you rely on sentinel, you need to modify the jar package related to sentinel

<dependency> <groupId>com.alibaba.csp</groupId> <artifactId> Sentinel-dubo-adapter </artifactId></dependency> changed to <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-apache-dubbo-adapter</artifactId> The < version > 1.7.1 < / version > < / dependency >Copy the code

(2) Update maven to modify the old version of dubbo reference classes

Dubbo provides a number of string – and collection-related methods that need to be changed to the corresponding utility classes in other packages if used in the system.

(3) Dubbo configuration modification, each project is not quite the same

Quoted here is zkclient need to modify the curator, or launch an error: under Caused by: Java. Lang. An IllegalStateException: No such extension org.apache.dubbo.remoting.zookeeper.ZookeeperTransporter by name zkclient

Note: after version 2.7.4.1 is upgraded, client:curator can no longer be configured in the configuration file of the project, because the underlying source code uses client:curator as the connection client of ZooKeeper by default. If you are interested, you can read the source code.

After upgrading to the new Dubbo version, the project started normally and the service was available externally.

Use of two Dubbo tag routes

If you want to modify a feature in a very long call chain and test it without affecting other users of the environment to use the existing feature, for example:

1. Remote invocation between A, B, C, and D is implemented through Dubbo

2. These modules may have one or more instances

3. This environment is used by multiple people (including development and testing) simultaneously

If you want to modify a function in B and add a feature (called FAT1), which is also registered in this environment, the following problems will occur: When other users use this function, the call initiated from A may switch back and forth between instances with and without FAT1 due to Dubbo load balancing algorithm, etc. The result may be that the same function is used twice and the result is unexpectedly different!

The easiest way to solve this problem is to set up a separate test environment for each feature (FAT). For example, if there are 20 features released in this phase, deploy 20 environments. Wait, is there something wrong? Deploying 20 environments? Do you feel like your BOSS is standing behind your seat, ready to throw you out of the office?

In a careful analysis of this problem, there are two key points to solve:

1. Isolate features that are being developed/tested by different people.

2. Share the unmodified parts to save resources.

To sum up, the best solution would be as follows:

1. Establish a Baseline environment that contains all the components, data sets, and so on required by the application.

2. For different functional features, an instance is independently released for the component modified by the Feature, which is called a Feature, and the corresponding test field is called FAT+ number. For example, the test environment of Feature 1 is called FAT1.

3. When developing and testing a certain functional Feature (such as Feature 1), use the routing function to make the upstream module automatically select the correct downstream module, which is convenient for developers to debug and testers to view the effect.

By exploring the Dubbo documentation (dubbo.apache.org/zh-cn/docs/…) , and found that there are several schemes to achieve this function:

1. Use conditional routing rules

2. Enable the dynamic label function

3. Use the static label function

Through the analysis of the above three methods, the advantages and disadvantages of each method are found as follows:

1. If conditional routing is used:

The advantage is that the requirements are clear. If I want to design A FAT test farm, where A and B are components to be tested, I can use the routing rule host! = A => host ! = A => host =B

The disadvantage is that:

A. Routing rules need to be modified using the Dubbo console, which is too powerful for general development/testing.

B. If components A, B, and D are modified at the same time, C may not know whether the request should be sent to D when the request is sent from A->B->C. Conditional routing cannot be implemented.

2. If dynamic label is used, problem B in 1 can be solved, because the label will be passed in the form of Attachment in the whole call link, but problem A still cannot be solved

In summary, to achieve this function, it is best to use 3. Static label function. According to the official document, Dubbo label routing function is available since 2.7, so we need to use this version.

** 1 Server Settings **

The configuration of the server is very simple. You only need to add the dubo.provider. Tag and dubo.consumer.tag attributes to the configuration file.

Tag =old # Request. Tag. Force =false # Client tagdubo.consumerCopy the code

** 2 Client **** Settings **

If the requested tag does not exist and request.tag.force=false, the client will downgrade the request to the service with an empty tag.

(1) Read the tag of the configuration file

Configuration file Information

Dubo.consumer. Group =test # dubo.provider. Tag =old # The default is false request.tag.force=false # The client carries tag dubo.consumer.tag =oldCopy the code

Utility class for reading tag numbers (also configurable in NACOS)

@Componentpublic class DubboTagConfiguration {    
   @Value("${dubbo.consumer.tag}")   
   private String dubboConsumerTag;   
   public String getDubboConsumerTag() {        
     return dubboConsumerTag;    
 }}
Copy the code

(2) Add the request tag number to the Filter of dubbo

Through the test, the tag setting of the project can realize the functions required by our project in the cluster environment. Since the project has not been officially launched, we will timely update any questions in the future. We hope that interested students can discuss with us.