When there are multiple registration centers, how to unify the registration center smoothly?

In the past few days, we have encountered similar problems in different WeChat groups and communities:

For example, spring4all's post: http://bbs.spring4all.com/thread/21

Another example is a similar discussion in Qin's group today.

Although the descriptions are different, the core revolves around a question: how do services under two different registries call each other?

To address this issue, let me talk about my thinking, practice and suggestions.

Why is there such a scene?

Let me talk about the background problem first. When some group friends see this kind of problem, the first reaction is how to use multiple registration centers. Is it a mess?

Obviously people with a little brain won't do this! So why is there such a scene? It usually evolves like this:

1. In the absence of a unified basic technology platform management, almost all large enterprises will encounter such problems. For the period of brutal business development, the technical team has little energy to do these governance. After the system boundary is divided, it is good that the interaction between the system and the system is defined by the protocol. The technical stack within each system is based on the team. You can choose what you are best at, and you don’t need to unify to complete the construction of each system quickly and well. Therefore, there is nothing wrong with different systems choosing different registry to manage their own services.
2. With the development of the business, the business needs to be adjusted, the architecture needs to evolve, and the complex system relationships (systems developed by ourselves in the past, systems acquired by mergers and acquisitions, systems from external procurement) need to be rebuilt. Regardless of whether it is to re-divide the system boundary in a micro-service way or a middle-office way, it is bound to re-plan and manage existing services.
3. Due to the complexity of the system, we can't get in place in one step, we can only change a little bit to the transformation goal. There is bound to be an evolutionary process in which the old and the new coexist and gradually transform. In order to be able to smooth the process of transition and transformation, our first thought is to unify service governance, so that all internal services can easily and conveniently find each other and call each other.

So, there is this kind of scene discussed by everyone in the first article. Therefore, this is a product of the process of architecture evolution, not a freak that comes out of bad design.

Two Ideas of Unified Service Governance

Solution 1: On the business server side, realize the registration and discovery of multiple registration centers

This method is the first of the article, the solution to the problem that everyone puts forward, the realization of this solution involves the solution of several core problems:

1. Service registration extension: We know that the registration mechanism of Spring Cloud is for a single registration center, and the matching discovery is also the same. We cannot realize the realization of multiple registries by configuring the realization of a set of service discovery interfaces. Therefore, you need to use a set of main registry as Spring Cloud's own bean implementation, and the periphery needs to learn more sets (according to the number of registries) to register the client implementation.

2. Extension of service discovery: A set of registration operations for non-primary registration centers is implemented, and then a set of discovery mechanisms must be implemented. At the same time, because the service discovery here is not bound to Spring Cloud's service discovery mechanism, these services will not enter the ServiceList and the corresponding ServerList under the registry configured by Spring Cloud. Therefore, in the service discovery module, you need to add the services and instances obtained by these external registries to the ServiceList and ServerList under the main registry. At the same time, here are a few points that need to be noted:

   • Because business services are registered in each registration center, there will be overlaps when they are discovered, so we need to do a good job of removing the duplicates here.
   • The management of service names also needs to prevent repetition. There are some service naming such as user center under different systems that are easy to conflict. Usually, the system code can be used as a prefix to process the service name to ensure that there is no duplication after fusion.

Through this operation, each business service has established a connection with all registration centers, and various services originally in different systems can also discover and call each other.

Solution 2: Realize the synchronization of service data between each registration center

This method is to create a new registration center synchronization service. Its task is very simple. It is to synchronize the service information of each registration center to other registration centers, and monitor the changes of each registration center to keep all different registration centers. Contains all services under the system.

In this case, as long as it is a business service built by Spring Cloud, you only need to gradually replace the registry dependency, and you can easily transfer the services that were originally in different registries to the services under the same registry. .

Comparison of the advantages and disadvantages of the two ideas

The general advantages and disadvantages of the above two schemes are as follows:

| |Scheme One|Scheme Two|
|---|---|---|
|Advantages|No need to increase deployment costs|Business services are less intrusive|
|Disadvantages|Business services are very intrusive|Need to increase deployment costs|

Of course, there will be some complications for the second scheme. If there are some special customizations to the registration process, some extensions and compatibility will need to be made. But compared to the first implementation, the logic complexity implantation on the business application side is very small.

At the same time, because of the need to unify service governance, the final state after the fact is often only the registry that you want to maintain centrally at this time. If the first scheme is adopted, the registration and discovery mechanism must be re-adjusted. It is a complicated matter to remove the registration and discovery logic to be eliminated.

So, comprehensively compare these two methods. I personally think that using option two, synchronizing the data of the registry to complete the task of unified service governance, is more secure than option one, and has the least impact on business development. Although some deployment costs will be introduced, these costs are minimal for a multi-system basis.

So, have you encountered similar problems? What is a good plan? Leave a message and discuss it together! If you want to collide with more interesting souls, you can also join our technical exchange group to discuss our technical life together!

Welcome to pay attention to my public account: Program Ape DD, share knowledge and thoughts that can’t be seen elsewhere