How Nacos Powers Service Registration and Dynamic Discovery in Spring Cloud

Nacos Architecture

The Nacos ecosystem consists of several key components: Provider APP: the service provider. Consumer APP: the service consumer. Name Server: routes requests in a high‑availability cluster using VIP or DNS. Nacos Server: hosts the Open API, Config Service, Naming Service, and a Raft‑based consistency protocol for data synchronization. Nacos Console: the management UI.

Registration Center Principle

Service instances register with the registry on startup and deregister on shutdown.

Consumers query the registry to obtain available instances.

The registry performs health‑check calls to verify that instances can handle requests.

Spring Cloud Registration Timing

Spring Cloud defines the

org.springframework.cloud.client.serviceregistry.ServiceRegistry

interface as the standard for service registration. The implementation used for Nacos is NacoServiceRegistry, which is auto‑wired via spring.factories in the spring-cloud-commons module.

The auto‑configuration class AutoServiceRegistrationAutoConfiguration creates an AutoServiceRegistration bean, whose concrete subclass NacosAutoServiceRegistration extends AbstractAutoServiceRegistration. This class listens for WebServerInitializedEvent and triggers this.bind(event), ultimately invoking NacosServiceRegistry.register().

Implementation of NacosServiceRegistry

The registry method of NacosServiceRegistry calls namingService.registerInstance from the Nacos client SDK, which sends an HTTP request to the server endpoint nacos/v1/ns/instance. Internally, the client creates heartbeat information via beatReactor.addBeatInfo() and registers the service through serverProxy.registerService().

Heartbeat info is generated to ensure the registered instance remains healthy. serverProxy.registerService() performs the actual registration.

Heartbeat Mechanism

The client schedules periodic heartbeat packets; a dedicated thread monitors the server’s response. If no response is received within the configured timeout, the instance is marked unhealthy and a service‑change event is emitted.

Registration Process Summary

Nacos client sends a registration request via Open API or SDK (both HTTP‑based).

The server creates a Service object stored in a ConcurrentHashMap.

A scheduled task establishes heartbeat checks for all instances.

Data consistency is maintained through the Raft protocol.

Provider Address Query

Both Open API and SDK expose nacos/v1/ns/instance for querying registered instances. The InstanceController.list method parses request parameters, retrieves the corresponding Service from the cache, extracts provider IPs, and returns a JSON payload.

Nacos Service Address Dynamic Perception

Clients can call subscribe(serviceName, EventListener) or selectInstance(..., subscribe=true) to receive real‑time updates. Internally, HostReactor runs an UpdateTask thread that pulls the latest address list every 10 seconds. If a provider fails its heartbeat, the server pushes a notification, which the client processes via processServiceJSON to refresh its local cache.