Service discovery deals with the problems about how microservices talk to each other, i.e. perform API calls. In a traditional network topology, applications have static network locations. Hence IP addresses of relevant external locations can be read from a configuration file, as these addresses rarely change.
In a modern microservice architecture, knowing the right network location of an application is a much more complex problem for the clients as service instances might have dynamically assigned IP addresses. Moreover the number instances may vary due to autoscaling and failures.
Hence, service discovery tools and patterns a
REST in its most simple definition is an architectural style that tries to solve machine to machine interaction problem. We always had the need to simply create programs that its main users are another programs. In ancient times we did this using soap protocol, RPC etc. At some point in time, a smart guy named Roy Fielding had the idea to take inspiration from a platform that solved a much harder problem: machine to human interaction. Which is, the web. It is one of the greatest successes in the history. If some guy had been charging a nickel anytime someone has visited a web page, he would be the richest man ever. So it's a good place to look for inspiration.
The Web solves the very same problems but under much harder context. Which are searching, combining, transforming data, caching, authentication providing good user experience, loose coupling, all in a distributed manner. So, It was a definitely good candidate to use in machine-to-machine interaction as well. It works on a couple of architectural foundations. So the first order of business is determining those foundations. Here's a good sum up. It thinks in resources. It then universally identifies and accesses to said resources. Those resources may have many representations. Those representations use hypermedia to point other resources. And all of that works on HTTP.
All these are there to provide a general purpose system that has flexibility, discoverability, and predictability.
There aren't any tightly coupled rigid contracts in web communication. As in we don't need a specification document to consume a page in Facebook. But all of it works gracefully because of these 3 core values are respected.
Big idea about rest is, what if we exposed the entities in our domain model as web resources and let other programs consumed those resources? Would it work? Well at this point of time where there are nothing but RESTful services we know that it worked.
Going after for those core values of flexibility, discoverability and predictability may be rather vague and obscure task for some people. But luckily another smart guy named Leonard Richardson developed a maturity model that lets us follow a couple of more strict guidelines to reach that glory fo REST. It is a great starting point for anyone wants to develop RESTful web services.
re developed to overcome these challenges. Mainly service discovery consists of a key-value store (Service Registry) and an API to read from and write to this store. New instances of applications are saved to this service registry and deleted when the service is down or not healthy. Clients, that want to communicate with a certain service are supposed to interact with the service registry to know the exact network location(s).
There are two main service discovery patterns that shape how clients interact with other services:
- Client-Side discovery pattern: Client talks directly with the service registry to receive the IP addresses of a certain service and uses its own load balancing algorithm to choose one of them. Although this approach is simple and straigtforward, it couples service discovery logic with clients.
- Server-Side discovery pattern: Client makes requests to a load balancer or an API gateway, which routes the requests to corresponding services. In this case API gateway is aware of the service registry and load balancing, which leaves clients abstracted from the service discovery logic. Maintaining a single point of failure API gateway is the main drawback of this approach.
Consul, Netflix Eureka, etcd, Apache Zookeeper are some of the most popular service discovery tools that are widely used and compatible with many platforms.
