Microservice Architecture Practice: Load Scheme Selection in Service Registration and Discovery

Microservice architecture is not a silver bullet. In microservice architecture, we will face many new problems. At this time, a service registration discovery problem will inevitably be introduced. The author of this article introduces you to three main service registration and discovery and load balancing schemes depending on the location of the load balancing.

1. Service registration and discovery mechanism under the microservice architecture

With the popularity of the microservice architecture, more and more enterprises put the microservice architecture into practice. Compared with the traditional monolithic application architecture, the microservice architecture has unique advantages; under the traditional monolithic application architecture, because of the centralized function and code, a release package is deployed and released in a process application, and the monolithic application The application architecture has been unable to meet the rapidly changing needs of enterprise business.

On the one hand, the code maintenance is difficult, the scalability is poor, and the flexibility is low. In the microservice architecture, because services are deployed independently, each service is better than a monolithic application in terms of development cycle and difficulty when developing, testing, and deploying.

However, the microservice architecture is not a silver bullet. In the microservice architecture, many new problems will be faced. The microservice architecture consists of a group of small services, and the services use a lightweight communication mechanism for communication. The calling relationship is a mesh structure. When a microservice calls another microservice, it cannot know the specific address of the other microservice; since each service belongs to a "micro" service, the life cycle of each service is not long. Services may be shut down, restarted, or replaced at any time; when the traffic volume increases, the microservice needs to expand, and when the traffic volume decreases, the microservice needs to shrink; this causes the address of each microservice to change dynamically. A service registration discovery problem is inevitably introduced, that is to say, when the client calls, it needs to know the address of the server, and when the server provides services, it needs to register and announce its own address for the client to call; at the same time, the server generally has many This requires the introduction of load balancing capabilities. Depending on the location of the load balancing, there are three main service registration and discovery and load balancing schemes.

2. Common service registration and discovery schemes

1). Centralized load balancing scheme

Centralized load balancing is also called server-side load balancing. As shown in Figure 1, the load balancer is on a separate host and can use soft loads, such as nginx, apache, etc., or hard loads, such as F5, etc. Responsible for the load balancing of multi-instance services, the client directly accesses the load balancer through the domain name, and the DNS server resolves the domain name to the IP of the load balancer:

picture description

This solution is relatively simple to implement, still the mainstream in the industry, and can make full use of the load balancer The ability to distribute requests to the following service instances according to different load policies; at the same time, the shortcomings of this scheme are also obvious, the load balancer has a single point problem, all traffic needs to pass through the load balancer, if the load balancer exists If there is a problem, it will directly cause the service to fail to provide services normally; the load balancer acts as a proxy in the middle, and the performance will also suffer a certain loss.

2). Client-side load balancing scheme The

client -side load has been improved in view of the shortcomings of the server-side load. As shown in Figure 2, the load capacity is provided by the client-side process. The server-side instance registers its own address to the registration center. The client subscribes the address of the service provider from the registration center, and after obtaining the address, it performs service routing according to the load balancing implementation strategy:

picture description

This solution solves the single point problem of server load, and each client implements its own load function , the load capacity is together with the client process, which is consistent with the life cycle of the client. If the load balancing process is down, the client is also down, and it only affects its own client and will not affect other clients; at the same time, this scheme also has There are certain disadvantages. The load requires each client to implement it by itself. If there are different technology stacks, each client needs to use a different language to achieve its own load capacity, which is technically difficult. Motan and dubbo in the industry use this solution for services. Sign up and discover.

3). Client host independent load balancing scheme

The third solution combines the advantages and disadvantages of the first two solutions. As shown in Figure 3, the capabilities of service discovery and load are removed from the client process. The client process and the load balancing process are two independent processes on the same host. On; the service instance still registers its own address to the registration center when it is started, and the client directly sends the request to the local load balancer.

Picture description

This solution is a typical distributed solution, there is no single point of problem, if the load balancer of a host fails, only one node will be affected and other nodes will not be affected. The load balancer itself has a small load and performance loss. At the same time, it does not need multiple languages ​​to realize its own load capacity, and the load capacity is public; however, this solution is complicated to deploy and difficult to maintain. After an exception occurs, it is troublesome to debug the load and locate the problem.

3. The choice of the new generation As mentioned

above , for service registration and discovery, how do we practice in Puyuan's new generation of digital enterprise cloud platform? In the digital enterprise cloud platform, we chose the path of DevOps to achieve our ideal operation, while centering on the microservice architecture. The logical architecture of DevOps (for more content in the new generation, please move to the menu of this public account: pure dry goods - digital transformation) as shown in the figure:

picture description

Service registration and discovery are in the DevOps technology platform, and serve as the basic framework for the upper-level DevOps background

service usage.

The running view of DevOps is shown in the figure:

Picture description It can be seen

from the figure that there is an intricate calling relationship between microservices, and SRD mainly solves the problem of service registration and discovery between microservices. In the digital enterprise cloud platform, we comprehensively considered the advantages and disadvantages of several solutions for service registration and discovery, and combined with some features of our platform and technology stack, we considered the following issues:

How to choose a load scheme, we chose a load scheme similar to scheme 3; because scheme 3 makes up for the advantages and disadvantages of the previous two schemes, the problem is that the deployment is complicated, but we use K8S to manage the deployment of microservices, the load itself The complexity is solved by K8S itself, and we do not need to spend a lot of money to solve the deployment problem.

In the case of selecting the independent load of the client host, the Cluster IP cannot be obtained when the service provider starts. Our solution is to access it through the domain name. The default domain name is the same as the current application name.
The following is the architecture diagram of our service registration and discovery:

picture description When the

service provider starts, it registers the domain name of the current application to the service registry, the client obtains the service domain name of the service provider through the service registry, and the client obtains the service domain name of the service provider through the dns Resolve to the Cluster IP, and then initiate the call.


Taken from: http://geek.csdn.net/news/detail/100504