In the context of Microservices, service instances could change dynamically because of autoscaling, failures, and upgrades, so that the traditional way of hard coding the static network location (ip, port) is not sufficient.
Service Discovery as an architecture pattern provides a central data store known as Service Registry to bridge between the client (your application) to other instances in the cloud.
For example, you could code your app to call the Logging microservice with the key "logging". Then in the service registry, "logging" will be mapped to the live-and-healthy instances.
This is just a brief introduction, take some time to read the article and other Microservice strategies if necessary. Hope this helps 🙂
Hi, I'm also new to this, but I can share a great article that had helped me a lot to understand the concept and its big picture.
nginx.com/blog/service-discovery-i...
In the context of Microservices, service instances could change dynamically because of autoscaling, failures, and upgrades, so that the traditional way of hard coding the static network location (ip, port) is not sufficient.
Service Discovery as an architecture pattern provides a central data store known as Service Registry to bridge between the client (your application) to other instances in the cloud.
For example, you could code your app to call the Logging microservice with the key "logging". Then in the service registry, "logging" will be mapped to the live-and-healthy instances.
This is just a brief introduction, take some time to read the article and other Microservice strategies if necessary. Hope this helps 🙂
Thanks @kinopyo , I've done some googling myself and was able to get a generic idea. I was looking for a simplified explanation here, like I am five.