How Spring Cloud Config Works: Build and Use a Service Configuration Center

When the number of microservices grows, each service maintains its own configuration file, making manual updates cumbersome and error‑prone; a service configuration center solves this problem.

Among open‑source configuration centers, Spring Cloud Config integrates seamlessly with the Spring ecosystem. It consists of a server that reads configuration from a repository and clients that fetch the configuration at startup.

First, a Git repository is prepared (e.g., https://gitee.com/pzblogs/config-demo) containing two property files:

config-client.properties
blog.name=hello123

config-client-dev.properties
blog.name=gogogo123

Next, a Spring Boot project named config-server is created. Its pom.xml includes the dependencies spring-cloud-config-server and the spring-cloud-dependencies BOM (version Edgware.SR3).

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>1.5.4.RELEASE</version>
</parent>

<dependencies>
  <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
  </dependency>
</dependencies>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>Edgware.SR3</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

The main class is annotated with @EnableConfigServer:

@EnableConfigServer
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Server configuration ( application.properties) points to the Git repo:

spring.application.name=config-server
server.port=9010
spring.cloud.config.server.git.uri=https://gitee.com/pzblogs/config-demo
spring.cloud.config.server.git.username=
spring.cloud.config.server.git.password=

For the client, a Spring Boot project named config-client is created with dependencies spring-boot-starter-web and spring-cloud-starter-config. Its application.properties sets the service name and port, while bootstrap.properties tells the client where to find the config server:

# application.properties
spring.application.name=config-client
server.port=9011

# bootstrap.properties
spring.cloud.config.uri=http://localhost:9010/
spring.cloud.config.name=config-client
spring.cloud.config.profile=default
spring.cloud.config.label=master

A simple controller reads the property blog.name:

@RestController
public class HelloController {
    @Value("${blog.name}")
    private String name;

    @RequestMapping("/hello")
    public String hello() {
        return name;
    }
}

When the client runs, accessing http://localhost:9011/hello returns hello123 (default profile). Changing spring.cloud.config.profile=dev makes the same endpoint return gogogo123, confirming that the client fetches the correct profile from the server.

Because the client does not automatically detect changes in the Git repository, the article shows how to enable dynamic refresh. Adding the spring-boot-starter-actuator dependency, disabling default security ( management.security.enabled=false), and annotating the controller with @RefreshScope allow the client to reload configuration via the /refresh endpoint.

# pom.xml addition
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

# application.properties to disable security
management.security.enabled=false

@RestController
@RefreshScope
public class HelloController {
    @Value("${blog.name}")
    private String name;

    @RequestMapping("/hello")
    public String hello() {
        return name;
    }
}

After modifying config-client.properties in the Git repo (e.g., changing blog.name=hello123456), a POST request to http://localhost:9011/refresh triggers the refresh, and a subsequent call to /hello returns the updated value.

In summary, a configuration center centralizes common variables across distributed services, reducing inconsistency. However, refreshing many clients manually can be tedious; the next article will explore using a message queue to broadcast refresh commands and further lower operational overhead.