Menu
As far as I can tell, "service discovery" means a way for a client to find out about a server (or cluster of servers) that it wants to connect to.
I've built web applications that communicate with other back-end processes using protocols like HTTP and AMQP. In those, each client has a config file that contains a host name or whatever information it needs to connect to the server, which gets set at deployment time using a configuration tool like Ansible. That's simple and seems to work pretty well.
Is service discovery an alternative to just putting server information in a client's config file? If so, why is it better? If not, what problem does it solve?
644
3. The Need for Service Discovery. A microservice needs to know the location (IP address and port) of every service it communicates with. If we don't employ a Service Discovery mechanism, service locations become coupled, leading to a system that's difficult to maintain.
Service discovery is the automatic detection of devices and offered services over a network. Discovery, which minimizes configuration efforts for administrators, is commonly found in microservice architectures and containerization platforms.
Service discovery is how applications and (micro)services locate each other on a network. Implementations include both a central server(s) that maintain a global view of addresses and clients that connect to the central server to update and retrieve addresses.
A popular example of server-side service discovery is Amazon Web Services (AWS) Elastic Load Balancer (ELB). The ELB is used to balance the load of external traffic from the internet, as well as internal traffic directed to a virtual private cloud (VPC). The client makes a request through the ELB using its DNS name.
Let's start by reviewing what service-discovery is - here's a good explanation: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ (this link should pretty much clarify the issue asked)
And here's an example how it is used in practice: Suppose you have service B which is used by service A. Service B (like most services in SOA) is actually a cluster of applications of type B. Service A requires to use one of the nodes of cluster B, yet the cluster of B nodes is dynamic. i.e. B nodes are created and terminated, depending on the load on the overall B service. Now, we would like service A to communicate with a live B node every time it needs to use service B. In order to do so, we will use the service-discovery tool to provide us, at any given time, an address of one of the live B nodes.
So, trying to answer your above questions, putting the end-point server information (specifically endpoint address) as static configuration in a config file which is read at the startup of service A, won't give you the dynamics you'd like when service B endpoints may constantly change.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
