How Nacos Powers Service Registration and Dynamic Discovery in Spring Cloud

Nacos Architecture

Components include:

Provider APP: service provider

Consumer APP: service consumer

Name Server: provides high‑availability routing via VIP or DNS

Nacos Server: hosts Open API, Config Service, Naming Service, and a Consistency Protocol based on the Raft algorithm

Nacos Console: management UI

Principles of Service Registry

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

Consumers query the registry to obtain available instances.

The registry performs health checks via the instance's health‑check API.

When Spring Cloud Performs Registration

Spring‑Cloud‑Common defines the interface

org.springframework.cloud.client.serviceregistry.ServiceRegistry

as the standard for service registration; implementations integrate with Spring Cloud.

The concrete implementation used is NacosServiceRegistry.

Spring Cloud integration with Nacos process:

The spring-cloud-commons module contains META-INF/spring.factories with auto‑configuration entries.

The class AutoServiceRegistrationAutoConfiguration configures service registration.

Within this configuration an AutoServiceRegistration bean is injected; it extends AbstractAutoServiceRegistration, and NacosAutoServiceRegistration further extends that abstract class.

The registration is triggered by Spring's event mechanism: AbstractAutoServiceRegistration implements onApplicationEvent, listens to WebServerInitializedEvent, and calls this.bind(event).

Finally, NacosServiceRegistry.register() registers the service.

Implementation of NacosServiceRegistry

In NacosServiceRegistry.register() the Nacos client SDK method namingService.registerInstance is invoked to register the service.

Heartbeat mechanism details: beatReactor.addBeatInfo() creates heartbeat information for health detection. serverProxy.registerService() performs the actual registration.

Both Open API and SDK ultimately send an HTTP request to nacos/v1/ns/instance on the server.

On the server side, InstanceController processes the request, extracts serviceName and namespaceId, creates or retrieves a Service object stored in a ConcurrentHashMap, adds the instance, and sets up heartbeat and consistency listening.

Service initialization schedules a task that periodically checks the last heartbeat timestamp of each instance; if a timeout occurs, the instance is marked unhealthy and a change event is emitted.

Provider Address Query

Both Open API and SDK can query provider addresses. The list method of InstanceController parses request parameters, obtains the corresponding Service instance, retrieves all provider instances, assembles a JSON response, and returns it.

Dynamic Service Address Sensing

Clients can subscribe to service updates via subscribe or use selectInstance with subscription enabled. The client’s HostReactor runs an UpdateTask thread that pulls the latest address list from the server every 10 seconds.

The server maintains heartbeat checks with service providers; when a provider fails, the server pushes an update to consumers.

Consumers process the received JSON via HostReactor.processServiceJSON and update their local address list.