What Is Nacos? Exploring Service Discovery and Distributed Configuration

Welcome to the first part of a series introducing Nacos, its concepts, and its role in service discovery and distributed configuration.

1. Introduction to Nacos

Nacos official website is https://nacos.io

The homepage highlights Nacos's two core functions: service discovery and configuration management.

Service discovery

Configuration management

Thus Nacos can serve as a service registry and a configuration center.

Pronunciation of Nacos is /nɑ:kəʊs/. The name is an acronym of Na me and Co nfig S ervice.

Na me and Co nfig S ervice

Nacos is open‑source from Alibaba and is part of the Spring Cloud Alibaba project, which provides several foundational components for microservice development.

Spring Cloud Alibaba can be compared to the well‑known Spring Cloud Netflix stack and includes the following main technologies:

Sentinel – provides flow control, service degradation, and circuit‑breaker capabilities.

Nacos – handles service registration, discovery, and distributed configuration.

RocketMQ – enables event‑driven messaging and integrates with Spring Cloud Stream.

Seata – implements distributed transactions.

Dubbo RPC – uses RPC for service calls.

Now it is clear that Nacos, as an Alibaba open‑source component under Spring Cloud Alibaba, can act as both a service registry and a distributed configuration center.

2. Overview of Service Discovery

In distributed systems, multiple independent services need to call each other, requiring knowledge of the target service instance's IP, port, and API.

While API details are documented, IPs and ports are dynamic and change with each deployment.

Discovering the target service instance is the purpose of a service discovery mechanism.

When the number of service instances is small, each instance can maintain its own address list, e.g., via configuration files, but this becomes impractical as the number grows.

At scale, a dedicated service registry is needed.

Each service instance registers its address with the registry upon startup, similar to a phone directory.

If an instance stops, it deregisters itself; if it crashes, the registry must clean up stale entries.

The registry uses a heartbeat mechanism: instances periodically send heartbeat requests to indicate they are alive; missing heartbeats trigger cleanup.

When a service wants to call another, it queries the registry for the target service name to obtain a list of instance addresses and selects one for the call.

This describes how a service registry enables service discovery.

3. Overview of Distributed Configuration

Each service typically has its own configuration file (e.g., Spring Boot properties). When multiple instances of a service run, each holds a copy of this file.

Changing a configuration value traditionally requires editing the file and redeploying all instances, which is inefficient.

By extracting configuration into a third‑party configuration center, service instances can fetch their configuration at runtime, and updates become instantly effective across all instances without redeployment.

Distributed configuration offers two major benefits:

Ease of maintenance – centralized management is superior to scattered per‑service files.

Dynamic updates – configuration changes take effect immediately without redeploying services.

Additionally, Nacos provides version management for configurations, enabling easy rollback to previous versions.