Service Registry

A service registry is a central concept in the architecture of microservices. As discussed in the previous section, a service registry is an integral part of service discovery.

A service registry, in layman’s terms, is the network address and database of a storage network instance. A service registry should be highly available and its data up to date.

The client caches some network address data after querying the service registry. However, the expiration time of this information needs to be set, because the data can change in real time.

Therefore, a service registry should contain a cluster of servers in which data needs to be consistent across machines, with replication protocol between machines to do this.

Netflix Eureka is a good example of a service registry. It provides a REST API for registering and querying service instances. A service instance registers its network location using a POST request. Every 30 seconds, it must refresh the registration with a PUT request. Delete a registration by using HTTP delete request or instance registration timeout. Clients can retrieve registered service instances using HTTP GET requests.

Netflix ensures high availability of service registries by running multiple Eurekas on multiple Amazon servers, each of which runs on an EC2 instance and has a variable IP address. DNS TEXT is used to store the Eureka cluster configuration. This is a mapping to get a list of network locations of available Eureka servers.

When the Eureka server starts, it queries DNS to retrieve the Eureka cluster configuration, locate its corresponding node, and assign itself an unused IP address.

The Eureka client queries DNS to discover the network address of the Eureka server. The client is more likely to access the Eureka server in the same area. Of course, if no server is found, the client will also access the servers in other areas.

Other good service registries are:

• Etcd: A highly available, distributed, consistent key-value structure for sharing configuration information and service discovery. Kubernetes uses ETCD.
• Consul: A tool for discovering and configuring services that provides apis for registering and discovering services, consul performs health checks to ensure availability.
• Zookeeper: A widely used distributed high-performance service.

The implementation mechanism of the service registry is discussed below:

There are two main modes: one is self-registration mode; The other is the third party registration model.

Self-registration mode

In self-registration mode, each service instance is responsible for registering and unregistering with the service registry, and it also needs to send a heartbeat to keep the registration confidence from being expired.

Netflix OSS Eureka Client uses this mode.

EurekaClient is responsible for registering and unregistering services. In Spring Cloud projects, it is very convenient to register services with Eureka with just an annotation @enableEurekaclient

The advantage of self-registration mode is that it is simple and no additional components are required.

The downside, however, is that it is highly coupled, needs to be adapted to service registries, and is limited by programming languages and frameworks.

Third-party Registration Mode

With a third-party registration mode, a service instance is no longer responsible for registering and deregistering directly with the service registry; in fact, another third-party system component does the registration.

This third-party component monitors the cluster of running instances by polling the deployment environment or subscribing to an event. When it detects a new instance, it registers with the service registry and, as such, unregisters it.

An open source application called Registrator implements this registration component by automatically registering and unregistering service instances deployed in Docker environments. Etcd and Consul are supported.

Another is Prana for NetflixOSS, which supports non-JVM languages and supports Eureka.

The advantage of using a third-party pattern is that it is well decoupled from the service registry and does not need to implement code according to the requirements of the service registry.

The downside is that this third-party registry component must be highly available, which adds administrative complexity.

Source: www.imooc.com/article/291…

The article will be updated continuously. You can search “Maimo Coding” on wechat to read it for the first time. Every day to share quality articles, big factory experience, big factory face, help interview, is worth paying attention to every programmer platform.