The original address: microservices. IO/patterns/se…

background

If you use client-side service discovery or server-side service discovery, the service needs to register the instance with the registry when it is started and unregister with the registry when it is shut down for other services to be aware of.

The problem

How do service instances register or unregister with the registry?

consideration

  • The service must register instances with the registry when it is started and unregister instances with the registry when it is shut down
  • Crashed service instances must be unregistered from the registry
  • Instances that are running but cannot provide services properly also need to be unregistered in the registry

The 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 must usually send a heartbeat periodically so that the registry knows it is still running. On shutdown, the service instance unregisters itself from the registry.

This mechanism is common in microservices infrastructure frameworks.

For example,

Let’s write an example in Scala using SpringBoot and SpringCloud as microservice frameworks to Netflix Eureka service registry. Using the @Enableeurekaclient annotation on the @Configuration Spring framework Configuration class will register the instance with Eureka upon startup

@Configuration
@EnableEurekaClient
class EurekaClientConfiguration {
Copy the code

Results analysis

The benefits of self-registering this design pattern are:

  • A service instance knows its true state, so it can implement a more complex state mechanism than just UP/DOWN, such as STARTING, AVAILABLE, and so on

There are some downsides to this design that need to be carefully considered and avoided:

  • Coupled to a registry, a new registry is written
  • If different microservices in your microservice system use different programming languages or frameworks, then you need to implement unified registration logic for these.
  • Instances that are running but cannot handle requests properly are generally undetected and unregistered in the registry.

Related patterns

  • Registry – the core of service discovery
  • Client service discovery and server service discovery
  • Microservices Infrastructure – Most microservices infrastructure frameworks have self-registered functionality implementations
  • Third party registration – another alternative design pattern