Microservice technology stack: common registry components, comparative analysis

Posted Jun 15, 20207 min read

Source code of this article: GitHub·click here || GitEE·click here

  1. Introduction of Registration Center

  2. Basic concepts

The concept of registration center has been proposed in a distributed architecture system. The most classic one is Zookeeper middleware.


In the microservices architecture, the registration center is one of the core basic services. The registration center can be regarded as a communication center in the microservices architecture. When a service requests another service, the status of the service can be obtained through the registration center. Address and other core information.

Service registration is mainly related to three major roles:service provider, service consumer, and registration center.

  1. Process and principle

Basic process

  • When the service starts, register its own network address and other information to the registration center, and the registration center records service registration data.
  • Service consumers obtain the address of the service provider from the registration center, and call the service provider's interface through the address and based on a specific method.
  • Each service communicates with the registration center using a certain mechanism. If the registration center and the service cannot communicate for a long time, the instance will be cancelled. This is also called the service offline. When the service is reconnected, it will be online based on a certain strategy.
  • When the information related to the service address changes, it will be re-registered to the registration center. In this way, the service consumer does not need to manually maintain the relevant configuration of the provider.

Core functions

Through the above basic process, it is not difficult to find out what core functions a registration center needs to have:

  • Service discovery

Service discovery means that after the service is started, it is registered to the registration center, and the service provider provides its own metadata, such as IP address, port, Uri of the operating status indicator, home page address and other information.

  • Service record

Record the service information of the registration center, such as service name, IP address, port, etc. The service consumer obtains a list of available service instances based on the query.

  • Dynamic management service

The registration center regularly tests the registered services based on a specific mechanism. For example, by default, a heartbeat is sent every 30 seconds to renew the service. Tell the server that the client is still available through service renewal. Under normal circumstances, if the Server does not receive the Client's heartbeat within 90 seconds, the Server will delete the Client instance from the registration list.

  1. Comparison of basic components

  2. Zookeeper components

1.1 Basic description


ZooKeeper is a very classic service registry middleware. In the domestic environment, due to the influence of the Dubbo framework, Zookeeper is considered to be the best choice for the registration center under the RPC service framework in most cases. With the continuous development and optimization of the Dubbo framework, and The birth of various registry components, even the RPC framework, the current registry has gradually abandoned ZooKeeper. In the commonly used development cluster environment, ZooKeeper still plays a very important role. In the Java system, most cluster environments rely on ZooKeeper management services for each node.

1.2 Component Features


From the point of view of the data structure characteristics of Zookeeper, it is not designed based on service registration. The namespace provided by ZooKeeper is very similar to the namespace of the file system. It is highly abstracted in the KV format on the data structure and is very versatile. Redis can also be used as a registration center, but not much.

The ZooKeeper component supports the short-lived existence of nodes. As long as the session that created the znode is active, these znodes will exist. When the session ends, the znode will be deleted. The Dubbo framework is based on this feature. The service is registered with Zookeeper as a temporary node. It needs to periodically send a heartbeat to Zookeeper to renew the node, and allows the corresponding node on Zookeeper to be deleted when the service is offline. At the same time, Zookeeper uses the ZAB protocol. Ensure strong consistency of data.

  1. Eureka components

2.1 Basic description


The most native deep integration component in the SpringCloud framework ecology, Eureka is a service discovery framework developed by Netflix. It is a REST-based service that is mainly used for service registration, management, load balancing, and service failover. However, the official statement stops maintenance in the Eureka 2.0 version and is not recommended.

2.2 Component Features

Eureka contains two components:EurekaServer and EurekaClient.

EurekaServer provides a service registration service. After each node is started, it will be registered in EurekaServer, so that the information of all available service nodes will be stored in the service registry in EurekaServer. The information of service nodes can be seen intuitively in the interface. Eureka allows you to customize the method of checking whether your status is healthy when registering a service. This is a better experience in the scenario where the service instance can keep the heartbeat reported.

EurekaClient is a java client used to simplify the interaction with EurekaServer. The client is also a built-in load balancer using round-robin load algorithm.

  1. Consul components

3.1 Basic description


Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and highly scalable, and it is easy to develop and use. It provides a full-featured control panel, the main features are:service discovery, health check, key-value storage, security service communication, multiple data centers, ServiceMesh. Consul's design includes many functions that are used in distributed service governance.

3.2 Component Features

Consul provides support for multiple data centers and performs load balancing based on Fabio. In each data center, there is a mix of client and server. It is expected that there will be three to five servers. A good balance can be achieved between failure and availability of performance. All nodes in the data center participate in the gossip protocol. This means that there is a gossip pool that contains all the nodes in a given data center. This has several purposes:first, there is no need to configure the server's address for the client; discovery is done automatically. Second, the task of detecting node failures is not distributed on the server, but distributed. This makes fault detection more scalable than naive heartbeat solutions. Third, it is used as a messaging layer for notification when important events such as leader elections occur.

  1. Nacos components

4.1 Basic description


Nacos is committed to discovering, configuring and managing microservices. Nacos provides a simple and easy-to-use feature set to help you achieve dynamic service discovery, service configuration management, service and traffic management. Nacos is more agile and easy to build, deliver and manage microservice platforms. Nacos is a service infrastructure that builds a modern service architecture centered around "services"(such as microservices paradigm and cloud native paradigm). Nacos supports as an RPC registration center, for example:supports Dubbo framework; also has the ability of microservices registration center, for example:SpringCloud framework.

4.2 Component Features


The data model refined by Nacos after many years of production experience is a three-tier model of service-cluster-instance. As mentioned above, this can basically satisfy the data storage and management of the service in all scenarios. Although the data model is relatively complex, it does not enforce the style of the data structure. In most application scenarios, it is similar to the Eureka data model.

Nacos provides a data logical isolation model. User accounts can create multiple namespaces, each namespace corresponds to a client instance, and the physical cluster of the registry center corresponding to this namespace can be routed according to rules, so that the internal registry Upgrades and migrations are imperceptible to users.

  1. Component selection

The comparison chart of the registration center is as follows.


Based on the comparison of the above types of registration centers, from the current SpringCloud framework trend, I personally recommend the follow-up microservice architecture system to choose Nacos components. The main reasons are as follows. The community is active. After large-scale business verification, it can not only serve as a microservice registration center, but also It supports the registration center of Dubbo as an RPC framework, and has perfect Chinese documents. It can be summarized in one sentence:general middleware, saving time; detailed documentation and worry-free.

Four, source code address


Recommended article:Microservices Basic Series

Serial Number Article Title
01 Microservice basics:Eureka components, management service registration and discovery
02 Microservice basics:Ribbon and Feign components to achieve request load balancing
03 Microservice foundation:Hystrix components to achieve service fuse
04 Microservice basics:Turbine components to implement microservice cluster monitoring
05 Microservice basics:Zuul components to implement routing gateway control
06 Microservice foundation:Config component, to achieve unified configuration management
07 Basic microservices:Zipkin component to implement request link tracking
08 Microservice Foundation:Comparative Analysis with Dubbo Framework and Boot Framework
09 Microservice Basics:Nacos Components, Services and Configuration Management
10 Microservice basics:Sentinel components, service current limit and downgrade
11 Microservices Application:Database Expansion Solution in Sub-database and Sub-table Mode
12 Microservice application:Shard-Jdbc sub-database sub-table, expansion solution implementation