Mastering Nacos Configuration Center: Architecture, Setup, and Advanced Features
This article explains the purpose, requirements, architecture, setup steps, configuration model, client workflow, request protocol, data storage, gray release, and rollback mechanisms of Nacos's configuration center, providing a comprehensive guide for backend developers.
Configuration Center
Business configuration, feature toggles, weak‑dependency degradation, and even database passwords may rely on a dynamic configuration center.
Without a dedicated component, teams resort to hard‑coding, configuration files, databases, or caches, each with drawbacks such as recompilation, restarts, performance limits, or stale data.
From these shortcomings we can derive clear requirements for a configuration center:
Store, retrieve, and listen to configurations (mandatory).
Push changes to listeners promptly (mandatory).
Provide a visual console to view changes (mandatory).
Support gray‑scale execution of changes (nice‑to‑have).
Allow rollback of changes (nice‑to‑have).
Popular solutions include Ctrip’s open‑source Apollo, Spring Cloud Config, Alibaba’s Nacos, and Baidu’s Disconf.
Nacos Configuration Center
Nacosstands for Naming and Configuration Service, focusing on service registration (Naming) and configuration management.
This article explains the architecture and implementation of Nacos’s configuration center based on version 2.0.0 (significantly different from 1.x).
Setting Up Nacos Debug Environment
Clone the source from GitHub (use --depth=1 for a shallow clone).
git clone --depth=1 https://github.com/alibaba/nacos.gitImport the project into an IDE for easier debugging.
Start the server by running Nacos.main() in the console module, which launches all modules.
Use the client to test; the configExample module demonstrates configuration operations. Copy it for custom testing without modifying source code.
Nacos Configuration Model
A configuration is uniquely identified by namespace + group + dataId. namespace: bound to a client, isolates environments or tenants. group: logical grouping for business separation. dataId: the configuration identifier.
Client Startup Process
If the Nacos server address is configured, the client uses it directly; otherwise it retrieves the address from an endpoint, allowing address changes without client restarts (see
https://nacos.io/en-us/blog/namespace-endpoint-best-practices.html).
The first interaction creates a gRPC connection to a randomly selected server; subsequent requests reuse this connection with retries and rate‑limiting. On failure or server‑initiated disconnect, a new server is selected.
Request Model
The gRPC proto defines a unified request/response structure.
message Metadata{
string type = 3;
string clientIp = 8;
map<string, string> headers = 7;
}
message Payload{
Metadata metadata = 2;
google.protobuf.Any body = 3;
}
service Request{
// Sends a commonRequest
rpc request (Payload) returns (Payload){}
} type: request/response class name. clientIp: client IP address. headers: carried header information.
The body in Payload is JSON‑encoded.
All configuration‑center APIs are defined in com.alibaba.nacos.api.config.ConfigService.
Key interfaces include: getConfig: read a configuration. publishConfig: publish a configuration. publishConfigCas: atomic publish with CAS semantics. removeConfig: delete a configuration. addListener: listen for changes. removeListener: remove a listener.
Change Push
Nacos uses a push‑pull hybrid model to ensure timeliness and data consistency.
Data Storage
The configuration data can be stored in an embedded derby database for single‑node testing or in an external mysql database.
The publishConfigCas implementation relies on an SQL update like update ${table} set ${xx}=${zz} where md5=${old_md5}; if the row has changed, the publish fails.
Gray Release and Rollback
When gray release is enabled, only the specified IPs receive the change; others do not, and gray and production releases are kept separate.
Gray releases are recorded, allowing rollback to any previous version.
Conclusion
The article walks through the background, architecture, and key modules of Nacos’s configuration center, providing a comprehensive understanding and setting the stage for future analysis of Nacos’s service‑registration capabilities.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Xiao Lou's Tech Notes
Backend technology sharing, architecture design, performance optimization, source code reading, troubleshooting, and pitfall practices
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
