Service Instance Discovery
Context
Microservices are adopted. Microservice instances are deployed to a dynamic environment where fixed network addresses and ports are not guaranteed. Request-response 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
Introduce a service instance discovery mechanism to keep track of all running microservice instances and their network location. The discovery mechanism allows reconfiguration at runtime, acting as a configuration server specifically for reconfiguring the network location of microservice instances.
An API or library gives access to the current configuration to all deployed microservice instances. Alteratively, an internal integration proxy can be configured to forward requests to the tracked instances, or an internal DNS component can offer DNS-based routing between available microservice instances.
In implementations, we find infrastructure components that implement multiple techniques at once. Next to service instance discovery, they might offer additional functionalities like
- load balancing between the instance of a microservice, or
- circuit breaker functionality for better fault tolerance.
Service meshes can provide service instance discovery by using sidecars as well.
Maturity
Proposed, to be evaluated.
Sources of Evidence
L3:
- Dynamic service collaboration
- Service discovery, load balancer, circuit breaker
- Dependent services locate each other through discovery and balancer
- Devs became more comfortable with the new concepts by introduction of components => acceleration of migration
- Microservices need service discovery and load balancer to be fully functional.
- Service discovery
- separation into server and client component
- (+) removes need for manual wiring
- (+) promotes independent deployment pipelines
L5:
- Service discovery = ability of services to discover each other in consistent manner
- standard and consistent process of registration and announcing themselves
- helps consuming services to discover end points and locations
- involves right consumer strategy and how API gateways are configures to report service availability
L6:
- Context: DIMMER platform
- Service Catalog for service discovery [somewhat different scope as it is discovery for IoT devices]
L7:
- Context: comparison to SOA
- Category: Lookup at runtime and design time
- Microservices: Service discovery on application level and network level
- Open question how they should be found
L8:
- Service discovery technology as part of "second wave"
- e.g. ZooKeeper, Eureka, etcd, Synapse, Consul
- => "[...] let services communicate with each other without explicitly referring to their network locations"
- 8th wave: sidecars => encapsulates service discovery (among others)
- 1st gen: each service had to keep track of location of other service
- locating instances became huge issue with increasing number of services + different execution envs
- 2nd gen: service discovery
L9:
- Context: Case-Study on OpenStack with Microservices
- Configuration State Manager: uses etcd
- Each container sidekick process: monitors status => register/deregister service
- "service registration process" interplay with service orchestrator and ha proxy
- Alternative techologies: Consul, Eureka, SkyDNS, ZooKeeper
L12:
- Service Discovery as component that has to be utilized to benefit from all advantages
- microservice can each have instances => for scaling
- keeping track of exact address and port numbers is cumbersome
- Service Discovery as solution => get available instances of each service
- Combination with load balancer: scaling
- Example technology: Eureka
- part of Netflix stack; Ribbon as Load Balancer, Hystrix as Circuit Breaker, Zuul as Edge server
- Dynamic service collaboration
- service discovery, load balancer, circuit breaker
- components introduced early => devs more comfortable with these concepts for migration
L18:
- goal: high-availability
- greatest challenge service discovery problem => present Serfnode
- usual scenario: microservice has instances, running stopping over time
- availability cannot be counted on
- Service discovery: enable consumers to locate providers in real time and facilitate communication
- Serfnode as a sidecar!
- tightly aligns with monitoring: only keep place in registry if healthy
- metrics for instance location: minimize network hops, minimize total providers for given consumer, using oldest or newest provider
- Example technology: Consul
- service discovery and distributed configuration management (stronly consistent key-value store), monitoring, health checking
- requires multiple agents to be reliable
- quorum based => odd number
- Serfnode: decentralized open source service discovery problem + event-based communication
- more lightweight since only discovery
- easier to deploy ad reason about availability since every node same set of responsibilities
- but only eventual consistency
L19:
- "explosion" in service numbers, esp with different versions for each
- solutions like service discovery required, others: routing mechanism, configuration management
L20:
- context: pains and gains of microservices
- service location on place 2 in category "pains during operation stage"
- potentially huge amount of microservices
- partitioning into microservices can change (add / remove microservices flexibly)
- number of replicas can change (scale in and out)
- actual instance location can change (e.g. host, port) (migration from one host to another)
- service discovery pattern as 4th greatest gain in design stage
- service discovery and message broker mitigate pains of service location and coordination
- combination with circuit breaker
- mitigate pains related to failure and service coordination/location of microservices
L21:
- Distribution can utilize locality => services closer to clients serve => better geographical scalability
L24:
- service discovery one of the most well-known microservice patterns
- present in all investigated open source projects
L25:
- Context: Service discovery as part of "Orchestration and Coordination Architecture Patterns"
- multiple instances of a microservices usually run in different containers/VMs
- communication needs to be dynamically defined, clients need to communicate efficiently with changing instances of microservice
- service discovery supports resolution of DNS address to IP addresses
- cites Richardson
- client-side discovery
- clients query instances and make request directly
- client responsible for picking one of the available instances
- can serve as load balancer of the requests
- client uses load-balancing algorithm to select one of the available service instances to make request
- (-) clients need to know about service discovery mechanism
- (-) coupling between client and service registry
- (+) ease of development
- server-side discovery
- client make request to load balancer => queries registry and forwards request
- difference to API gateway: direct communication; the address is returned => no filter or service interface translation
- relies on service registry, acting in similar manner as a DNS server
- registry ensures availability of microservice instance before forwarding the IP address/DNS and port
- (+) increased maintainability
- (+) ease of communication: direct communication without of interpretation
- (+) health management: resilience and scalability mechanisms provide "health management" and outscaling for atomic/composed service
- (+) failure safety: failure => easy restarting due to stateless properties
- (+) software understandability => by small services
- (+) ease of deployment => by smaller services
- (+) ease if migration: switch between old and new version instances in registry
- (-) interface design must be fixed: to minimize impact of changes of internal changes; otherwise other services have to change as well
- (-) registry complexity: requires implementation of several interfaces per service ([interpretation] for registering instance)
- (-) reuse: registry can become bottleneck if not done right
- (-) distributed system complexity: direct communication increases communication between services, distributed transaction complexity, testing of distributed systems, including shared services among different teams can be tricky
- Hybrid pattern: combination of service registry and API gateway
- gateway replaced by message bus
- clients communicate with message bus => acts as registry, routes request to requested microservice
- microservices communicate with each other over message bus (analogy: ESB in SOA)
- (+) ease of migration: from SOA, ESB can be used in comm layer
- (+) learning curve: from SOA
- (-) SOA issues: no benefit from IDEAL properties of microservices and independence
- isolated state
- distribution
- elasticity
- automated management
- loose coupling
L31:
- Migration pattern 6: Introduce service registry
- Context
- decomposition into microservices
- each of the services have one or more instances into prod env
- number of instances can change dynamically, each of them deployed in different systems
- Problem
- how can services locate each other dynamically?
- how can edge server / load balancer know list of instances of a services to route the traffic
- Solution
- setup service registry to store service instances' addresses
- service instance registers during instantiation
- removal: (1) no heartbeats received (2) notification during service termination
- edge server and load balancer can use information to locate services dynamically
- needs to be available => otherwise other services cannot communicate
- use replication strategies and high availability mechanisms
- Challenges
- coupling to registry
- could become single point of failure if not done right
- Technologies: Eureka, Consul, Apache Zookeeper, etcd
- Context
- Migration pattern 7: Introduce service registry client
- Context
- decomposition into microservices
- service registry has been set up
- number of instances can change dynamically, each of them deployed in different systems
- Problem
- how registry knows a new instance has been deployed / terminated?
- Solution
- each service has to know address of service registry
- each service to register themselves at initiation
- use periodic heartbeat from each instance to keep list of available instances
- instance removal: (1) no heartbeats received (2) notification during service termination
- Challenges
- client has to be implemented for all programming languages in use
- bad implementation can complicate service code
- Technologies: Eureka as service registry, Java client implementation
- Context
- Both patterns spotted in all three cases
L34:
- Context: categorization of research challenges
- Service discovery as category
- process to determine and detect near services, register and maintain them over time
- considers strategies on gateway configuration, reporting service availability, ...
- keywords: discovery, registration, service registry
L37:
- Context: Framework for IoT based on microservices
- message driven and registry/discovery mechanism => framework can easily extend, evolve, and integrate 3rd party apps to support interoperability and scalability
L40:
- Growing adoption of microservices growing by ease of deploying and updating software
- but also by loose coupling provided by dynamic service discovery and binding
L42:
- Challenge: infrastructure for container management, service discovery and registration
L45:
- Context: migration: Architecture Recovery -> Architecture Refinement
- 1st refinement: service discovery resolution
- to resolve the service discovery services in order to reveal dependencies among microservices
- service discovery used to decouple microservices
- microservice can change status dynamically (e.g. IP address) for several reasons (upgrades, autoscaling, failure)
- => discovery allows microservices to find each other in network dynamically
- (-) but mask real resource dependencies among microservices
- => refined architecture model to reveal dependencies
- example with Acme Air: Nginx as discovery; links towards it predominant
L52:
- Discovery as part of Management Capabilities of reference architecture in "outer architecture"
L53:
- Service Discovery
- Pattern type: Action
- Solution of: system coupling
- Qualities: dynamic reconfiguration; extensibility
- Context: IoT Microservices
- "service description and discovery" in the sense of discovering a potential microservice (not its instance)
- description of service in syntax and semantics
- ontology for semantics
L54:
- Context: Development requirements of microservices
- service discovery: knows what is running on specific environment to allow each service relying on another service knows about the other
- 2-part process
- service registers itself
- tries to find other services after registration
- Technologies: Zookeeper, Consul, Eureka are widely used service registries
- required to ease up management and monitoring of containerized services
L55:
- Context: microservice-based middleware for digital factory
- gateway based on Netflix Ribbon in collaboration with service registry
- load balancing, circuit breaker
- service registry (SOA enabling services)
- REST endpoint for service discovering
- allows transparent and agnostic service communication and load balancing
- technologies: Netflix Eureka
- exposes API for registration and querying => services can communicate without referring to specific IPs
- especially important in scenario where services are replicated for coping with high workload
L59:
- need for systems as service catalogs and messaging and queueing services to discover them and route calls ito correct service instances
- calls go through proxy or messaging layer that finds a suitable instance
L61:
- discovery 4th most often used pattern in microservices
- related to quality attributes maintainability and performance
L63:
- Context: MiCADO - an Microservice-based Cloud Orchestrator
- Discovery of instances part of a cluster manager / container orchestrator
- Microservices discovery and execution layer
- manages execution of microservices
- keeps track of services running
- implemented by Occopus
- Startup and shut-dwn of microservices
- Gathers info about running services: service name, IP address, port, where reachable, tags
Interview B:
- cannot hardwire microservices => need for service registry / discovery (amont others)
- part of the gateway or service mesh?
LN21:
- Microservice can have thousands of physical instances (different containers), managed by service discovery
- Dynamic behavior: create, destroy, scaling, invocations of microservice may be accomplished by different instances
- Containers can be managed by clusters doing
- among others: service discovery, service registry, load balancing, config management
- Technologies: Spring Cloud, Mesos, Kubernetes, Docker Swarm
- If Docker => Kubernetes => provides service discovery next to horizontal scaling and load balancing
- node discovery as classic challenge of distributed systems
- Orchestration layer: service discovery provides DNS-like central point for locating services
- Attack vector: compromise service discovery, register malicious nodes, redirect communication
- service discovery as major challenge
- API Proxy uses config storage and API proxy to achieve service discovery
- stores IP, port, timeouts, endpoints, ...
- Config updated by CI (Jenkins)
LM43:
- Context: SLR findings about microservices in DevOps
- Service discovery ub S12 and S33
- client-side discovery, server-side discovery, service registry, self-registration, third-party registration
- Table 10: lists server-side and client-side discovery, service discovery, self-registration, third-party registration
- SMS revealed patterns for, among others, service discovery
LM47:
- Context: SLR with tactics to achieve quality attributes
- service registry stores location of all running services in a central point
- ther microservices can receive binding information about other microservices
- Motivation: multiple instances, change over time, need to locate position to detect faults
- Description: automatically register microservices with their addresses
- remove instances when periodic heartbeat fails
- some use client-side implementations to include services of other vendors / previous system automatically
- types:
- self-registry: each service responsible to register/deregister
- third-party registry: automatic registration via 3rd party registry service
- registrar and service registry components; no need for service specific lib
- checks availability
- Registrator and Prana from NetflixOSS
- manual registry
- better interoperability: include microservices from other systems
- takes time to respond to failures where no health check possible
- => suitable for systems that run with high availability and stable for a long time already
- Constraints: couple to registry, can become poing of failure
- impl of clients should adapt to all programming languages used
LM48:
- Context: microservice migration describes an examples project (FX Core) and compares back to monolith
- diffusion of SOA due to shortcomings related to service discovery: dynamic binding and invocation
- microservice orchestration tools try to overcome that
- keep track of running instances and how to reach them
- typically done with service discovery tool
- either separate service: Consul
- or part of orchestration tool
- more than DNS lookup
- health checking to ensure service is alive/available
- can make use of locality
- gives illusion of interacting with single service instead of multiple replicas
- is a MUST
- services don't have static IP, mapping required
- load balancing: typically implemented as part of service discovery and orchestration
- Swarm cluster also handles service discovery and load balancing
- hostname lookup from containers translated to IPs of concrete containers
- discovery only of infrastructure services as RabbitMQ serves as interaction point between services
- Orchestration (Kubernets, Mesosphere Marathon, Docker Swarm) provide number of features for scalability
- among others: service discovery
Interview B:
- cannot hard-wire services to each other
- need for a service registry / discovery
- need for resilience patterns and load balancing
- is it part of the gateway? is it solved by the k8s cluster? if using service meshes, is it part of that?