Nacos 配置中心基础整理

配置中心是Nacos众多功能之一，为微服务模式的应用开发提供了配置统一化管理工具，是Nacos一个强大的卖点。本文将从诞生背景，类似方案对比，以及核心管理模型展开介绍，并在应用上，以spring-clound-alibaba为列介绍最核心的配置文件拉取。

背景

配置，应用程序启动和运行时，读取的一些信息，动态调整程序行为，比如需要从哪里连接数据库，缓存多长时间过期等。具有以下特点：

• 只读，程序不允许更改配置
• 伴随应用的整个生命 周期
• 加载方式多样化，程序硬编码，环境变量，启动参数，配置文件(当前最流行)，数据库(通常作为配置中心存储介质)

程序硬编码，难以维护，每次更新必修重新打包，真实开发并不推荐。

环境变量，分布式服务器之间不可复用。

启动参数，可读性查，尤其在配置项太多的时候，更是难以阅读。

基于这样的缺陷，配置文件成为了管理配置的不二之选，并且可以用数据库作为存储介质，加以妥善维护。

无论采用什么方式，配置需要管理。

过去传统的单体应用里，一个应用程序具有自己的配置文件，但当单体引用拆分成各个微服务后，配置文件也被拆开，并且拆开后，各个微服务配置文件之间，还会存在冗余。

 因此，需要一个专门的服务器来统一管理配置文件，使得配置文件和具体服务在组织上解耦，实现配置文件的扩展和复用。

 Nacos 配置中心，正是提供了这样的一个解决方按。

相关方案

当前构建配置中心解决方案：

• apollo，携程提供，功能最全面
• spring cloud config，集成Netfix公司提出的配置中心技术，由于依赖git，所以性能很差
• nacos，性能最好，功能略逊apollo，但针对大型应用开发仍然够用

功能对比：

性能对比：

Nacos配置管理模型

配置文件存放Nacos配置中心服务器，而配置管理模型，反映了各个应用服务拉取配置文件的方式。就是: Namaspace-> Group->DataId

DataId，标识一个配置文件，里面包含各个配置项的集合，可以用多种格式，比如yml, ymal, properties等。

group，就是配置文件的分类，分类采用的语意按实际情况而定，比如根据项目区分。

namespace，对group的分类，分类采用的语意按实际情况而定，通常采用隔离的语意，按照部署环境做划分。

一个通常的实践：

dataId,Group, Namespace均可以在nacos配置中心后台管理页面进行建立。

Nacos 典型应用

此处选择集成了nocas的相关实现方案的spring-clound-alibaba，其具有spring-boot开箱即用的优势，开发简单，规避实现nacos繁琐的技术细节，让开发者集中在nacos核心功能的应用开发上。

获取配置文件

各个服务的bootstrap.yml编写以下代码，用nacos的配置管理模型定位到配置文件，获的配置项，并在代码里用@Value注解获取配置项的值

其中，

server-addr: 必填

file-extension: 配置文件扩展名，必填

namespace: 非必填，默认是nacos配置中心public空间的id

group：非必填，默认是DEFAULT_GROUP

以上配置信息，结合dataId，便可定位到配置文件，这里的dataId构建流程，用以下为代码描述：

var prefix = "";
var dataId = "";
if( spring.cloud.nacos.config.prefix 没有设置){
    prefix = {spring.application.name};
}else{
    prefix = {spring.cloud.nacos.config.prefix};
}

if(spring.profile.active 没有设置){
    dataId = {prefix} + "." +{spring.cloud.nacos.config.file-extension};
}
else{
    dataId = {prefix} + "-" + {spring.profile.active} + "." +{spring.cloud.nacos.config.file-extension};
}

 获取扩展配置和共享配置

• 使得一个微服务可以有多个配置文件。
• 使得多个微服务可以共享一个配置文件。

扩展配置：

 在spring.cloud.nacos.config下编写以下配置代码：

对于每一个ext-config[n]，

dataId: 必填，全名

group：非必填，默认是DEFAULT_GROUP

refresh: 非必填，默认是false

共享配置：

 spring.cloud.nacos.config.share-details里指定多个共享配置文件的dataId，用逗号连接。

spring.cloud.nacos.config.refreshable-details里指定需要支持刷新的共享配置文件dataId, 同样用逗号连接。其他没有指定的，默认不支持动态刷新。

注意：这个方式只针对default-group里的共享配置，所以不是很灵活，不推荐使用。

配置项应用优先级

结合前文，可以整理出Nacos配置中心拉取配置的三种方式：

A，内部命名规则，就是根据配置文件的dataId构建流程

B，扩展配置文件

C，共享配置文件

一个配置项在3种拉去方式里都出现的时候，应用的优先级为：

• A > B > C
• 如果均是B, 下标越大，越优先
• 如果均是C, 在列表里位置越靠后，越优先

扩展

nacos配置中心服务器，通常会以集群方式出现，至少是3个节点，因为要形成majority。而各个服务的bootstrap里，要写上所有的结点地址。

官方推荐的方式：

这样，微服务设置配置中心的时候，只需要设置那个vip，应对集群迁移或结点变化的情况。