In a microservice architecture, the services are dynamic in nature. They will go down and come up based on traffic or any other configuration. Due to this dynamic nature, there should be a separate, highly available server that holds the essential configuration details that all the servers need to know.
For example, our pricing service will need to know where the registry service is and how it has to communicate to the registry service. The registry service, on the other hand, should be highly available. If for any reason the server has to go down, we will spin up a new server. The pricing service needs to communicate with the config service in order to find out about the registry service. On the other hand, when the registry service is changed, it has to communicate the changes to the config server, which will then cascade the information to all the necessary services.
Spring cloud config server (https://github.com/spring-cloud/spring-cloud-config) provides server and client-side support for external configuration.
With the cloud config server, we have a central place to manage all our external properties across all environments. The concept is similar to Spring-based environment property source abstractions on both client and server. They fit for any application running in any language.
They are also helpful for carrying the configuration data between various (development/test/production) environments and help to migrate much easier.
Spring config server has a HTTP, resource-based API for external configuration. They will encrypt and decrypt property values. They bind to the config server and initialize a Spring environment with remote property sources. The configuration can be stored in a Git repository or in a file system.