DOCSEARCHbyAlgolia
Submit Docs

Nacos: Dynamic Naming and Configuration Service

repository·develop·Indexed 12 days ago

https://github.com/alibaba/nacos

A dynamic naming and configuration service for service discovery and centralized configuration management in microservices architectures. Nacos provides service health checks, dynamic DNS, and a management dashboard. It includes a Console UI for administration and supports the Mesh Configuration Protocol (MCP) for transporting mesh configurations via bidirectional streaming gRPC.

Tokens
161.4K
Snippets
168
Records
725
Agent score
99%

What's inside Nacos

  1. Overview of Nacos Console UI (Next) Implementation Progress

    develop

    The console-ui-next package is the next-generation Nacos Console UI. The implementation is organized into several phases, moving from core configuration management to advanced service management and AI-driven features.

    Current Development Status

    Phase 6 (AI Registry Center) is currently in progress. This phase focuses on:

    • MCP (Model Context Protocol) Server Management: Includes list, detail, and edit/create pages. Features include protocol selectors, publication strategy dialogs, and tool management.
    • Agent Management: Includes list, detail, and edit/create pages. Features include capability tags, skill counts, and unified publication logic.

    Completed Features

    • Configuration Management: Core CRUD, version history/rollback, batch operations, import/export, and canary releases.
    • Service Management: Completed.
    • UI/Brand Optimizations: Includes a redesigned top navigation bar, sidebar interactions (using Popover flyouts instead of Tooltips), and improved form layouts.

  2. Overview of Nacos Plugin Specifications

    develop

    Nacos plugin specifications define the lifecycle and integration patterns for extension points within the Nacos ecosystem. Plugins are used to customize how Nacos components are loaded, selected, executed, configured, and surfaced via the unified plugin management model.

    When developing or implementing a plugin, you must adhere to the following constraints:

    • Design Consistency: Plugins extend the Nacos Design Spec and must maintain stable [Resource Model] semantics.
    • API Compliance: Any plugin exposing HTTP endpoints must follow the established [HTTP API] rules.

  3. Overview of Nacos Client Runtime Specs

    develop

    The Nacos Client Runtime Specs define the implementation behavior that sits beneath the public Client SDK interfaces. These specifications bridge the gap between the high-level SDK, the underlying gRPC API, and the specific domain requirements for core Nacos services.

    Understanding these specs is essential for developers building or extending Nacos clients to ensure they correctly implement:

    • Config: Configuration management behavior.
    • Naming: Service discovery and registration.
    • AI Registry: AI-related registry capabilities.
    • Distributed Lock: Coordination and locking mechanisms.

  4. Overview of Nacos 3.x AI Registry Specs

    develop

    The AI Registry specs define the Nacos 3.x AI resource model. This model extends the core Nacos Design Spec and follows the shared Resource Model Spec. The AI Registry functionality is exposed to developers through several interfaces:

    • HTTP API
    • gRPC API
    • SDK
    • Client Runtime

    Use these specs to understand how to manage AI-specific resources, agents, and their lifecycles within the Nacos ecosystem.

  5. What is Nacos?

    develop

    Nacos is a dynamic naming and configuration service designed for service discovery and configuration management in cloud-native applications and microservices. It provides four core capabilities:

    • Service Discovery and Service Health Check: Allows services to register themselves and discover others via DNS or HTTP. It includes real-time health checks to ensure requests are only sent to healthy instances.
    • Dynamic Configuration Management: Centralizes configuration management across environments, allowing updates without requiring application redeployment.
    • Dynamic DNS Service: Supports weighted routing for mid-tier load balancing, flexible routing policies, and flow control.
    • Service and MetaData Management: Provides a dashboard to manage service metadata, configurations, Kubernetes DNS, health, and metrics statistics.

  6. Manage Nacos Authority Control

    develop

    Nacos provides an Authority Control module to manage access to the system through three primary components:

    1. User Management (UserManagement): Handles user identities and accounts.
    2. Roles Management (RolesManagement): Defines roles that group sets of permissions.
    3. Permissions Management (PermissionsManagement): Defines the specific granular permissions available within the system.

    These components work together to implement Role-Based Access Control (RBAC) within the Nacos console.

  7. Technical stack of Nacos Console UI (Next)

    develop

    The next-generation Nacos Console UI is built using a modern web stack designed for performance and developer experience. It transitions from the legacy React 16/Webpack setup to a React 18/Vite architecture.

    Core Stack:

    • Framework: React 18 + TypeScript
    • Build Tool: Vite 7
    • Styling: Tailwind CSS 4 (using the oklch color system with a blue/white theme)
    • UI Components: Shadcn/ui (built on Radix UI)
    • State Management: Zustand v5 (managing stores for auth, server, namespace, app, config, history, and service)
    • Routing: React Router v7 (utilizing HashRouter, lazy loading, and guards like AuthGuard, AdminGuard, and GuestGuard)
    • Internationalization: react-i18next (supporting zh-CN and en-US)
    • HTTP Client: Axios (configured with request/response interceptors and Token handling)
    • Code Editor: @monaco-editor/react

  8. Explore Nacos Config Domain Specifications

    develop
    The Nacos Config domain specifications provide a comprehensive technical breakdown of how configuration is managed, from the fundamental resource models to runtime behaviors and storage operations. Developers can use these specifications to understand the exact behavior of the Nacos configuration service, including how resources are defined, how clients publish and query data, how listeners react to changes, and how data is persisted and maintained for consistency.

  9. Project File Structure (console-ui-next)

    develop

    The project follows a modular structure for the Nacos Next Console:

    • src/api/: API client definitions (auth, config, namespace, server, service).
    • src/components/:
      • config/: Specialized editors (Monaco, Diff).
      • layout/: Sidebar and Header.
      • ui/: Shadcn/ui base components.
    • src/layouts/: Application-wide layouts (e.g., AppLayout.tsx).
    • src/pages/: Feature-based page components (e.g., configurationManagement, serviceManagement).
    • src/stores/: Zustand state management (auth, server, namespace, app, config, history, service).
    • src/types/: TypeScript interfaces.
    • src/locales/: Internationalization files.

  10. Understand the Nacos Naming domain structure

    develop

    The Nacos Naming domain is organized into a hierarchical specification structure that defines how service discovery, registration, and health management operate. The domain is split into three main layers:

    1. Top-Level Spec: Defines the overall positioning, responsibilities, design principles, and service type boundaries.
    2. Common Specs: Defines shared behaviors across all service types, including resource identity (service, cluster, instance), discovery/subscription semantics (query, push, local cache), health checking (weight, protection thresholds), metadata management, and operational diagnostics.
    3. Service-Type-Specific Specs: Defines behaviors unique to specific service models, such as the lifecycle of ephemeral vs. persistent services, consistency models (AP for ephemeral, CP for persistent), and client state management.

    When developing against Nacos or implementing custom logic, refer to these specs to understand the expected behavior of the naming subsystem.

  11. What is the Mesh Configuration Protocol (MCP)?

    develop

    MCP is a subscription-based configuration distribution API used to transport mesh configurations. It is conceptually aligned with xDS but uses specific service and proto definitions.

    In the MCP model:

    • A Source (Configuration Producer) pushes resource updates (additions, updates, or deletions) to a Sink (Configuration Consumer).
    • A Sink responds to updates with an ACK (if accepted) or a NACK (if rejected, e.g., due to invalidity).
    • The protocol uses bidirectional streaming gRPC services to facilitate this exchange.

  12. Overview of the Remote Agent Discovery (RAD) Protocol

    develop

    The Remote Agent Discovery (RAD) protocol (version 0.1.0) is an experimental protocol designed to facilitate remote Agent search, discovery, watching, and runtime endpoint publication.

    It addresses two primary developer needs:

    1. Discovery: Identifying which Agents satisfy a specific requirement when the target is unknown.
    2. Endpoint Resolution: Determining which calling protocols and endpoints are available for a specific Agent version.

    Note: RAD returns metadata required to call a remote Agent; it does not proxy the actual calls, nor does it define the message, task, or session protocols used by the Agents themselves.