Alibaba Nacos在Spring Cloud中的配置加载顺序超详细分析结果

一、本分析基于以下应用版本：

1、JDK：OpenJDK 11

2、SpringBoot：230RELEASE

3、SpringCloud：HoxtonSR4

4、Nacos：221RELEASE

二、bootstrapproperties 配置信息如下：

# 环境参数 dev,sit,prod

springprofilesactive=dev

springapplicationname=demo-core

springcloudnacosconfigserver-addr=>

本文主要介绍自己将nacos作为spring boot的配置中心的实践过程，希望对有需求的小伙伴提供一些帮助。

通过nacos实现配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

在linux系统中可以通过以下命令安装 docker-compse：

使用如下命令创建部署文件 nacos-standalone-mysql-8yaml ：

文件内容如下：

使用如下命令启动nacos：

使用下面的命令可以查看启动日志：

启动成功后访问： >

对于Server端来说，一般是设置在 {nacoshome}/conf/applicationproperties 里，如果参数名后标注了(-D)的，则表示是 JVM 的参数，需要在 {nacoshome}/bin/startupsh 里进行相应的设置。例如像设置 nacoshome 的值，可以在 {nacoshome}/bin/startupsh 进行如下设置：

除了上面列到的在 applicationproperties 里配置的属性，还有一些可以在运行时调用接口来进行调节，这些参数都在 Open API 里的 查看系统当前数据指标 这个API里有声明。

客户端的参数分为两种，一种是通过-D参数进行指定的配置，一种是构造客户端时，通过 Properties 对象指定的配置，以下没有带-D标注的都是通过 Properties 注入的配置。

专题回顾

Nacos专题Nacos 快速入门

Nacos专题Nacos 集群搭建

Nacos 既可以作为注册中线，提供服务注册与发现；又是配置中心，提供配置的动态管理。Nacos 既能支持 properties 类型的配置，也能支持 ymal 类型的配置。

为了满足 多租户、多环境、多服务 配置隔离的需求，Nacos 提供了 Data Id 、 Group 以及 Namespace 不同管理级别的概念，利用 Nacos 定义的层级关系，用户可以非常方便的管理多环境的配置。

Data Id 的完成格式如下：

完整的 Data Id 由 3 部分构成，具体格式说明如下：

示例：

如果 Data Id 的值为 nacos-config-devproperties ，则在 bootstrapproperties 配置如下：

如下图所示，用 Data Id 来区分开发、测试、生产环境配置：

在分布式系统中，我们经常会根据业务来对系统进行水平拆分，业务独立的模块单独构成一个系统，从而实现业务解耦。Nacos 的 Group 能够很好的应对分布式系统的配置管理。 Group 是 Data Id 的集合，按照业务系统来定义 Group ，然后再在每个 Group 下按照 dev 、 test 、 prod 来区分环境，这样整个系统配置就非常的清晰明了。

在 Nacos 服务端定义完分组后，还需要在项目中通过 springcloudnacosconfiggroup 配置来指定分组， 这样在项目启动的时候，就能拉取指定分组下的配置。

如下图所示，为订单系统创建分组：

Namespace 是用于在多租户之间进行配置隔离，不同的 命名空间 下，可以存在相同的 Group 和 Data Id ，再配合 Nacos 的权限管理功能，针对用户角色(多组合)，进行 Namespace 级别的读写权限控制。

Nacos 默认命名空间为 public ，当在新建一个 Namespace 时，Nacos会生成一个唯一标识UUID，在项目中通过 springcloudnacosconfignamespace 来指定命名空间。

Nacos 英文全称 Dynamic Naming and Configuration Service，它是 Spring Cloud Alibaba 的核心组件之一，致力于微服务架构中的服务注册与发现、配置管理。

Nacos 将注册中心和配置中心整合在一起，提供了两个核心功能，即服务注册与发现和动态配置服务。

Nacos 支持基于 DNS 和 基于 RPC 的服务发现，服务提供者向 Nacos 服务端注册服务后，服务消费者可以从 Nacos 服务端获取注册列表。

提供了一个简洁易用的 UI，方便用户管理所有环境的应用配置和服务配置，消除了配置变更时服务需重新部署的过程。还提供了包括 配置版本跟踪 、 金丝雀发布 、 一键回滚配置 以及 客户端配置更新状态跟踪 在内的一系列开箱即用的配置管理特性，大大降低配置变更带来的风险。

Nacos 分为服务端和客户端，服务端用来提供服务发现与注册等功能，客户端就是不同的应用和服务。

在 Nacos 的 Release Notes 可以看到每个版本的相关介绍。当前最新的稳定版本是 140。

Nacos 服务需要 Java 运行环境，因此，在启动服务之前需要确保你的服务器已经有了 Java 运行环境，并且配置好了 JAVA_HOME 。

参数说明：

-m：指定运行模式，standalone 表示单机模式

在 Nacos 配置文件中配置服务器ip，默认的端口号为8848，默认的用户名和密码均为nacos，访问 >

最近有项目组同学问到为什么自己配置了nacos，但配置不生效？我简单看了下，发现问题出在相关配置的优先级模式不同。

spring-boot项目，有bootstrap、application两个配置文件，结合profile，和支持的文件格式properties、yaml，已经有6个配置文件了。然后使用了spring-cloud-starter-alibaba-nacos-config 后，又提供了三级配置。这些配置之间的组合关系，将在无形中影响配置的效果。很多同学只知道其中的一种，因此在无意识引入两种或以上的配置后，就会发现有奇怪的配置不生效问题发生。

spring-boot项目依赖bootstrapyml 用于应用程序上下文的引导阶段，由父Spring ApplicationContext加载，其工作的阶段为父ApplicationContext 被加载到使用applicationyml的之前。也就是说 bootstrap 加载优先于 applicaton。

bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何Spring应用程序的外部属性的来源。bootstrap 里面的属性会优先加载，它们默认也不能被本地相同配置覆盖。

bootstrap 配置文件有以下几个应用场景：

由于spring-boot支持多种文件格式，所以多种格式之间，其优先级是平等的，只要找到了一个，就会被使用。一般有：properties、yaml、xml等格式。

应用级别的spring-boot配置文件，主要用于 Spring Boot 项目的自动化配置，其加载优先级低于bootstrapyaml。

nacos作为外部配置服务器，通过spring-boot的bootstrapyaml引入。但nacos本身，也提供了三级配置体系：主配置(只有一个，但会按照不同后缀名，去找到相关配置）、扩展配置、共享配置。

三级配置的优先级如下：主配置 > 扩展配置 > 共享配置

nacos提供的配置路径 springcloudnacosconfig 下，有一系列的属性用于定位主配置。基于 prefix（默认为 ${springapplicationname} 的值）、namespace、group（默认为字符串 DEFAULT_GROUP ）、file-extension（默认为字符串 properties ），按组装规则 ${prefix}-${springprofilesactive}${file-extension} 去找到一个配置。

在nacos的所有配置中，主配置（存在的情况下）具有最高的优先级，其同名配置值不能被扩展配置或共享配置中定义的同名属性所覆盖。

上述两类配置都支持三个属性： data-id 、 group （默认为字符串 DEFAULT_GROUP ）、 refresh （默认为 true ）。

实际上，nacos中并未对 extension-configs 和 shared-configs 的差别进行详细阐述。我们从他们的结构，看不出本质差别；除了优先级不同以外，也没有其他差别。那么，nacos项目组为什么要引入两个类似的配置呢我们可以从当初 该功能的需求（issue） 上找到其原始目的。

摘要其核心内容如下：

以上就是关于Alibaba Nacos在Spring Cloud中的配置加载顺序超详细分析结果全部的内容，包括:Alibaba Nacos在Spring Cloud中的配置加载顺序超详细分析结果、什么是NacosNacos注册配置中心介绍、spring boot使用nacos作为配置中心实践等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！