I don’t understand the reasoning behind service discovery tools. I understand they are used so micro services can connect but why can’t we just store all the urls/load balancers in the config server as properties? Looking for some explanation for eureka over property file with the micro service urls.
Thanks
CodePudding user response：
Discovery service such as Eureka is used for registry purpose so that client can get the address from the registry prior to making a call to the service. It's norm in microservices that each service can have multiple instances running at a moment for handling the load.
why can’t we just store all the urls in the config server as properties?
If you put the address of the services in the property file of config server, how you'll register the address of another instance of the same service at run time and make a call to it. For scalability purpose you need to run more than one instance of service, so it is necessary to have discovery service where varying number (1...N) of instances of individual service get them registered and make themselves available to the clients with the help of discovery service. Of course, you've to use some orchestration service such as Kubernetes to handle how many instances you want to run for the service.
CodePudding user response：
In your example of putting a URL into a config, clients still needs to do discovery to find other micro services . In this case DNS is acting like a discovery service by converting URLs into IP Addresses (to the load balancer).
using a load balancer as state is "server side load balancing" in which a consumer sends a message to the load balancer and the load balancer sends it to the appropriate back end, in this example the load balancer can become a bottle neck on a very busy service.
An alternative is that the clients do their own load balancing by having a list of instances and choosing which ones to send it to based on reports of how busy certain instances are.
Both of these solutions have strengths and weaknesses, but a discovery service such as Eureka are required for the client side load balancing approach.
Services such as eureka often have other nice non-technical advantages, which DNS does not.
- The ability to record metadata against a service such as, which team in the company owns it, what it does.
- A central place to look up services when you are developing a new service.
- Some discovery services can track which services are looking up other services making it easy to do dependency analysis to work out what might break if a service is changed.
If the load balancer/DNS approach is working for you, a dedicated discovery service like Eureka might not fit your architecture.