Nacos: Services and Configuration in the Cloud-Native Era

by

Introduction: The Challenges of Microservice Architecture and the Birth of Nacos

Driven by cloud computing and containerization technologies, microservice architecture has become the mainstream paradigm for modern application development. However, with the exponential growth in the number of services, traditional service governance models face three core challenges: inefficient service discovery mechanisms, lack of a unified platform for configuration management, and limited service health monitoring methods. Alibaba open-sourced Nacos (Naming and Configuration Service) in 2018 precisely to address these pain points. As a key component of cloud-native infrastructure, Nacos builds a “nervous system” connecting the microservice ecosystem through its three core capabilities: service discovery, configuration management, and dynamic DNS.

Part 1: Nacos Core Architecture Design

1.1 Modular Layered Architecture

Nacos employs a four-layer architecture design to achieve high cohesion and low coupling:

  • Access layer : Handles client requests through a load balancer and supports the HTTP/2 protocol to improve transmission efficiency.
  • Service layer : includes three core modules: registration center, configuration center, and metadata management.
  • Persistence layer : Supports relational databases such as MySQL and PostgreSQL, as well as embedded Derby databases.
  • Caching layer : Employs a multi-level caching mechanism, combining local caching with distributed Redis caching, to ensure high-concurrency access performance.

1.2 Innovation in Consistency Protocols

Nacos creatively proposed a dynamic switching mechanism for AP/CP modes:

  • Temporary instance scenario : Using AP mode (eventual consistency), service availability is prioritized through health checks.
  • Persistent instance scenario : Switch to CP mode (strong consistency) to ensure the absolute accuracy of configuration data.
  • Metadata synchronization : Cross-node data synchronization is achieved based on the Raft protocol, ensuring cluster state consistency.

1.3 Health Check Mechanism

  • Client-initiated reporting : Service instances report their status to the Nacos Server via heartbeat packets (default 5-second intervals).
  • Server-side proactive probing : Performs health checks on TCP/HTTP interfaces, supporting custom probe paths.
  • Anomaly handling mechanism : Three consecutive failed checks trigger service degradation, automatically removing the abnormal instance from the service list.

Part Two: In-depth Practices in Service Discovery and Governance

2.1 Full Process Analysis of Service Registration

  1. Service launch phase :
    • The client loads the Nacos SDK and initializes service instance information (IP, port, metadata, etc.).
    • Establish a persistent connection with the Nacos Server and start a heartbeat thread.
    • Upon initial registration, Nacos Server assigns a unique service ID (format: ${service name}-${cluster name}-${instance ID}).
  2. Service operation phase :
    • The client sends a heartbeat packet every 5 seconds and updates the last active timestamp.
    • The server maintains a list of service instances and automatically cleans up instances that have not been updated for 30 seconds.
    • Supports weight configuration (0-100) to achieve proportional traffic allocation.
  3. Service offline phase :
    • When a client actively calls the logout interface, the Nacos Server immediately updates the service status.
    • Graceful shutdown mechanism: Instance information is retained for 15 seconds to allow new requests to complete processing.

2.2 Advanced Features of Service Discovery

  • Environment isolation : Achieve isolation between multiple environments (development/testing/production) through namespaces.
  • Cluster routing : Supports traffic management strategies such as weight-based blue-green deployment and canary deployment.
  • Metadata extension : Custom tags (such as version number, region information) support fine-grained routing.
  • DNS discovery : Resolves service names to domain names, compatible with traditional DNS lookup methods.

2.3 Best Practices for Service Governance

  1. Circuit breaking and degradation : Integrates Hystrix/Sentinel to automatically break circuits based on service health status.
  2. Traffic control : Implement A/B testing through weight adjustment, gradually switching traffic.
  3. Service Mesh Integration : Working with Istio/Linkerd to achieve transparent traffic hijacking
  4. Multi-language support : Provides SDKs for mainstream languages ​​such as Java, Go, and Python.

III: Technical Implementation of Configuration Management

3.1 Configure publish and subscribe mechanism

  1. Configure and release process :
    • The client submits configuration change requests via the RESTful API.
    • Nacos Server performs validity checks (such as JSON format validation).
    • Configure the database to persist the settings and trigger version number increment.
    • Push the change notification to all clients that have subscribed to this configuration.
  2. Configuring subscription implementation :
    • The client establishes a long-lived connection and listens for configuration change events.
    • An incremental update mechanism is used, transmitting only the changed parts.
    • Supports local caching configuration, allowing the old configuration to be used even when the network is disconnected.

3.2 Configure version control and rollback

  • Version chain management : Each configuration change generates a unique version number, supporting historical version lookup.
  • Canary release : Controlling the scope of configuration effectiveness through environment variables to gradually expand the release.
  • Rollback mechanism : One-click rollback to a specified version, automatically fixing abnormal configurations.

3.3 Configure security policies

  • Access control : Role-based access control (RBAC) with support for read/write permission separation.
  • Data encryption : Supports AES-256 encrypted storage of sensitive configurations.
  • Audit logs : Record all configuration change operations to meet compliance requirements.

Part 4: High Availability and Performance Optimization of Nacos

4.1 Cluster Deployment Architecture

  • Master-slave mode : Single-node deployment, suitable for testing environments.
  • Cluster mode : Deployed with a minimum of 3 nodes, using the Raft protocol to ensure data consistency.
  • Multiple data centers : Achieving cross-regional disaster recovery through synchronous replication.

4.2 Performance Tuning Practices

  1. JVM parameter optimization :
    • Heap memory settings: Adjust -Xms and -Xmx according to the amount of data (4GB is recommended as a minimum).
    • GC strategy: Use the G1 garbage collector and set a maximum pause time target.
  2. Database optimization :
    • Index optimization: Create composite indexes for frequently queried fields such as service name and cluster name.
    • Table partitioning strategy: Partition tables by namespace, keeping the data volume of a single table below one million records.
  3. Network optimization :
    • Client connection pool: Set a reasonable maximum number of connections (50-100 recommended).
    • Heart rate interval: Adjusted based on network conditions (default 5 seconds, can be shortened to 3 seconds).

4.3 Monitoring and Alarm System

  • Key performance indicator monitoring :
    • Service registration success rate
    • Configuration change delay
    • Client connection count
    • Database query time
  • Alarm threshold settings :
    • An alarm is triggered when the service registration failure rate exceeds 5%.
    • An alarm will be triggered if the configuration change is delayed by more than 1 second.
    • Client connection count exceeding threshold triggers capacity expansion recommendation

5. Ecological Integration and Expansion of Nacos

5.1 Deep Integration with Spring Cloud

  1. Service discovery integration :
    • Automatic registration is achieved using spring-cloud-starter-alibaba-nacos-discovery.
    • Support for RestTemplate annotated with @LoadBalanced to implement client-side load balancing
  2. Configuration management integration :
    • Dynamic configuration is achieved using spring-cloud-starter-alibaba-nacos-config.
    • Supports multi-environment configuration in bootstrap.yml (spring.profiles.active)
  3. Integrated health check :
    • In conjunction with Actuator, it provides /health endpoint monitoring service status.
    • Supports custom health check rules

5.2 Integration with Kubernetes

  1. Service discovery and integration :
    • Automatic service registration via Nacos-K8s Operator
    • Support DNS resolution for Kubernetes Services
  2. Configuration management integration :
    • Map ConfigMap to Nacos configuration
    • Supports automatic encrypted storage of Secrets

5.3 Custom Extension Development

  1. SPI extension mechanism :
    • Implement Nacos’s SPI interface and extend authentication methods.
    • Supports custom health check logic
  2. Plugin Development :
    • Develop and configure encryption plugins, integrating national cryptographic algorithms.
    • Create a service governance plugin to implement custom routing rules.

VI: Challenges and Solutions in the Production Environment

6.1 Performance bottlenecks of large-scale clusters

  • Problem : Service discovery latency increases when dealing with tens of thousands of service instances.
  • Solution :
    • A sharding strategy is adopted to divide data storage by namespace.
    • Introduce local caching to reduce database queries
    • Optimize Raft log replication mechanism to improve election efficiency

6.2 The Avalanche Effect of Configuration Changes

  • Problem : Frequent configuration changes cause frequent client restarts.
  • Solution :
    • Implement batch processing of configuration changes and merge multiple changes.
    • Add a change frequency limit to prevent malicious attacks.
    • Canary releases that support configuration changes

6.3 Compatibility issues of multilingual clients

  • Problem : Inconsistent behavior due to differences in SDK implementations across different languages.
  • Solution :
    • Establish a unified client API specification.
    • Build a cross-language test suite
    • Provide compatibility checking tools

7. Future Evolution Direction

7.1 Deep Integration of Service Mesh

  • Deep integration with Istio enables transparent traffic management.
  • Supports mTLS mutual authentication to enhance the security of inter-service communication.

7.2 Intelligent governance capabilities

  • Traffic prediction based on machine learning, with automatic weight adjustment.
  • Anomaly detection and self-healing capabilities enable automatic fault recovery.

7.3 Edge Computing Support

  • A lightweight version of Nacos Edge, adapted for edge node deployment.
  • Supports offline mode, maintaining basic functionality when the network is interrupted.

Conclusion: The ecological value of Nacos

As a “service connector” for the cloud-native era, Nacos not only solves the core pain points of microservice architecture, but also builds a bridge connecting the entire process of development, testing, and operation through its open design philosophy and powerful scalability. In the open-source community, Nacos has grown into an infrastructure supporting millions of services, and its design philosophy and technical implementation provide important references for building elastic and reliable cloud-native applications.