Unveiling the Core Mechanics of Spring Cloud Config Center

From Spring Boot Startup Process

When a Spring Boot application starts, the SpringApplication.run method executes three main phases:

ApplicationContext refresh pre‑phase : prepares the Environment , creates an ApplicationContext , and performs initial setup.

ApplicationContext refresh phase : invokes ApplicationContext#refresh to refresh the container.

ApplicationContext refresh post‑phase : finalizes the startup.

Which phase is most likely to pull configuration from the config center?

The answer is the pre‑phase, because it prepares the Environment , where externalized configuration is loaded.

Core Operations of prepareEnvironment

The prepareEnvironment method first creates an Environment instance and then calls listeners.environmentPrepared(environment) , which triggers the EventPublishingRunListener#environmentPrepared method and publishes an ApplicationEnvironmentPreparedEvent . Two important listeners handle this event:

ConfigFileApplicationListener – parses local configuration files and adds them to the Environment .

BootstrapApplicationListener – interacts with the configuration center.

These listeners are loaded from spring.factories during the early startup.

How Spring Cloud Cleverly Pulls Configurations

BootstrapApplicationListener creates a dedicated Spring container (a SpringApplication) whose purpose is to communicate with the configuration center. This container:

Loads the bootstrap configuration file.

Loads all classes referenced by the org.springframework.cloud.bootstrap.BootstrapConfiguration key in spring.factories .

Within the spring-cloud-context module, PropertySourceBootstrapConfiguration registers a collection of PropertySourceLocator beans. The PropertySourceLocator interface defines a strategy for locating (potentially remote) property sources for the Environment . Implementations fetch configuration from remote config centers and place it into the Environment , making the properties available during the normal ApplicationContext refresh.

Dynamic Bean Property Refresh

To enable dynamic refresh, beans are annotated with @RefreshScope . Spring registers two beans for each such component:

The first bean is a proxy (generated by ScopedProxyFactoryBean ) that is injected into other components.

The second bean is the actual target bean (e.g., UserService ) with scope refresh .

When the configuration center detects a change, it publishes a RefreshEvent . RefreshEventListener receives this event and triggers the same bootstrap logic used at startup to re‑fetch the latest configuration. After fetching, Spring destroys the target beans (the second beans) while keeping the proxy beans intact. The next time the proxy bean is used, Spring recreates the target bean with the updated properties, achieving a seamless property refresh.

The underlying mechanism relies on the Scope interface; the refresh scope stores its beans in RefreshScope . Destroying and recreating beans in this scope updates the injected values.

Integrating Open‑Source Config Centers

To integrate a config center with Spring Cloud, two steps are required:

Implement PropertySourceLocator and register it via org.springframework.cloud.bootstrap.BootstrapConfiguration in spring.factories .

Provide beans that publish RefreshEvent when configuration changes occur.

For example, Nacos integrates by defining NacosConfigBootstrapConfiguration (which registers NacosPropertySourceLocator ) and NacosConfigAutoConfiguration (which publishes refresh events). Similar patterns apply to other config centers like Consul, while Apollo requires a custom adapter.