Microservice technology stack: common registry components, comparative analysis
Posted Jun 15, 2020 • 7 min read
Introduction of Registration Center
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.
- Process and principle
- 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.
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.
Comparison of basic 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.
- 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.
- 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.
- 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.
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
GitHub·Address https://github.com/cicadasmile/husky-spring-cloud GitEE·Address https://gitee.com/cicadasmile/husky-spring-cloud
Recommended article:Microservices Basic Series