Cloud Native 35 min read

Comprehensive Guide to Nacos Configuration Center and Service Registry Integration with Spring Boot

This article provides an in-depth comparison of Nacos with other configuration and registration centers, explains its architecture and design principles, and offers detailed step-by-step instructions for deploying Nacos in standalone and cluster modes, integrating it with Spring Boot for both configuration and service discovery, including code snippets and operational tips.

Top Architect
Top Architect
Top Architect
Comprehensive Guide to Nacos Configuration Center and Service Registry Integration with Spring Boot

Introduction

The author, a senior architect, evaluates popular configuration and registration centers and finds Nacos most suitable for private‑cloud deployments. The article introduces Nacos, compares it with Apollo, Eureka, and Consul, and outlines the plan to explore its source code in later posts.

1. Comparison with Other Products

1.1 Configuration Center Comparison

Feature

Apollo

Nacos

High Availability

Based on Eureka

Based on Raft, no extra middleware

Multi‑environment

Project‑level granularity

Environment‑level granularity

Config Hot‑Update

Second‑level

Second‑level

Version Management

Automatic

Automatic

Config Rollback

Supported

Supported

Config Inheritance

Supported

Not supported

Gray Release

Supported

Supported

Config Validation

Supported

Supported

Audit

Detailed audit logs

Basic audit logs

Permission Management

Project‑level, no read/write granularity

Environment‑level, supports read/write granularity

Supported Languages

Go, C++, Python, Java, .NET, OpenAPI

Python, Java, Nodejs, Go, OpenAPI

Minimum Cluster Size

8 nodes

4 nodes

Communication Protocol

HTTP

HTTP, gRPC

1.2 Registration Center Comparison

Feature

Nacos

Eureka

Consul

Dependency

None

Zookeeper

None

CAP Model

AP+CP

AP

CP

Scalability

Raft‑based, high performance

Broadcast sync, pressure >1000 nodes

Raft

Health Check

TPC/HTTP/SQL/Client Beat

Client Beat

TCP/HTTP/gRPC/CMD

Load Balancing

Weight/MetaData/Selector

Ribbon

Fabio

Cross‑Center Sync

Supported

Not supported

Supported

Version Upgrade

Normal

Stopped

Normal

Integration

SpringCloud/K8S

SpringCloud

SpringCloud/K8S

Protocol

HTTP/DNS/gRPC

HTTP

HTTP/DNS

Avalanche Protection

Supported

Supported

Not supported

Conclusion: Nacos offers both configuration and registration capabilities, reducing operational cost compared with using separate products.

2. Nacos Principles

2.1 System Architecture

The architecture consists of four layers: User Layer (OpenAPI, Console, SDK, Agent, CLI), Business Layer (service management, config management, metadata management), Kernel Layer (plugins, events, logging, callbacks, consistency protocol, storage), and Plugin Layer (NameService, CMDB, Metrics, Trace, access management, etc.).

2.2 Configuration Center Design

Key domain models include Namespace (tenant‑level isolation), Group (default DEFAULT_GROUP), and Data ID (unique config identifier). A typical usage scenario is illustrated with a diagram.

2.3 Data Consistency

Nacos adopts an AP consistency protocol for the configuration center. Server‑to‑Server consistency is ensured via DB persistence or Raft when no DB is used. Clients verify data via MD5 and long‑polling.

2.4 Disaster Recovery

Clients keep local snapshots of configurations; when the server is unreachable, the snapshot provides read‑only fallback.

2.5 Load Balancing

Although load balancing is not a core function of the registry, Nacos provides client‑side strategies based on health, weight, and metadata.

3. Nacos Installation

3.1 Standalone Mode

Run Nacos with an embedded database using Docker:

#!/bin/bash
# Reference: https://github.com/nacos-group/nacos-docker
# Access UI at http://127.0.0.1:8848 (user/password: nacos/nacos)
# 8848 is the service port, 9848/9849 are gRPC ports
# Example environment variables:
# SERVER_SERVLET_CONTEXTPATH=nacos
# NACOS_APPLICATION_PORT=8848
# NACOS_AUTH_ENABLE=false
# SPRING_DATASOURCE_PLATFORM=mysql
# ... (other JVM and MySQL parameters)

Docker command:

docker run -d \
  --name some-nacos \
  -e MODE=standalone \
  -p 8848:8848 \
  -p 9848:9848 \
  -p 9849:9849 \
  nacos/nacos-server:2.0.3

3.2 MySQL Backend

#!/bin/bash
docker run -d \
  --name some-nacos-mysql \
  --net common-network \
  -e MODE=standalone \
  -p 8848:8848 \
  -p 9848:9848 \
  -p 9849:9849 \
  -e SPRING_DATASOURCE_PLATFORM=mysql \
  -e MYSQL_SERVICE_HOST=some-mysql \
  -e MYSQL_SERVICE_PORT=3306 \
  -e MYSQL_SERVICE_DB_NAME=nacos \
  -e MYSQL_SERVICE_USER=nacos \
  -e MYSQL_SERVICE_PASSWORD=nacos \
  nacos/nacos-server:2.0.3

3.3 Cluster Mode

Prepare the SQL script in nacos-2.0.3/distribution/conf :

source nacos-mysql.sql

Start three nodes (ports 8841‑8843) with Docker:

#!/bin/bash
# Node 8841
docker run -d \
  --name some-nacos-8841 \
  --net common-network \
  -h some-nacos-8841 \
  -e MODE=cluster \
  -e PREFER_HOST_MODE=hostname \
  -e "NACOS_SERVERS=some-nacos-8841:8841 some-nacos-8842:8842 some-nacos-8843:8843" \
  -e NACOS_APPLICATION_PORT=8841 \
  -p 8841:8841 \
  -e SPRING_DATASOURCE_PLATFORM=mysql \
  -e MYSQL_SERVICE_HOST=some-mysql \
  -e MYSQL_SERVICE_PORT=3306 \
  -e MYSQL_SERVICE_DB_NAME=nacos \
  -e MYSQL_SERVICE_USER=nacos \
  -e MYSQL_SERVICE_PASSWORD=nacos \
  -e JVM_XMS=512m -e JVM_XMX=512m \
  -v /Users/ginger/nacos/logs/8841:/home/nacos/logs \
  nacos/nacos-server:2.0.3

Repeat similarly for 8842 and 8843, adjusting ports and volume paths.

3.4 Nginx Proxy

location / {
  proxy_pass http://nacos-server;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header REMOTE-HOST $remote_addr;
  add_header X-Cache $upstream_cache_status;
  add_header Cache-Control no-cache;
}
upstream nacos-server {
  server some-nacos-8841:8841 weight=1 max_fails=2 fail_timeout=10s;
  server some-nacos-8842:8842 weight=1 max_fails=2 fail_timeout=10s;
  server some-nacos-8843:8843 weight=1 max_fails=2 fail_timeout=10s;
}

4. Integration with Spring Boot – Configuration Center

4.1 Maven Dependency

<dependency>
  <groupId>com.alibaba.boot</groupId>
  <artifactId>nacos-config-spring-boot-starter</artifactId>
  <version>0.2.10</version>
</dependency>

4.2 Application Properties

# Service profile
spring.profiles.active=dev
spring.application.name=easy-console
server.port=8096
server.servlet.context-path=/console

# Nacos config
nacos.config.server-addr=172.17.0.26:8848
nacos.config.bootstrap.enable=true
nacos.config.namespace=dev
nacos.config.group=DEFAULT_GROUP
nacos.config.data-id=${spring.application.name}-${spring.profiles.active}.${nacos.config.type}
nacos.config.type=properties
nacos.config.auto-refresh=true
nacos.config.remote-first=false
nacos.config.max-retry=3
nacos.config.config-retry-time=2000
nacos.config.config-long-poll-timeout=30000
nacos.config.enable-remote-sync-config=false

Enable nacos.config.bootstrap.enable so that remote configuration loads before the application starts.

4.3 Logging and Snapshot

Client logs are stored under /${JM.LOG.PATH}/logs/nacos (default user home). Snapshots are stored under /${JM.SNAPSHOT.PATH}/nacos/config . Adjust JM.LOG.PATH , JM.SNAPSHOT.PATH , JM.LOG.RETAIN.COUNT , and JM.LOG.FILE.SIZE via JVM arguments if needed.

5. Integration with Spring Boot – Service Registry

5.1 Maven Dependency

<dependency>
  <groupId>com.alibaba.boot</groupId>
  <artifactId>nacos-discovery-spring-boot-starter</artifactId>
  <version>0.2.10</version>
</dependency>

5.2 Provider Configuration

# Application properties (provider)
spring.profiles.active=dev
spring.application.name=easy-console
server.port=8096
server.servlet.context-path=/console

# Nacos discovery
nacos.discovery.server-addr=172.17.0.26:8848
nacos.discovery.auto-register=true
nacos.discovery.register.group-name=DEFAULT_GROUP
nacos.discovery.namespace=${spring.profiles.active}

Startup logs show successful registration, e.g., Finished auto register service : easy-console, ip : 10.242.44.123, port : 8096 .

5.3 Consumer Configuration

# Application properties (consumer)
spring.profiles.active=dev
spring.application.name=nacos-client
server.port=8090

# Nacos discovery (no auto‑register)
nacos.discovery.server-addr=172.17.0.26:8848
nacos.discovery.auto-register=false
nacos.discovery.register.group-name=DEFAULT_GROUP
nacos.discovery.namespace=${spring.profiles.active}

Inject the naming service:

@NacosInjected
private NamingService namingService;

Fetch all instances of a service:

List<Instance> instances = namingService.getAllInstances("easy-console");

Example health‑check task that selects a healthy instance and calls its health endpoint:

@Slf4j
@Component
public class HealthCheckTiming {

    @NacosInjected
    private NamingService namingService;

    @Scheduled(cron = "0/5 * * * * ?")
    public void checkHealth() {
        try {
            Instance instance = namingService.selectOneHealthyInstance("easy-console", true);
            String url = "http://" + instance.getIp() + ":" + instance.getPort() + "/console/api/system/status";
            String rsp = HttpUtil.getMethod(url);
            log.info("check health, success, rsp={}", rsp);
        } catch (IllegalStateException e) {
            log.info("check health, failed, {}", e.getMessage());
        } catch (Exception e) {
            log.error("check health, failed", e);
        }
    }
}

If no provider is available, Nacos throws IllegalStateException: no host to srv for serviceInfo: easy-console , which should be caught as shown.

5.4 Application Name in Nacos UI

Nacos determines the consumer’s application name from the system property project.name . If not set, it falls back to the container name or unknown . Set -Dproject.name=nacos-client to display a meaningful name.

5.5 Provider Lifecycle Demo

The UI shows the provider coming online, going offline (client logs “no host to srv…”), and coming back online, demonstrating real‑time service discovery.

References

Nacos official documentation: https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos design whitepaper: https://www.yuque.com/nacos/ebook/iez8a4

Ctrip Apollo configuration center architecture analysis

dockerMicroservicesNacosSpring BootService RegistryConfiguration Center
Top Architect
Written by

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.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.