Config Center

A config center manages application configuration centrally and supports dynamic refresh, multi-environment, and gradual rollout. Common products: Nacos, Apollo, Spring Cloud Config, Consul. This article explains roles, model, and usage with a comparison table.

Overview

Centralized: Config stored in the center; apps fetch at startup or runtime. Avoids config scattered across machines and environments.
Dynamic refresh: On change, config is pushed or polled to clients; no restart needed. Spring @RefreshScope, Nacos listeners, etc.
Multi-environment: dev, test, prod isolated; by profile, dataId, group.
Gradual rollout: Some instances load new config first; validate, then roll out. Apollo supports gradual release.

Example

Example 1: Basic model

Plain text
Namespace / Profile (environment)
  → DataId / Key (config item)
  → Value (content)
  → Group (optional grouping)

Example 2: Product comparison

Product	Characteristics
Nacos	Good Dubbo/Spring Cloud integration; config + discovery
Apollo	Mature gradual rollout, permissions, audit
Spring Cloud Config	Tight Spring integration; Git as backend
Consul	Config + discovery + K/V; multi-language

Example 3: Usage notes

Sensitive config (passwords, keys): encrypt or use Secrets management.
Refresh scope: Clearly define which config is hot-reloadable and which requires restart; avoid assuming a change is live when it is not.
Fallback: When the config center is down, use local default or cache so the app can start.

Example 4: Spring @RefreshScope

Java
@RefreshScope
@ConfigurationProperties("app")
public class AppConfig { }

Bean is recreated when config is refreshed so new values are picked up.

Core Mechanism / Behavior

Pull: Client periodically fetches config. Simple; may have delay.
Push: Server pushes on change. Lower delay; requires long-poll or WebSocket.
Cache: Client caches locally; uses cache when center is unavailable for a limited time.

Key Rules

Config center must be highly available; multi-node, local cache, fallback.
Sensitive data encrypted or in Vault/Secrets; strict production permissions.
Changes need audit and gradual rollout; validate large changes with small traffic first.

What's Next

See Spring Boot Config Priority for config load order. See Service Discovery for Nacos and similar combined solutions.