nacos 基础了解

nacos 首先它是用java写的其实就是一个springboot工程，它功能有很多，这里我们主要了解一下nacos 的服务发现和配置管理功能。

nacos 是阿里的开源项目，应用于微服务，微服务是将单体应用拆分成一个个服务节点，nacos主要功能是服务发现和微服务的配置集中管理。

配置管理

理解配置中心

 什么是配置？

应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。
配置主要有以下几个特点：

• 配置是独立于程序的只读变量

配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置

• 配置伴随应用的整个生命周期

配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

• 配置可以有多种加载方式

常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等

• 配置需要治理

同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理

什么是配置中心

在微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余，如下图：

 假设这时候你有很多服务，然后你这时候分别对每个服务进行配置文件的管理，这时候你就会发现配置文件是冗余的，而且每个服务会有多个实例，这时候你就发现，配置文件特别的分散，所以基于微服务开发的化，需要一个配置中心集中去管理配置

下图是配置中心的功能图

配置中心的服务流程如下：
1、用户在配置中心更新配置信息。
2、服务A和服务B及时得到配置更新通知，从配置中心获取配置。

总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件

配置中心是微服务化不可缺少的一个系统组件，在这种背景下中心化的配置服务即配置中心应运而生，一个合格的配置中心需要满足如下特性：

• 配置项容易读取和修改
• 分布式环境下应用配置的可管理性，即提供远程管理配置的能力
• 支持对配置的修改的检视以把控风险
• 可以查看配置修改的历史记录
• 不同部署环境下应用配置的隔离性

Nacos配置管理

 发布配置

 首先在nacos发布配置，nacos-restful-consumer服务从nacos读取配置。
浏览器访问 http://127.0.0.1:8848/nacos，

打开nacos控制台，并点击菜单配置管理->配置列表：
在Nacos添加如下的配置：

nacos-restful-consumer:

Namespace: public
Data ID: nacos‐restful‐consumer.yaml
Group : DEFAULT_GROUP
配置格式: YAML
配置内容： common:
                                name: application1 config

 这样一个简单的配置就发布成功了

获取配置

用spring的注解就可以实现

在nacos-restful-consumer工程的controller中增加获取配置的web访问端点/configs，通过标准的spring @Value方式。但这种方式 ，是静态的

@Value("${common.name}")
private String common_name;

@GetMapping(value = "/configs")
public String getvalue(){
return common_name;
}

当然要添加naco配置管理的客户端

要想从配置中心获取配置添加nacos-config的依赖

<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring‐cloud‐starter‐alibaba‐nacos‐config</artifactId>
</dependency>

我们要想让nacos知道从哪获取配置，我们需要在bootstrap.yml添加配置

spring:
        cloud:
                nacos:
                        config:
                               server‐addr: 127.0.0.1:8848 # 配置中心地址
                                file‐extension: yaml
                                group: DEFAULT_GROUP

注意：要使用配置中心就要在bootstrap.yml中来配置，bootstrap.yml配置文件的加载顺序要比application.yml要优先。

 折摸着就能根据application.name和扩展名，就能让nacos找到nacos配置管理中心的这个yaml文件

基于上面的例子，若要实现配置的动态更新，只需要进行如下改造

// 注入配置文件上下文
@Autowired
private ConfigurableApplicationContext applicationContext;

@GetMapping(value = "/configs")
public String getConfigs(){
return applicationContext.getEnvironment().getProperty("common.name");
}

配置管理模型

 

 

Nacos抽象定义了Namespace、Group、Data ID的概念，具体这几个概念代表什么，取决于我们把它们看成什
么，这里推荐给大家一种用法，如下图：
Namespace：代表不同环境，如开发、测试、生产环境。
Group：代表某项目，如XX医疗项目、XX电商项目
DataId：每个项目下往往有若干个工程，每个配置集(DataId)是一个工程的主配置文件

 

 

 自定义扩展的 Data Id 配置

了解扩展配置文件得优先级问题

  ext-config扩展配置

pring Cloud Alibaba Nacos Config可支持自定义 Data Id 的配置。 一个完整的配置案例如下所示：

 

 可以看到:
通过 spring.cloud.nacos.config.ext-config[n].data-id 的配置方式来支持多个 Data Id 的配置。
通过 spring.cloud.nacos.config.ext-config[n].group 的配置方式自定义 Data Id 所在的组，不明确   配置的话，默认是 DEFAULT_GROUP。

我们也可以发现扩展配置我们是用数组表示得。这点要注意，因为这里边有优先级问题

通过测试发现：
扩展配置优先级是 spring.cloud.nacos.config.ext-config[n].data-id 其中 n 的值越大，优先级越高。
通过内部相关规则(应用名、扩展名 )自动生成相关的 Data Id 配置的优先级最大。然后主配置文件优于扩展文件配置