Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action and the creator of the original CloudFoundry.com. His latest startup is eventuate.io, a microservices application platform.
He offers microservices consulting, workshops and hands on training classes.Learn More
Join the microservices google group
Services typically need to call one another. In a monolithic application, services invoke one another through language-level method or procedure calls. In a traditional distributed system deployment, services run at fixed, well known locations (hosts and ports) and so can easily call one another using HTTP/REST or some RPC mechanism. However, a modern microservice-based application typically runs in a virtualized or containerized environments where the number of instances of a service and their locations changes dynamically.
Consequently, you must implement a mechanism for that enables the clients of service to make requests to a dynamically changing set of ephemeral service instances.
How does the client of a service - the API gateway or another service - discover the location of a service instance?
When making a request to a service, the client obtains the location of a service instance by querying a Service Registry, which knows the locations of all service instances.
The following diagram shows the structure of this pattern.
This is typically handled by a Microservice chassis framework
Netflix OSS provides a good example of client-side discovery:
Client-side discovery has the following benefits:
Client-side discovery also has the following drawbacks: