Microservice Design Patterns - MacKittipat/note-developer GitHub Wiki

Service discovery

Service Registry

  • A database of services, their instances and their locations
  • Service instances are registered with the service registry on startup and deregistered on shutdown
  • Client of the service query the service registry to find the available instances of a service
  • Example : Eureka , Zookeeper, Consul, Etcd

Client-side discovery

  • When making a request to a service, the client service obtains the location of a service instance by querying a Service Registry
  • Client service is responsible for determining the network locations of available service instances and load balancing requests across them
  • Example : Ribbon

Server-side discovery

  • When making a request to a service, the client service makes a request to a service via a load balancer.
  • The load balancer queries the service registry and routes each request to an available service instance.
  • More latency between service because more network hop but no service discovery logic required on client service.
  • Example : AWS ELB

Reliability

Circuit Breaker

  • When the number of consecutive failures crosses a threshold, the circuit breaker trips
  • For the duration of a timeout period all attempts to invoke the remote service will fail immediately
  • Fail fast to prevent cascading failure
  • The circuit breaker pattern can help you avoid cascading failures, reduce timeouts, and provide fallback responses when a service is down or overloaded.
  • Example : Hystrix

External API

API gateway

Backend for front-end

Transaction

Sagas

  • A pattern to manage data consistency across microservices in distributed transaction scenarios
  • Create a sequence of local transaction in each services.
    • A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step
    • If a step fails, the saga executes compensating transactions that undo the preceding transactions
  • Background
    • 2 Phase Commit : Guarantee consistency but coordinator could be single point of failure, slow, impact availability.
  • Coordination model
    • Orchestration
      • Centralize approach, Coordinate sagas where a centralized controller tells the saga participants what local transactions to execute.
    • Choreography
      • Coordinate sagas where participants exchange events without a centralized point of control.
      • Having business logic related to Saga in each service which break the idea of loosely couple
  • Reference

References