Which Config Center Should You Choose? Apollo, Nacos, Spring Cloud Config Compared

Config Center Basics

Why Use a Config Center?

Real‑time configuration : Traditional static configs require redeployment; a config center balances real‑time updates with performance.

Management features : Permission control, gray release, versioning, validation, and security are integral.

Distributed scenarios : As services multiply, a centralized config hub simplifies deployment and maintenance.

Supported Functions

Gray release : Deploy changes to a subset of instances before full rollout.

Permission management : Fine‑grained access control and audit logs prevent accidental changes.

Versioning & rollback : Restore previous configurations when needed.

Format validation : Ensure JSON, YAML, Properties, etc., are syntactically correct.

Listening & query : Identify which instances use a given config.

Multi‑environment & multi‑cluster : Isolate configs per environment or cluster.

Common Config Centers

Preface

While Zookeeper and ETCD can store configuration data, they lack UI tools, permission controls, and gray‑release capabilities, making dedicated config centers preferable.

The four main centers covered are Apollo, Disconf, Spring Cloud Config, and Nacos .

Apollo

GitHub: https://github.com/apolloconfig/apollo

Apollo, developed by Ctrip, offers a full‑stack open‑source config management platform with robust permission and workflow features.

Apollo Architecture

The simplified architecture includes four core modules:

ConfigService : Provides config retrieval and push interfaces for clients.

AdminService : Handles config management and publishing for the portal.

Client : Retrieves configs, maintains a long‑living connection, and uses MetaServer for service discovery.

Portal : UI for managing configs, accessing AdminService via soft‑load‑balancing.

Interaction flow:

ConfigService serves client config requests.

Clients keep a long connection, using a push‑pull model for real‑time updates.

AdminService manages config changes via the portal.

ConfigService and AdminService share a ConfigDB per environment.

Portal uses a separate PortalDB for metadata and permissions.

When combined with service discovery (e.g., Eureka), the full Apollo stack integrates seamlessly.

Apollo Features

Unified management of multiple environments, clusters, and namespaces.

Hot‑publish: changes take effect within ~1 second.

Versioned releases with gray‑release support.

Permission control, audit logs, and release approval.

Client usage monitoring.

Native Java and .NET clients, plus HTTP API for other languages.

Open platform API for custom extensions.

Disconf

GitHub: https://github.com/knightliao/disconf

Disconf, open‑sourced by Baidu in 2014, uses Zookeeper for distributed config storage but is no longer actively maintained.

Disconf Architecture

Disconf provides a web UI (disconf‑web) and a client that watches Zookeeper nodes for real‑time updates.

Disconf Characteristics

Distributed config management for key‑value pairs and files.

Unified publishing and automatic client updates.

Supports heterogeneous system deployments with a single package.

Annotation‑driven, minimal‑code integration (requires Spring).

Web UI for viewing config usage.

Spring Cloud Config

GitHub: https://github.com/spring-cloud/spring-cloud-config

Spring Cloud Config, released in 2014, integrates tightly with the Spring ecosystem.

How It Works

Configuration is stored in a repository (Git, SVN, JDBC, or local files). A Config Server pulls the data, serves it via REST, and clients fetch configs using {application}/{profile}/{label}. Dynamic refresh is possible via Spring Cloud Bus.

Key Features

Server‑client model with centralized config.

Supports distributed environments.

Seamless Spring integration.

Language‑agnostic via HTTP API.

Version control via Git.

Nacos

Nacos official site: https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos, an Alibaba open‑source project, provides service discovery, health monitoring, and dynamic configuration.

Main Features

DNS‑based and RPC‑based service discovery with health checks.

Dynamic configuration with versioning, canary releases, and rollback.

Multi‑environment isolation via namespaces.

Supports multiple languages (Java, Go, Python, Node.js, PHP) via open APIs.

Config Center Comparison & Selection

Comparison Table

(Image omitted for brevity)

Gray Release : Apollo supports UI‑driven gray release; Spring Cloud Config relies on manual bus refresh; Nacos 0.9 lacks gray release.

Permission Management : Spring Cloud Config uses Git permissions; Apollo uses project‑level roles; Nacos currently lacks fine‑grained permissions.

Versioning & Rollback : All three support it; Spring Cloud Config leverages Git.

Format Validation : Apollo and Nacos validate formats; Spring Cloud Config does not.

Listening & Query : All provide instance‑config mapping; Nacos offers the simplest UI.

Multi‑Environment : Spring Cloud Config uses profiles; Apollo uses environment tags; Nacos uses namespaces.

Multi‑Cluster : All can be deployed in multiple clusters with varying isolation methods.

Real‑time Push : Nacos and Apollo use HTTP long‑polling; Spring Cloud Config needs WebHook + Bus.

Language Support : Spring Cloud Config is Java‑centric; Apollo and Nacos support many languages.

Performance : Nacos shows the highest read/write throughput, followed by Apollo; Spring Cloud Config is limited by Git.

Selection Guidance

Apollo and Nacos offer broader ecosystem support than Spring Cloud Config.

Apollo provides richer config management features but is more complex to containerize.

Nacos has ready‑made Docker images and follows the KISS principle.

For high‑performance, large‑scale scenarios, Nacos is often the better fit.

Beyond technical features, consider community activity, documentation quality, and long‑term maintenance when choosing a config center.