Skip to main content

Instance Discovery by Message Broker

Context​

Microservices are being adopted. Microservice instances are deployed to a dynamic environment where fixed network addresses and ports are not guaranteed. Event-based communication between microservices is facilitated.

Problem​

  • Changing network addresses and ports of microservice instances break communication with clients.
  • Microservices might be configured to direct traffic to instances of other microservices that are not available any more
  • Newly deployed microservice instance might not get traffic since other microservices don't know of them

Solution​

Use a message queue that already comes with service instance discovery functionality.

In migration scenarios from SOA, the ESB can be used. However, make sure to keep the business logic within the microservices.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

This technique builds on classical service instance discovery and used it as basis to formulate the context and the problem statement.

L20:

  • service discovery and message broker to mitigate pains of service location and coodrination

L25:

  • Hybrid pattern: message bus replaces API gateway and acts as service registry
  • routes messages to requested microservices; communicate with each other over message bus, smiliar to ESB in SOA
  • (+) ease of migration from SOA as ESB is already there
  • (+) learning curve: familiar already from SOA
  • (-) still uses ESB

L34:

  • Context: SCS as specialzed type of microservice architecture
  • Example: communication between microservices over a message broker
  • message broker seems to deal with message delivery

L37:

  • message driven registry/discovery mechanism
  • (+) easy extend and integrate 3rd party applications to support interoperatblity and scalabiltiy

L40:

  • existing middlewares offer event notification
  • helps to cope with complexity of connecting multiple entities
  • even with dynamic discovery of components

L59:

  • need for service catalogs and messaging and queuing service to discover and route calls to correct service instance

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • RabbitMQ between business services
    • all replicas of a service subscribe to same queue to share load
      • round robin
      • ackowledgements on successful processing; if not processed: handed to another replica => at-least-once execution
      • if not working: into error queue notifying devs
    • interpretation: RabbitMQ keeps track of replicas: acts as a service discovery