Understanding Nacos Architecture and Service Registration in Spring Cloud
This article explains the Nacos architecture, the principles of service registration and discovery, and how Spring Cloud integrates with Nacos through auto‑configuration, heartbeat mechanisms, and dynamic address updates, providing a comprehensive guide for building cloud‑native microservices.
Nacos Architecture
Nacos consists of 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 (management UI).
Service Registry Principles
Service instances register themselves on startup and deregister on shutdown.
Consumers query the registry to obtain available instances.
The registry performs health‑check API calls to verify instance liveliness.
When Spring Cloud Registers Services
Spring Cloud defines the interface
org.springframework.cloud.client.serviceregistry.ServiceRegistry. The implementation NacosServiceRegistry integrates Nacos as the registration backend.
Auto‑configuration is declared in spring‑cloud‑commons/META-INF/spring.factories, which loads AutoServiceRegistrationAutoConfiguration. This configuration creates an AutoServiceRegistration bean whose concrete class NacosAutoServiceRegistration extends AbstractAutoServiceRegistration.
The AbstractAutoServiceRegistration listens for WebServerInitializedEvent and invokes this.bind(event), ultimately calling NacosServiceRegistry.register() to register the service.
Implementation of NacosServiceRegistry
The registry method calls namingService.registerInstance from the Nacos client SDK. The registration flow includes creating a Service object, adding it to a ConcurrentHashMap, initializing heartbeat tasks, and listening for data‑consistency events.
Heartbeat is achieved by scheduling periodic packets via beatReactor.addBeatInfo(). If a heartbeat is missed, the instance is marked unhealthy.
Service Provider Address Query
Both Open API and SDK expose endpoints (e.g., nacos/v1/ns/instance) handled by InstanceController. The controller parses request parameters, retrieves the Service from the cache, and returns a JSON list of provider addresses.
Dynamic Service Discovery
Clients can subscribe to service updates using subscribe or enable automatic subscription via selectInstance(..., true). The HostReactor runs an UpdateTask thread that pulls the latest address list every 10 seconds, processes push notifications from the server, and updates the local cache.
Overall, Nacos registers services via Open API or SDK, stores them in a thread‑safe map, maintains heartbeat checks, synchronizes data using a consistency protocol, and provides dynamic discovery to consumers.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
