Notes
  • Blockchain
  • About this repository
  • References
  • Carret Position
  • Loggia and Balcony
  • automobile
    • Motorbike
  • computer
    • Kubernetes Event-driven Autoscaling (KEDA)
    • Protobuf
    • [[Amazon]] [[Identity and Access Management]] ([[IAM]])
    • Apdex
    • Architecture Decision Record
    • Audio
    • [[Amazon Web Services]] (AWS) Lambda
    • Blockchain
    • C/C++
    • Cache line
    • Caching strategies
    • Database
    • Design Patterns
    • Docker compose
    • Event Driven Design
    • False sharing
    • Git
    • [[Go]] common mistakes
    • [Go] [[subtests]]
    • Go
    • Janus
    • Jest
    • Kubernetes
    • Log-Structured Merge-tree
    • Media server
    • MySQL: Charset, Collation and UCA
    • Netflix
    • Opus Codec
    • Process, Thread
    • ReDoS - [[Regular expression]] Denial of Service
    • Rust
    • ScyllaDB
    • Shell Functions
    • Signals (The GNU Library)
    • Solidity
    • Sources
    • SQL
    • Transmission Control Protocol (TCP)
    • Ten design principles for Azure applications
    • Transient Fault Handling
    • twemproxy
    • Video
    • Web2 vs Web3
    • WebRTC
    • Microservice architecture
      • 3rd party registration
      • Command Query Responsibility Segregation (CQRS)
      • Access token
      • Aggregate
      • API Composition
      • API gateway/Backends for Frontends
      • Application metrics
      • Audit logging
      • Circuit Breaker
      • Client-side discovery
      • Client-side UI composition
      • Consumer-driven contract test
      • Consumer-side contract test
      • Database per Service
      • Decompose by business capability
      • Decompose by subdomain
      • Distributed tracing
      • Domain event
      • Domain-specific
      • Event sourcing
      • Exception tracking
      • Externalized configuration
      • Health check API
      • Log aggregation
      • Log deployments and changes
      • Messaging
      • Microservice architecture
      • Microservice Chassis
      • Multiple Service instances per host
      • Polling publisher
      • Remote Procedure invocation
      • Saga
      • Self-contained service
      • Self registration
      • Server-side discovery
      • Server-side page fragment composition
      • Serverless deployment
      • Service Component test
      • Service deployment platform
      • Service instance per Container
      • Service instance per VM
      • Service mesh
      • Service per team
      • Service registry
      • Service template
      • Shared database
      • Single Service instance per host
      • Transaction log tailling
      • Transactional outbox
  • food-and-beverage
    • Cheese
    • Flour
    • Japanese Plum liqueur or Umeshu
    • Sugar
  • management
    • Software Engineering processes
  • medic
    • Desease, disorder, condition, syndrome
    • Motion Sickess
  • others
    • Elliðaey
    • ASCII art
    • Empirical rule
    • Hindsight bias
    • Outcome bias
    • Tam giác Reuleaux
    • Luật Việt Nam
  • soft-skills
    • Emotional intelligence
Powered by GitBook
On this page
  • Context
  • Problem
  • Forces
  • Solution
  • Examples
  • Resulting context
  • Related patterns
  1. computer
  2. Microservice architecture

Self registration

Context

You have applied either the [[Client-side Service Discovery]] pattern or the [[Server-side Service Discovery]] pattern. Service instances must be registered with the service registry on startup so that they can be discovered and unregistered on shutdown.

Problem

How are service instances registered with and unregistered from the service registry?

Forces

  • Service instances must be registered with the service registry on startup and unregistered on shutdown

  • Service instances that crash must be unregistered from the service registry

  • Service instances that are running but incapable of handling requests must be unregistered from the service registry

Solution

A service instance is responsible for registering itself with the service registry. On startup the service instance registers itself (host and IP address) with the service registry and makes itself available for discovery. The client must typically periodically renew its registration so that the registry knows it is still alive. On shutdown, the service instance unregisters itself from the service registry.

This is typically handled by a [[Microservice chassis]] framework

Examples

Service registration is configured using the @EnableEurekaClient on a Java config class:

@Configuration
@EnableEurekaClient
class EurekaClientConfiguration {

This annotation causes the service instance to be registered with Eureka.

Resulting context

The benefits of the Self Registration pattern include the following:

  • A service instance knows its own state so can implement a state model that's more complex than UP/DOWN, e.g. STARTING, AVAILABLE, …

There are also some drawbacks:

  • Couples the service to the [[Service Registry]]

  • You must implement service registration logic in each programming language/framework that you use to write your services, e.g. NodeJS/JavaScript, Java/Scala, etc.

  • A service instance that is running yet unable to handle requests will often lack the self-awareness to unregister itself from the service registry

Related patterns

  • [[Service Registry]] - an essential part of service discovery

  • [[Client Side Discovery]] - one way that a service instance is discovered

  • [[Server Side Discovery]] - another way a service instance is discovered

  • [[Microservice chassis]] - self registration is the responsibility the microservice chassis framework

  • [[3rd Party Registration]] is an alternative solution

PreviousSelf-contained serviceNextServer-side discovery

Last updated 2 years ago

The is an example of an application that uses self-registration. It is written in [[Scala]] and uses [[Spring Boot]] and [[Spring Cloud]] as the [[Microservice chassis]]. The application uses the [[Service Registry]], which is a component.

Microservices Example application
Eureka
Netflix OSS