Shared and Extended Configuration Support in Nacos

In multi-module microservice architectures, common infrastructure settings—such as database connection strings, Redis endpoints, message broker URIs, or observability parameters—are frequently reused across services. To avoid duplication and simplify maintenance, Nacos Config provides two mechanisms for loading external configuration sources: shared-configs and extension-configs.

Both accept a list of configuration entries, each supporting the following fields:

• data-id: The identifier of the configuration item (e.g., database.yaml).
• group: Optional namespace grouping; defaults to DEFAULT_GROUP if omitted.
• refresh: Enables dynamic reloading when the remote config changes; defaults to true.

Configuration Example

spring:
  application:
    name: order-service
  cloud:
    nacos:
      config:
        server-addr: nacos.example.com:8848
        namespace: 7a3b1f9c-2d4e-4567-a8c1-0e2f3d4b5a67
        shared-configs:
          - data-id: base-logging.yaml
            group: COMMON_CONFIG_GROUP
          - data-id: cache-redis.yaml
            group: COMMON_CONFIG_GROUP
        extension-configs:
          - data-id: order-db-overrides.yaml
            group: ORDER_SERVICE_GROUP
            refresh: true
          - data-id: feature-toggles.yaml
            group: ORDER_SERVICE_GROUP
            refresh: false

Note: File extensions like .yaml must be explicitly included in data-id. Do not set file-extension separately—the parser infers format from the suffix.

Functional Distinction Between shared-configs and extension-configs

While both support identical syntax and runtime behavior, their semantic roles differ based on deployment context and override semantics:

• shared-configs is intended for cross-service configuration reuse. These entries typical reside in a generic group (e.g., DEFAULT_GROUP) and apply uniformly unless overridden.

• extension-configs serves scoped customization—e.g., per-application tweaks to shared values. For instance, most services may use a standard JDBC URL from shared-configs, while one service (inventory-service) overrides just the spring.datasource.url via its own extension-configs entry under its dedicated INVENTORY_GROUP.

Loading Order and Precedence Rules

Configuration resolution follows strict precedence:

1. Within the same category, later-listed items supersede earlier ones:

   • extension-configs[2] > extension-configs[1] > extension-configs[0]
   • shared-configs[1] > shared-configs[0]

2. Across categories, priority descends as:

   • Application-specific main configuration (derived from spring.application.name)
   • extension-configs
   • shared-configs

This hierarchy ensures that environment- or service-level adjustments take precedence over broad defaults without requiring conditional logic in code.