Service Registry

In the architecture of microservices, a service registry is a core concept. As mentioned in the previous section, a service registry is an integral part of service discovery.

A service registry, in general, is a network address and database that stores network instances. A service registry should be highly available and its data up to date.

The client will cache part of the network address data after querying the service registry. However, this information needs to be expired because the data will change in real time.

A service registry, therefore, should contain a cluster of servers in which data between machines needs to be consistent, and the machines do this through the Replication protocol.

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

Netflix ensures high availability in the service registry by running multiple Eureka’s on multiple Amazon servers, each running on an EC2 instance with a variable IP address. The DNS Text is used to store the Eureka cluster configuration. This is a mapping that is used to get a list of network locations of available Eureka servers.

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

The Eureka client finds the network address of the Eureka server by querying the DNS. The client is more likely to visit the Eureka server in the same region. Of course, if the server is not found, it will also visit the servers in other regions.

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, provides APIs for registering and discovering services, and to ensure availability, Consul performs health checks.
  • ZooKeeper: A widely used distributed high-performance service.

The following is the implementation mechanism of the service registry:

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

Self-registration mode

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

The Netflix OSS Eureka Client uses this pattern.

The EurekaClient is responsible for registering and unregistering services. In Spring Cloud projects, it is easy to register services with Eureka by simply adding an annotation to @EnableEurekaclient

The advantage of the self-registration pattern is that it is simple and requires no additional components.

The downside, however, is that the coupling is high, the need to adapt to a service registry, and the use of programming languages and frameworks is limited.

Third party registration mode

With the third party registration pattern, the service instance is no longer responsible for registering and de-registering directly with the service registry; in fact, another third party’s 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 finds a new instance, it registers with the service registry and, again, unregisters it.

An open source piece of software called Registrator implements this registration component, which automatically registers and unregisters service instances deployed in the Docker environment. ETCD and Consul are supported.

The other is Prana on Netflixoss, which supports non-JVM languages and supports Eureka.

The advantage of using a third-party schema is that it is decoupled from the service registry without the need to implement the code as required by the service registry.

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

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

The article will also be updated continuously. You can search “Maimo coding” for WeChat to read it first time. Every day to share quality articles, Dachang experience, Dachang face, help interview, is a platform worth paying attention to every programmer.