Understanding Nacos Architecture and Service Registration in Spring Cloud

Nacos consists of several components: Provider APP (service provider), Consumer APP (service consumer), Name Server (high‑availability routing via VIP or DNS), Nacos Server (exposes Config Service and Naming Service, uses a Raft‑based consistency protocol), and the Nacos Console for management.

The service registry works by having each service instance register itself when it starts and deregister on shutdown; consumers query the registry to obtain healthy instances, and the registry performs health‑check API calls to verify availability.

In Spring Cloud, the registration process is driven by the

org.springframework.cloud.client.serviceregistry.ServiceRegistry

interface. Nacos implements this via NacosServiceRegistry. The AutoServiceRegistrationAutoConfiguration creates an AutoServiceRegistration bean whose concrete class AbstractAutoServiceRegistration (extended by NacosAutoServiceRegistration) listens for WebServerInitializedEvent and then invokes the registration logic. NacosServiceRegistry registers services by calling the Nacos client SDK method namingService.registerInstance. Heartbeat information is generated with beatReactor.addBeatInfo(), and the actual registration request is sent via serverProxy.registerService().

The heartbeat mechanism periodically sends packets from the client to the server; if a response is not received within a configured timeout, the instance is marked unhealthy and a service‑change event is emitted.

Service registration can be performed through either the Open API or the SDK, both ultimately issuing an HTTP request to nacos/v1/ns/instance. On the server side, InstanceController processes the request, creates or retrieves a Service object stored in a ConcurrentHashMap, adds the instance, starts the heartbeat, and synchronises data via the consistency protocol.

Querying provider addresses uses the same Open API/SDK endpoints; the InstanceController.list method parses request parameters, retrieves the corresponding Service, extracts instances based on srvIPs, assembles a JSON response, and returns it to the consumer.

Dynamic service discovery relies on the HostReactor. After a client subscribes, an UpdateTask thread pulls the latest address list every 10 seconds, while the server pushes updates when a provider fails. The client processes the JSON payload to refresh its local address cache.