Understanding Nacos Architecture and Service Registration in Spring Cloud

The article introduces the Nacos architecture, describing its main components: Provider APP (service provider), Consumer APP (service consumer), Name Server (high‑availability routing via VIP or DNS), Nacos Server (exposes Open API, Config Service, Naming Service, and uses Raft for consistency), and Nacos Console.

It then outlines the basic registration principle: service instances register with the registry on startup and deregister on shutdown, consumers query the registry for available instances, and the registry performs health checks via a heartbeat API.

In Spring Cloud, the registration process is driven by the

org.springframework.cloud.client.serviceregistry.ServiceRegistry

interface. The implementation NacoServiceRegistry is auto‑configured via META-INF/spring.factories, which includes AutoServiceRegistrationAutoConfiguration. This configuration creates an AutoServiceRegistration bean, whose concrete class NacosAutoServiceRegistration extends AbstractAutoServiceRegistration. The registration is triggered by the WebServerInitializedEvent, invoking bind(event) and ultimately calling NacosServiceRegistry.register().

The NacosServiceRegistry implementation uses the Nacos client SDK’s namingService.registerInstance to register services. It creates heartbeat information via beatReactor.addBeatInfo() and registers the service through serverProxy.registerService(). The heartbeat mechanism periodically sends packets from the client to the server; missing responses mark the instance as unhealthy.

Service registration can be performed via two equivalent methods: Open API (HTTP request) and SDK (direct client calls). Both ultimately send an HTTP request to /nacos/v1/ns/instance, which is handled by the InstanceController on the server side. The controller extracts serviceName and namespaceId, creates or retrieves a Service object stored in a ConcurrentHashMap, adds the instance, and initiates heartbeat and consistency protocols.

For service provider address queries, the InstanceController.list method parses request parameters, retrieves the corresponding Service, extracts provider instances, and returns a JSON response.

Dynamic service address discovery is achieved through the HostReactor class. After a client subscribes, an UpdateTask thread periodically pulls the latest address list from the server. The server pushes updates when a provider’s heartbeat fails, and the client processes the JSON payload to refresh its local cache.

In summary, Nacos clients register services via Open API or SDK, the server builds a service object, maintains heartbeat checks, synchronizes data using a consistency protocol, and provides mechanisms for both static queries and dynamic updates of service addresses.