Understanding Nacos 1.x and 2.x Architectures: Evolution, Issues, and Improvements

Nacos 1.x Architecture

Nacos 1.x is organized into five layers:

Access Layer : Nacos clients, Dubbo/SCA integrations, and the Console UI. All interactions use HTTP OpenAPI.

Communication Layer : Short‑lived HTTP connections; some push notifications use UDP.

Function Layer : Provides service discovery and configuration management.

Sync Layer : Supports AP‑mode Distro, CP‑mode Raft, and a simple Notify mechanism for MySQL‑backed configurations.

Persistence Layer : Persists data in MySQL, Derby, or the local file system.

Service Model in 1.x

Clients register services via OpenAPI. The server validates the request, creates or updates a Service object identified by namespace + group + serviceName, and stores instance information. Two events are triggered:

Data synchronization (using Distro or Raft) to other Nacos nodes.

Subscriber notification via UDP.

Persistent services are synchronized with Raft to guarantee durability.

Key Problems in 1.x

High TPS caused by frequent heartbeats and ineffective queries.

Long latency in detecting service changes (default 15 s heartbeat timeout).

Unreliable UDP pushes lead to periodic reconciliation queries.

Large number of TIME_WAIT connections from short‑lived HTTP requests.

Configuration module uses 30 s long‑polling, causing frequent GC.

Nacos 2.x Architecture

Nacos 2.x builds on the 1.x layers but replaces the short‑lived HTTP communication with persistent RPC connections (gRPC and Rsocket). A new Link Layer normalizes different request types and will host future load‑balancing and flow‑control features. Other layers remain largely unchanged.

New Service Model

All client requests share a single RPC connection, introducing a stateful Client object that aggregates the services and subscriptions associated with that connection. Service registration updates the Client, triggers index updates, and pushes changes to subscribed clients over the same persistent link. Metadata (labels, instance status, weight) is separated from core service definitions, allowing dynamic updates without altering immutable service data.

Advantages of 2.x

Reduced heartbeat traffic; only keep‑alive messages are needed.

Faster detection of broken TCP connections.

Reliable streaming push over long connections, lowering invalid QPS.

Elimination of TIME_WAIT issues.

Real long‑connection avoids frequent GC in the config module.

Finer‑grained synchronization reduces inter‑node communication load.

Disadvantages of 2.x

Increased internal complexity for connection management and load balancing.

Stateful data tied to connections lengthens processing pipelines.

Observability of RPC (gRPC) is less straightforward than plain HTTP.

Future Roadmap for Nacos 2.x

Planned improvements include richer documentation, higher code quality with extensive testing, open‑source benchmarks, and a move toward a plugin‑based architecture to address current shortcomings such as load balancing and observability.