This article has been published on Github /JavaMap. It contains a series of articles on advanced technology knowledge for Java programmers.

In microservice architecture or distributed environment, service registration and discovery technology is indispensable, which is also one of the core technologies that programmers must master on the way to advance. This article guides you to grasp it easily by means of diagrams.

The reason for introducing service registration and discovery components

Let’s look at a question first. If we want to do a mall project now, how should you design the architecture of the system as an architect? You must be thinking: this is not easy to directly copy taobao’s architecture is not on the line. However, in the real startup environment, a project can be a near-death experience. If you invest a lot of money and manpower at the beginning, the loss will be huge once the project fails.

As an experienced architect, it is necessary to choose the most suitable architecture based on the current situation of the company’s financial resources, human input budget and so on. Large sites are built from small sites, and the architecture is the same.

The architecture of any large website is not a constant layer from the beginning, but the result of continuous iterative evolution with the increasing number of users and data.

In the iterative evolution of architecture, we will encounter a lot of problems. The essence of technology development is to constantly discover problems and then solve them. Solve problems and then discover problems.

Monomer architecture

At the beginning of the establishment of the system, there may not be many users. All the services are grouped into one application package and run in tomcat container, and the same server is shared with the database. This architecture is generally called single architecture.

In the initial stage, this architecture is very efficient and can be quickly iterated and launched according to user feedback. However, as the number of users increases, the memory and CPU of a service is tight, which is easy to cause bottlenecks. How to solve new problems?

Application and data separation

As the number of user requests increases, the memory and CPU of a server increase rapidly, and the response time of user requests slows down. At this point, you can consider separating the application from the database, using a separate server, you see the problem solved again.

Suddenly one day the sweeper accidentally touches the power line, and one of the servers loses power. All the users’ requests are reported in error, followed by a series of complaint calls.

Cluster deployment

What if a single instance could easily cause a single point of problem, such as a server failure or service capacity bottleneck? Smart you must have thought of a cluster.

In cluster deployment, an application is deployed on multiple servers or virtual machines. Users can access one instance randomly through service balancing to balance the traffic of multiple instances. If an instance is faulty, it can be offline, and other instances can still provide services.

As the number of users increased rapidly, the boss decided to increase the investment to expand the size of the team. The efficiency of the development team has not been significantly improved after the expansion. In the past, small teams could iterate once a week, but now it takes at least two to three weeks.

Business logic is getting more complex, code coupling is severe, and changing a line of code can introduce several online problems. The architect recognizes the need for architectural refactoring.

Microservices Architecture

When the individual architecture evolves to a certain stage, the complexity of development and testing will increase in cost, and the expansion of team size will make the coupling of their respective work more serious, which is the scenario that affects the whole body at the same time.

When the individual architecture hits a bottleneck, the microservices architecture emerges. Microservice is to split individual services according to the business dimension. The granularity can be large or small, and the timing can be divided by rhythm. The best practice is to first separate some independent functions from the unit into one or more microservices to ensure business continuity and stability.

Split a commercial application into six separate microservices as shown above. Six microservices can be deployed with multiple instances using Docker containers.

The architectural challenge here is that the user service may depend on the order service if it wants to query all the orders of the user. How does the user service interact with the order service? There are multiple instances of the order service. Which one should I visit?

There are usually several solutions:

(1) Hard coding of service address

The address of the service is written to the database or configuration file and routed by accessing the DNS domain name.

The IP address of service B is hardcoded in the database or configuration file. Service A first obtains the IP address of service B and then obtains the real IP address of an instance through the DNS server. Finally, service A sends A request to service B.

If service instances need to be expanded and service instances need to be offline after promotion, o&M personnel need to perform a lot of manual operations, which is prone to misoperation.

(2) Dynamic service registration and discovery

Another fatal problem with hard coding of service addresses is that if an instance is down, o&M personnel may not be able to detect it in time, resulting in abnormal requests from some users.

The introduction of service registration and discovery components is a good way to solve the above problems and avoid too much manual work.

Summary of Architecture Evolution

In a singleton architecture, an application is a service bundle in which modules call each other through function methods. The model is simple enough that there is no service registration or discovery at all.

In the microservice architecture, an application is divided into multiple microservices, which are deployed on different servers, different containers, and even multiple data centers. The microservices need to call each other, and service registration and discovery become an indispensable component.

Service registration and discovery fundamentals

Service registration and discovery are divided into registration and discovery two key steps.

Service registration: A service process registers its metadata information in a registry. This usually includes host and port numbers, and sometimes authentication information, protocols, version numbers, and information about the operating environment.

Service discovery: The client service process initiates a query to the registry to obtain information about the service. An important function of service discovery is to provide clients with a list of available services.

The service registry

There are two forms of service registration: client registration and proxy registration.

Client Registration

Client registration is the service’s own responsibility for registration and unregistration. The registry thread registers with the registry when the service is started and unregisters itself when the service goes offline.

The disadvantage of this approach is that the registration and logout logic is coupled to the business logic of the service, and if the service is developed in different languages, multiple sets of service registration logic need to be adapted.

Registered agent

Proxy registrations are registered and unregistered by a separate proxy service. When the service provider is started, it somehow notifies the proxy service, which is then responsible for initiating registration with the registry.

The disadvantage of this approach is that one more proxy service is referred to and the proxy service remains highly available.

Service discovery

Service discovery is also divided into client discovery and agent discovery.

Client discovery

Client discovery refers to that the client queries available service addresses from the registry. After obtaining all available instance addresses, the client selects an instance based on the load balancing algorithm and invokes the request.

This approach is very straightforward and the client can control the load balancing algorithm. However, the disadvantages are also obvious. The logic of obtaining instance addresses, load balancing and so on is coupled with the business logic of the service. If the service is discovered or the load balance changes, all the services have to be modified and brought back online.

The agent found

Agency found that refers to A new routing service is responsible for service discovery to obtain A list of available instances, service consumers if you need to call an instance of A service request will can directly send it to the routing service, routing service good load balancing algorithm based on configuration from the list of available instances can choose an instance will forward requests in the past, if it is found that instance is not available, The routing service can also retry itself without the service consumer being aware of it.

heartbeat

If there are multiple instances of a service and one of them goes down, the registry can sense it in real time and remove the instance information from the list, also known as off-hook.

How do I pick up the phone? Heartbeat detection is commonly used in the industry. Heartbeat detection can be implemented in active and passive ways.

Passive detection means that the service actively sends heartbeat messages to the registry. The interval can be customized, for example, once every five seconds. If the registry does not receive heartbeat messages from the instance within three periods, for example, 15 seconds, the instance is removed from the list.

In the figure above, instance 2 of service A is down and cannot actively send heartbeat messages to the registry. Registration will remove instance 2 after 15 seconds.

Active detection is initiated by the registry, which sends heartbeat detection messages to all service instances in the list every few seconds. If the heartbeat detection messages are not sent successfully or no reply is received within multiple periods, the registry will actively remove the instance.

Industry common service registration and discovery components comparison

Knowing the fundamentals of service registration and discovery, if you want to use service registration and discovery components in your project, how do you choose the technology when faced with many open source components?

In Internet companies, large companies with r&d strength will generally choose self-development or secondary development based on open source components, but for small and medium-sized companies, it is a good choice to directly choose an open source software.

Common registration and discovery components include Eureka, ZooKeeper, Consul, etcd, etc., which are no longer recommended since Eureka announced in 2018 that it was abandoning maintenance.

The following is a comparison of the components in each dimension.

| | | components advantages to disadvantages | | | interface type consistency algorithm | : — | — – | : — | — – | : — | — – | : – | | zookeeper | 1. Powerful, not just for service discovery; 2. Provide watcher mechanism to obtain the status of service providers in real time; 3. Widely used and supported by dubbo and other micro-service frameworks; | 1. No health check; 2. SDK needs to be introduced into the service, resulting in high integration complexity; 3. Multiple DATA centers are not supported. | | SDK Paxos | | consul | 1. Out of the box, convenient integration; 2. Bring a health check; 3. Multiple data centers are supported. 4. Provides a Web management interface. Notice | | cannot obtain real-time service transformation restful/DNS | Raft | | etcd | 1. Out of the box, easy integration; 2. Strong configurability | 1. No health examination; 2. Cooperate with third-party tools to discover services. 3. Multiple DATA centers are not supported. |restful|Raft|

Consul is more complete and balanced on the whole. Take Consul as an example.

Consul — A recommended open source component for service registration and discovery

A brief introduction to Consul

Consul is an open source application from HashiCorp. Consul is developed using the Go language and is easy to deploy out of the box. Consul is distributed, highly available, and scaleable for service discovery and configuration for distributed systems.

What are Consul’s advantages?

• Service registration and discovery: Consul allows you to register and discover services using DNS or restful interfaces. Services can be selected based on actual conditions.
• Health check: Consul’s Client can provide any number of health checks that can be associated with a given service or local node.
• Multi-data Center: Consul supports multi-data centers, which means users don’t have to worry about Consul’s own high availability issues or extended access issues that come with multi-data centers.

Architecture diagram of Consul

Consul’s implementation of multi-data centers relies on the Gossip Protocol. The purpose of this:

• You do not need to use the server address to configure the client; Service discovery is automated.
• The job of checking for failures is not on the server, but distributed.

Consul application scenario

Consul application scenarios include service registration discovery, service isolation, and service configuration.

In service registration discovery scenarios, Consul serves as the registry. After a service address is registered in Consul, you can use the DNS and HTTP interfaces provided by Consul to query the service address. Consul supports Health Check.

In a service isolation scenario, Consul supports service-specific access policies and supports both classic and emerging platforms, TLS certificate distribution, and service-to-service encryption.

In service configuration scenarios, Consul provides the key-value data store function and promptly notifies users of changes. Configuration sharing is implemented using Consul. Services that need to read configurations can obtain accurate configuration information from Consul.

— END —

Daily praise: Hello technical people, praise first look to form a habit, your praise is my power on the way forward, the next stage is more exciting.

The blogger graduated from Huazhong University of Science and Technology with a master’s degree. He is a programmer who pursues technology and has passion for life. A few years in a number of first-line Internet companies, with years of actual combat experience.

Search the official wechat account “Architect who loves to laugh”, I have technology and story, waiting for you.

The articles are constantly updated, you can see my archived series of articles on Github /JavaMap, have interview experience and technical expertise, welcome Star.

Chat 🏆 technology project stage v | distributed those things…