In the example solution described previously, all of the applications must hold the network location of the configuration server. The network location of service discovery is stored there as a property. At this point, we are confronted with an interesting problem to discuss. We could ask whether our microservices should be aware of the Config Server's network address. In previous discussions, we have agreed that the main place all the service’s network locations should be kept is the service discovery server. The configuration server is also a Spring Boot application like other microservices, so logically it should register itself with Eureka to enable the automated discovery mechanism for other services that have to fetch data from the Spring Cloud Config Server. This in turn requires placing the service discovery connection settings in bootstrap.yml instead of the spring.cloud.config.uri property.
Choosing between these two different approaches is one of...
