Nacos配置文件使用经验及CAP原则详解

1、入门

发布配置

Data ID: nacos‐simple‐demo.yaml

Group : DEFAULT_GROUP

配置格式: YAML

配置内容： common:

     ;                   config1: something

新建配置

在spring cloud生态下使用nacos config很容易，引入pom依赖：

<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

创建bootstrap.properties文件，并添加nacos server的连接地址即可：

spring.application.name=demo-api
spring.cloud.nacos.config.server-addr=nacos服务器地址
spring.cloud.nacos.config.prefix=nacos匹配配置前缀，默认为${spring.application.name}

2、配置文件

2.1. 规则配置

nacos上的dataId完整格式如下：

${prefix}-${spring.profile.active}.${file-extension}

• prefix：取自bootstrap配置文件里面spring.cloud.nacos.config.prefix的值，而该配置的默认值又为${spring.application.name}
• spring.profile.active：取当前环境的profile。如果项目spring.profile.active为空，dataId格式变成 ${prefix}.${file-extension}
• file-exetension：为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension来配置。目前只支持 properties和yaml类型，默认properties。

实际测试，如果配置了spring.profile.active，项目会主动获取nacos服务器上的配置文件包括：

${prefix}-${spring.profile.active}.${file-extension}

${prefix}.${file-extension}

2.2. 共享配置

大一点的项目，通常需要将配置信息拆分成多个配置文件，如：数据库连接信息、多语言配置等。因此就存在了两种情况：

• 一个项目会加载多个配置文件。
• 多个项目会共享同一个配置文件。

此时可以使用 shared-configs 或 extension-configs ，一直没发现二者之间有啥区别，作用和用法基本一样。例如：

spring.cloud.nacos.config.shared-configs[0].data-id=mysql.properties
spring.cloud.nacos.config.shared-configs[0].group=DATABASE_GROUP
spring.cloud.nacos.config.shared-configs[1].data-id=redis.properties
spring.cloud.nacos.config.shared-configs[1].group=DATABASE_GROUP
spring.cloud.nacos.config.shared-configs[2].data-id=common-i18n.properties
spring.cloud.nacos.config.shared-configs[2].group=I18N_GROUP
spring.cloud.nacos.config.shared-configs[2].refresh=true

上述配置中，将 shared-configs[n] 替换成 extension-configs[n]，并没有任何不同。

3. 优先级

1.配置文件优先级

按照前面介绍的，在使用nacos后，项目的配置文件来源多了起来，按照从高到低的优先级顺序分别为：

• 通过内部相关规则 ${prefix}-${spring.profile.active}.${file-extension} 自动生成相关的Data Id配置。
• 通过 extension-configs 方式支持的Data Id配置。
• 通过 shared-configs 方式支持的Data Id配置。

2. 共享配置内部优先级

共享配置 shared-configs[n]、extension-configs[n]内部，n的值越大，优先级越高。

前面的例子中优先级顺序：common-i18n.properties > redis.properties > mysql.properties

3. 本地优先级

如果在配置文件中开启了nacos config，在nacos服务器和项目本地，都创建了同样的配置文件。nacos服务器上的配置项，优先级比本地高。

4. 通过日志查看优先级

当你实在搞不清naco配置文件加载的优先级时，不要慌，直接看启动项目日志即可。

在spring项目中开启nacos config后，启动项目会在控制台打印出nacos加载的所有配置文件，而且按照优先级顺序从前往后排序。

如按照前面的配置，打印出来的日志为：

[PropertySourceBootstrapConfiguration.java:112] [] [ ] - Located property source: [BootstrapPropertySource {name='bootstrapProperties-demo-api-native.properties,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-demo-api.properties,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-demo-api,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-common-i18n.properties,I18N_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-redis.properties,DATABASE_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-mysql.properties,DATABASE_GROUP'}]

4. 项目规划

这里谈谈一个项目创建时，有关nacos config相关配置规划的想法。

1. 分配置文件

项目本地配置文件的功能分类：

• bootstrap-{profile} ：主要存放 nacos 的环境信息，不同环境下的nacos服务器地址可能不同。
• bootstrap ：存放 nacos 与环境无关的基础信息，如 shared-configs[n]、extension-configs 等，以及服务名称、端口号等。
• application-{profile} ：主要用于开发环境的配置，本地开发时有些参数不希望直接改公共的 nacos，可以在配置文件中修改。
• application ：本地开发时，存放与环境无关的基础信息。

总体来说，在开启nacos config服务后，都是以服务器上 ${prefix}-${spring.profile.active}.${file-extension}为准。本地application的作用及其有限，除非满足一些特殊的本地开发场景需求。

2. 分环境

虽然可以在一个nacos服务器上，通过${prefix}-${spring.profile.active}.${file-extension}来分环境，但不建议这么做。

不同环境nacos的服务器健壮程度、安全保密程度等，都是有不同要求的。一般建议在一个nacos服务器上，根据不同环境，连接不同的 namespace。甚至，根据不同环境，连接不同的nacos服务器。

我目前常用的做法，就是项目工程中不存放 application 相关的配置文件，只保留 bootstrap.properties 文件。不同环境下的配置文件是完全通过不同的nacos服务器或namespace来区分的，在本地运行时或 DevOps 部署时，通过传递参数来运行。例如本地运行时 Program arguments 的配置：

--nacos.url=http://x.x.x.x:xxxx
--nacos.config.namespace=xxx
--spring.cloud.nacos.discovery.enabled=false
--rocketmq.consumer-enabled=false

3. 分项目

通过 GROUP 来区分项目。而多个项目公用的一些配置，可独立出几个 GROUP，如：数据库连接配置、多语言配置等。

5. CAP

我们知道分布式 cap 理论中，只能满足 cp 或 ap。就注册中心而言分类如下：

• eureka 实现的是ap；
• zookeeper（基于 paxos算法）、consul（基于 raft算法） 实现的是 cp；
• nacos 既能实现 ap，也能实现 cp（基于 raft算法）。

nacos 集群默认支持的是 cap 原则中的 ap 原则。但是Nacos 集群可切换为CP原则，切换命令如下：

curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

同时，微服务的 bootstrap.properties 还需配置如下选项，指明注册为临时/永久实例。 AP模式不支持数据一致性，所以只支持服务注册的临时实例，CP模式支持服务注册的永久实例，满足配置文件的一致性

#false为永久实例，true表示临时实例开启，注册为临时实例
spring.cloud.nacos.discovery.ephemeral=true

以上就是Nacos配置文件使用经验及CAP规则详解的详细内容，更多关于Nacos配置文件CAP的资料请关注脚本之家其它相关文章！

最新评论