Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what is the process of smooth migration of Dubbo services". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Is the open source version of Consul affected?

Only commercial software is mentioned in the above terms, so will open source Consul be affected? In the Consul warehouse of Github, you can know that the license of the project is Mozilla Public License 2.0. this license is Category B on the Apache website and is licensed by Weak Copy Left, so what are its characteristics?

Any code that can be used, copied, modified, redistributed, including for commercial purposes.

If you modify the source code licensed under the MPL agreement, and then reissue this part of the source code, you must retain the original MPL license and not replace it.

If a larger project is derived from this project, this part of the work can be distributed using a new license, as long as the code under the original MPL license is not modified. (this is why the source code of the distribution of Apache projects can contain binaries under the MPL protocol.)

As you can see, MPL is generally considered to be a compromise between Apache License and GPL/LGPL. Relative to Apache License,MPL 2.0, the modified source code must remain the same agreement; compared to GPL/LGPL, MPL 2.0 can be commercially available, and derivative works can also change license types under certain conditions.

Generally speaking, the open source version of Consul is unlimited for both private and commercial use. But this may also be a wake-up call, if there are still scruples about Consul, how to replace it?

In the field of micro-services, Consul is mainly used to act as a registry and configuration center, such as Dubbo and SpringCloud have corresponding support. This article uses this as an introduction to how to smoothly migrate Dubbo services to achieve the effect of replacing the registry.

The definition and meaning of smooth Migration Service

If the Dubbo application has been deployed to the production environment and is in a normal state, and you want to replace the application registry, it must be the first priority to ensure the smooth operation of the business during the migration process. The process of ensuring that the application is running uninterrupted and eventually achieving a registry replacement is called a smooth migration. It can be compared to replacing engines for aircraft in flight. In many cases, such as project upgrade and frame adjustment, there is often an excessive solution between the status quo and the final state.

Smooth migration can avoid the incompatibility between the final solution and the original scheme after one-time launch, and avoid the risk of overall regression.

No Internet company can afford: "from xx to xx, system maintenance for one hour, during the service will not be provided, please forgive the majority of users" this downtime upgrade scheme.

Smooth migration process

When it comes to registry migration, many people may immediately think of the scheme of dual registration and double subscription.

The dual registration and double subscription migration scheme refers to the simultaneous access to two registries (the original registry and the new registry) when the application migration is applied to ensure the mutual invocation between migrated applications and unmigrated applications.

Take the migration from Consul to Nacos as an example:

In the migration state, there are two types of applications: unmigrated applications and migrating applications. When we talk about dual registration and double subscription, we all refer to [applications in migration]. Knowing the following points, the process of smooth migration becomes clear at once:

[applications not migrated] do not make any changes

In order to allow [unmigrated applications] to call [migrating applications], it is required that [migrating applications] not only write data to Nacos, but also write back to the old Consul. This is double registration.

In order to allow [App in Migration] to call [App in Migration] to [App in Migration], it is required that [App in Migration] not only subscribe to the data of Nacos, but also monitor the old Consul. This is a double subscription.

When all applications become "applications in migration", the old Consul can be gloriously laid off, and the smooth migration is complete.

In this process, you can also flexibly change some rules. For example, in the middle and later stages of migration, most applications already have services in Nacos, so you can switch from double subscription to single subscription to verify the migration. And in the real scenario, the migration of configuration center and metadata center will coexist, and the process will be more complex.

Dubbo smooth Migration Scheme-- multiple registries

Dubbo multi-registry configuration document address: http://dubbo.apache.org/zh-cn/docs/user/demos/multi-registry.html

The complete code example of this article will be provided at the end of the article, where the Consul registry is built locally, while the Nacos registry uses Aliyun's cloud product: micro service engine MSE, which can provide hosted Nacos/Zookeeper/Eureka and other clusters.

Dubbo supports the configuration of multiple registries, which provides us with a lot of convenience for smooth migration. When using dubbo-spring-boot-starter, you only need to add the following configuration to configure multiple registries:

Dubbo.registries.first.protocol=consul

Dubbo.registries.first.address=localhost:8500

Dubbo.registries.second.protocol=nacos

Dubbo.registries.second.address=mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

You can see that the service has been registered successfully in the Consul console:

You can see that the Nacos service has also been registered successfully in the MSE console.

Also, the service invocation is fine. You may think: the previous mentioned a lot, you told me to change the configuration of two lines is a smooth migration? I still have to correct this idea. Changing the code is always the easiest thing to do. the difficult thing is to always observe the state of the business during the migration and make sure that the service is not compromised by the migration. In addition, it should be noted that the multi-registry scheme included in Dubbo has some defects because of the problems in the implementation of the framework.

Defects of Dubbo multiple registries

In the implementation of Dubbo, the addresses of multiple registries are isolated and the addresses are not converged. That is, when the consumer is configured as follows:

Dubbo.registries.first.protocol=consul

Dubbo.registries.first.address=localhost:8500

Dubbo.registries.second.protocol=nacos

Dubbo.registries.second.address=mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

The service address is always read first from the Consul and will not be attempted from the Nacos unless there is no service in the Consul, depending on the order in which the registry declares it in the configuration file. This may not be in line with most people's intuitive perception of multiple registries, but there is no way. Dubbo is designed this way, and I have tried to guess several possibilities of such a design:

Multiple registries are not aware of the need for each other's existence, so they can only read multiple registries serially.

The Dubbo native model does not support registry aggregation unless there is a single AggregationRegistry proxy for multiple registry implementations

The equals scheme of multiple registered addresses is difficult to determine, and the official contract specification has not been given, that is, can ip and port be considered the same address if they are the same?

Dubbo's multi-registry design is not just designed to adapt to a smooth migration scenario. Other scenarios may want to use this serial read strategy.

In order to give readers an intuitive feeling, I tested with demo at the end of the article, so that service provider A1 (port number 12346) registers only with Nacos, service provider A2 (port number 12345) registers only with Consul, and consumer B double subscribes to Nacos and Consul. As shown in the figure below, at the beginning of the test, you can find that a stable call is made to A1; during this period, I manually kill A1, and an address offline notification is clearly printed in the figure, and then a stable call is made to A2.

Such defects will cause us to fail to fully test the unmigrated applications and the migrating applications during the smooth migration process.

Dubbo smooth Migration Scheme-Registry aggregation

The term registry aggregation is actually my own idea, because the Dubbo official documentation does not give this solution directly, but the open source implementation provided by Aliyun's micro-service commercialization EDAS team (ps, yes, that's my team). The basic idea is to aggregate the addresses of multiple registries as mentioned earlier. The way to use it is equally simple.

Introduce dependencies:

Com.alibaba.edas

Edas-dubbo-migration-bom

2.6.5.1

Pom

Add configuration:

Add the address of the registry in application.properties.

Dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=consul://localhost:8500,nacos://mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848&reference-registry=consul://localhost:8500,nacos://mse-kirito-p.nacos-ans.mse.aliyuncs.com:8848

If it is a non-Spring Boot application, configure it in dubbo.properties or the corresponding Spring configuration file.

Edas-migration://30.5.124.15:9999

Header information of multiple registries. No changes can be made, and ip and port can be filled in freely, mainly to be compatible with Dubbo's verification of ip and port. When starting, if the log level is WARN or below, a log of WARN may be thrown, which can be ignored.

Service-registry

The registry address of the service registration. Write multiple registry addresses. Each registry is in a standard Dubbo registry format; multiple, separated.

Reference-registry

The registry address of the service subscription. Each registry is in a standard Dubbo registry format; multiple, separated.

Verify the scheme:

It has become a random call, which solves the defect of multiple registries.

After the migration is completed, it is recommended to delete the configuration of the original registry and the edas-dubbo-migration-bom that is specific to the migration process, and restart the application in batches when the business volume is small. Edas-dubbo-migration-bom is a migration-specific dependency. Although long-term use has no impact on the stability of your business, it will not follow the version of Dubbo.

This is the end of the content of "what is the process of smoothly migrating Dubbo services". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.