Microservice registration is the core component of microservices, and the common ones are: ZooKeeper, Consul, Nacos, Eureka, etc. Wait, I'll focus on explaining the @mikechen of microservice registration in detail
Microservice registration
Service registration refers to the registration of one's own service information to the registry, including the IP address of the host where the service is located, the port number of the service, and the exposure service agreement.
As shown in the figure below:
Image
Service B registers itself with the registry, which is called service registration.
Service Registration Role
Service registration is the maintenance of a registry that manages all service addresses within the system.
When the new service is started, it will present its address information to the register, and the relying party of the service will directly ask the registry for the service address.
At the same time, the service registration is also responsible for one thing, the maintenance of the service state, if a service suddenly goes down, it should be able to perceive and remove the down service, and then actively or passively inform the service consumer of this information.
Service registration implementation
There are two forms of service registration: client registration and proxy registration.
1. Client Registration
Client registration is the work of the service itself to be responsible for registration and cancellation, when the service is started, the registration thread registers with the registry, and when the service goes offline, it cancels itself.
Image
The disadvantage of this method is that the registration and cancellation logic is coupled with the business logic of the service, and if the service is developed in different languages, it needs to adapt multiple sets of service registration logic.
2. Agent registration (third-party registration)
Proxy registration, also known as third-party registration, refers to a separate proxy service that is responsible for registration and cancellation.
When the service provider initiates it, the proxy service is notified in some way, and the proxy service is then responsible for initiating the registration with the registry.
Image
The advantage of third-party registration is that the service is separated from the service registry, and there is no need to complete the service registration logic for each programming language and architecture, and instead, the service instance is managed through a centrally managed service.
The disadvantage of this approach is that it references an additional proxy service, and the proxy service needs to be configured to manage a highly available system.
Microservice registration framework
There are many tools for service registration: ZooKeeper, Consul, Etcd, and Netflix's Eureka to name a few.
1.ZooKeeper
Here, the implementation of service registration will be implemented using Zookeeper's watch mechanism.
For example, if a client registers to listen to the directory node it cares about, Zookeeper will notify the client when the directory node changes (data changes, is deleted, subdirectory nodes are added or deleted).
The client will set up a watcher event for a znode, and when the znode changes, zk will actively notify the client of the znode, and then the client will make business changes according to the change of znode.
As shown in the figure below:
Image
2.Consul
Consul is an open-source tool from HashiCorp for service discovery and configuration of distributed systems.
Consul架构，如下图所示：
Image
The datacenter is divided into two parts, but these two parts are not completely isolated, and they interact with each other through WAN GOSSIP.
3.Etcd
Etcd is an open-source, highly available, distributed key-value storage system developed in Go, which can be used to configure the registration and discovery of shared services.
The ETCD architecture is shown in the following figure:
Image
From the architecture diagram, we can see that etcd is divided into four main parts:
- HTTP Server
It is used to process API requests sent by users, as well as synchronization and heartbeat information requests from other Etcd nodes.
- Store
It is used to process transactions for various functions supported by Etcd, including data indexing, node state changes, monitoring and feedback, event processing and execution, and so on.
- Raft
Raft is a concrete implementation of the strong consistency algorithm and is the core of Etcd.
- WAL
Write Ahead Log, a write-ahead log system, is the data storage method of Etcd, which is persisted through WAL, which is similar to the MySQL persistent storage mechanism.
Write-Ahead Logging is an efficient logging algorithm in databases, and disk I/O operations are a major bottleneck for non-in-memory databases.
With the same amount of data, the disk write operation of the database system using WAL logs is only about half of that of the traditional rollback journal when the transaction is committed, which greatly improves the efficiency of the database disk I/O operation and thus improves the performance of the database.
4.Eureka
Eureka serves as the registry for the Spring Cloud microservices framework, which corresponds to ZooKeeper for the Dubbo framework.
The basic architecture of Eureka is shown in the following figure:
The diagram above briefly describes the basic architecture of Eureka, which consists of 3 roles:
1.Service Provider： 暴露服务的服务提供方。
2)Service Consumer：调用远程服务的服务消费方。
3) EureKa Server: Service Registry and Service Discovery Center.
No matter what kind of tool is used, service registration must ensure high availability, otherwise all services cannot be called, or new services cannot be launched, so solutions such as local cached service addresses are generally considered.
For more information, please click Full-Scenario Live Streaming Solution - Aerospace Cloud Network Solution