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 a comprehensive set of resources for learning about microservices including articles, an O'Reilly training video, 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: