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.

Xiao Lou's Tech Notes
Xiao Lou's Tech Notes
Xiao Lou's Tech Notes
Mastering Nacos Configuration Center: Architecture, Setup, and Advanced Features

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

Nacos

stands 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.git

Import 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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

microservicesNacosconfiguration centerConfig Management
Xiao Lou's Tech Notes
Written by

Xiao Lou's Tech Notes

Backend technology sharing, architecture design, performance optimization, source code reading, troubleshooting, and pitfall practices

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.