[Translation] Microservice Design Pattern-7. Service Discovery-Self-Registration

> Original address: https://microservices.io/patterns/self-registration.html


# Background


Assuming that you use client-side service discovery or server-side service discovery, you need to register an instance with the registry when the service is started, and log out of the registry when it is closed, so that other services can be aware of it.


# Question


How to register or cancel a service instance with the registry?


# Considerations


 -The service must register an instance with the registry when it is started, and deregister the instance in the registry when it is shut down

 -The crashed service instance must be deregistered from the registry

 -Instances that are running but cannot provide services normally also need to be deregistered in the registry


# solution


The service instance ** is responsible for registering itself in the registry**. At startup, the service instance registers itself (host and IP address) with the service registry so that it can be discovered. The client usually must send heartbeats periodically so that the registry knows that it is still running. Upon shutdown, the service instance unregisters itself from the registry.


The general microservice basic framework will have this mechanism.


# Example


We write an example in Scala, use SpringBoot and SpringCloud as the microservice framework, and use the Netflix Eureka service registry. Using the annotation `@EnableEurekaClient` on the `@Configuration` Spring framework configuration class will allow the instance to be registered with Eureka after startup


```

@Configuration

@EnableEurekaClient

class EurekaClientConfiguration {

```


# Result analysis


**Self-registration** The benefits of this design pattern are:

 -The service instance knows its real state, so it can implement a more complicated state mechanism than only the two states of UP/DOWN, such as STARTING, AVAILABLE, etc.

There are also some disadvantages of this design that need to be carefully considered and avoided:

 -**Coupled with the registration center**, you must write a new implementation if you change a registration center

 -If different microservices in your microservice system use different programming languages ​​or framework systems, you need to **implement a unified registration logic** for these.

 -Instances that are running but cannot process requests normally, generally cannot be sensed by themselves, so they are logged out in the registry.


# Related Mode


 -**Registration Center**-the core of service discovery

 -**Client Service Discovery** and **Server Service Discovery**

 -**Microservice basic framework**-General microservice basic framework has self-registration function implementation

 -**Third Party Registration**-Another alternative design pattern


Guess you like

Origin blog.51cto.com/11418075/2663788