How to smoothly unify a registry when there are multiple different registries?

I have encountered similar problems in different wechat groups and communities in recent days:

Such as spring4all posts: bbs.spring4all.com/thread/21

For example, similar discussions were held in the Qin Group today.

Although the descriptions are different, they all revolve around the same question: how can services under two different registries call each other?

Here are my thoughts, practices and suggestions on this issue.

Why is there such a scene?

First, let’s talk about the background problem, some group friends when they see this kind of problem, the first reaction is how to use multiple registry, is it a fool?

Obviously no one with half a brain would do that! So why does this scenario exist? It usually goes something like this:

1. The lack of a unified base technology platform management, almost all large enterprises will encounter such problems. Period of brutal to business development, the technical team is rarely have the energy to do these governance, divided by the boundaries of the system, because the system and the interaction between system through agreement defines the good, each system within the technology stack based on the characteristics choose their best team, does not need to go to the united will, nice and fast to complete the construction of each system. Therefore, there is nothing wrong with different systems choosing different registries to govern their services.

2. With the development of the business, the business needs to be adjusted, the architecture needs to evolve, and the complex system relationship (previously developed by ourselves, acquired system, external procurement system) needs to be rebuilt. Whether in the form of microservices, or in the way of the mid-platform to redraw the boundaries of the system, it is inevitable to do a re-planning and governance of the existing services.

3. Because of the complexity of the system, we can not step in place, can only be little by little to transform the target. There is bound to be a new old coexistence, gradual transformation of the evolution process. In order to smooth the transition process, our first thought is to unify the service governance, so that all internal services can easily and conveniently discover each other and can call each other.

Hence the scenario discussed at the beginning of this article. So, this is a product of the evolution of the architecture, not a poorly designed freak.

Two ideas of unified service governance

Solution 1: Realize the registration and discovery of multiple registries on the service server

This approach is the solution to the problem raised at the beginning of the paper. Realizing this solution involves the solution of several core problems:

1. Extensions to service registries: We know that Spring Cloud’s registration mechanism is for single registries, as well as for matching discovery. We cannot implement multiple registries by configuring one set of service discovery interface implementations. So, you need to have one main registry for Spring Cloud’s own Bean implementation, and multiple other (depending on the number of registries) implementations of registered clients around it.

2. Extension of service discovery: Once registration operations are implemented for non-primary registries, the discovery mechanism is implemented as well. Also, 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 in the Spring Cloud configuration registry. Therefore, in the service discovery module, you need to add the services and instances obtained from the external registry to the ServiceList and ServerList under the main registry. In the meantime, a few things to note here:

• Because business services are registered in each registry, there will be overlap in discovery, which should be taken care of.
• The management of service names also needs to prevent duplication. Some service names, such as the user center, are easy to conflict in different systems. Service names can usually be prefixed with system codes to ensure that there are no duplicates after fusion.

By doing this, each business service is connected to all the registries, and services that used to reside in different systems can discover and invoke each other.

Scheme 2: Synchronizes service data between registries

This approach is to create a registry synchronization service, which has the simple task of synchronizing the service information from each registry to the other registries, while listening for changes in each registry to ensure that all the different registries contain all the services under the system.

In this case, as long as the business services are built by Spring Cloud, it is easy to move services from different registries to services in the same registry by gradually changing the registry dependencies.

Compare the advantages and disadvantages of the two ideas

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

Of course, there are some complications for option two, and some extensibility compatibility may be required if there are special customizations to the registration process. But compared to the first implementation, the logical complexity of embedding on the business application side is very small.

At the same time, since service governance is to be unified, the end state is often reserved only for the registry that you want to maintain centrally at the end. If the first scheme is adopted, it is bound to have to readjust the registration and discovery mechanism, and the elimination of the registration and discovery logic that will be eliminated is another complicated thing.

So, by combining these two methods. In my opinion, plan 2, which synchronizes the data of the registry to accomplish the task of unified service governance, is more secure than Plan 1, and has the least impact on business development. Some deployment costs are introduced, but they are minimal on a multi-system basis.

So, do you have similar problems? What’s a good plan? Leave a message to discuss! If you want to meet more interesting souls, you can also join our technology exchange group to discuss our technology life!

Welcome to pay attention to my public account: program ape DD, share the outside can not see the dry goods and thinking!