Understanding Nacos Architecture and Service Registration in Spring Cloud

The article introduces Nacos as a service registry, 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 on startup and deregister on shutdown, consumers query the registry for available instances, and the registry performs health checks via a heartbeat API.

Integration with Spring Cloud is explained through the org.springframework.cloud.client.serviceregistry.ServiceRegistry interface. The concrete implementation NacosServiceRegistry registers services by invoking namingService.registerInstance from the Nacos client SDK.

The article details the auto‑configuration process: AutoServiceRegistrationAutoConfiguration injects an AutoServiceRegistration bean, whose subclass NacosAutoServiceRegistration extends AbstractAutoServiceRegistration . This bean listens to WebServerInitializedEvent and triggers registration via bind(event) .

Heartbeat mechanism is described as a scheduled task that periodically sends packets from the client to the server; missing responses mark the instance as unhealthy, prompting the server to update service status.

Two registration approaches are covered: Open API (HTTP request) and SDK (client library). Both ultimately send an HTTP request to /nacos/v1/ns/instance , where the server’s InstanceController processes the request, creates or retrieves a Service object, adds the instance, and starts heartbeat monitoring.

Dynamic service address discovery is achieved via the HostReactor class, which runs an UpdateTask thread to pull the latest address list every 10 seconds and processes push notifications from the server to keep the local cache up‑to‑date.

Finally, the article provides a concise summary: Nacos client registers services via Open API or SDK, the server stores service metadata in a concurrent map, establishes heartbeat checks, synchronizes data using a consistency protocol, and supports dynamic discovery through subscription and pull mechanisms.