SNacos Config--服务配置

1.服务配置中心介绍

1.1微服务架构下关于配置文件的一些问题：

1. 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。

2. 配置文件无法区分环境--开发环境  测试环境  线上环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环

境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动

维护，这比较困难。

3. 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。

基于上面这些问题，我们就需要配置中心的加入来解决这些问题。

1.2配置中心的思路是：

1.首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。

2.当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。

3.当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

1.3在业界常见的服务配置中心，有下面这些：

1.Apollo------>很多使用apollo

Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料 也写的很详细。

2.Disconf

Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。

3.SpringCloud Config

这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配置存储支持Git<git没学>。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。

4.Nacos

这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心。

2.Nacos Config的使用

使用nacos作为配置中心，其实就是将nacos当做一个服务端，将各个微服务看成是客户端，我们将各个微服务的配置文件统一存放在nacos上，然后各个微服务从nacos上拉取配置即可。

2.2在微服务中引入依赖

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

2.3在微服务中添加nacos config的配置

注意:不能使用原来的application.yml作为配置文件，而是新建一个bootstrap.yml作为配置文件

2.3.1bootstrap和application都是SpringBoot项目中的配置文件,他们的区别主要有以下的几个方面

1.加载顺序区别

bootstrap配置文件是比application配置文件优先加载的,因为bootstrap是由spring父上下文加载,而application是由子上下文加载

2.优先级区别

bootstrap加载的配置信息是不能被application的相同配置覆盖的,如果两个配置文件同时存在,也是以bootstrap为主

3.应用场景区别

2.3.2bootstrap常见应用场景

1.配置一些固定的,不能被覆盖的属性.用于一些系统级别的参数配置

本地的配置文件是默认不能覆盖远程的配置的

2.一些需要加密/解密的场景

3.当你使用了Spring Cloud Config配置中心时,这时需要在boostrap配置文件中添加连接到配置中心的配置属性来加载外部配置中心的配置信息,专业翻译如下

2.3.3application常见应用场景

1.常用于SpringBoot项目的自动化配置

2.用于一些应用级别的参数配置

在大部分情况下不用区分这两种情况,只需要使用application即可,效果基本是一致的

配置文件优先级(由高到低):

bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml

#这个文件的优先级要高于application.properties,--引用配置中心的配置内容
#如果application和bootstrap中有相同的内容，则以bootstrap为主

spring.application.name=springcloud-order
#指定nacos配置中心的地址
spring.cloud.nacos.config.server-addr=localhost:81
#指定nacos中心文件的后缀--默认为properties
spring.cloud.nacos.config.file-extension=properties

3.在nacos中添加配置

找到配置中心的配置列表，点击右上角的+号

将application.properties的内容转移到nacos的配置中心的配置文件中

注释本地的application.yam中的内容， 启动程序进行测试 ，如果依旧可以成功访问程序，说明我们nacos的配置中心功能已经实现

4.配置动态刷新

        我们实现了配置的远程存放，但是此时如果修改了配置，我们的程序是无法读取到的，因此，我们需要开启配置的动态刷新功能。

1.在nacos配置文件上加上一句话

2.在需要读取配置的类上添加注解

@RefreshScope:实时刷新读取配置中心的内容===读取的为自定义配置的内容

@RestController 
@RefreshScope//只需要在需要动态读取配置的类上添加此注解就可以 
public class NacosConfigController { 
@Value("${config.appName}") 
private String appName; 
//2 注解方式 
@GetMapping("/nacos-config-test2") 
public String nacosConfingTest2() { 
return appName; 
} 
}

5.配置共享

        当配置越来越多的时候，我们就发现有很多配置是重复的，这时候就考虑可不可以将公共配置文件提取出来，然后实现共享呢？当然是可以的。接下来我们就来探讨如何实现这一功能。

同一个微服务的不同环境之间共享配置

        想在同一个微服务的不同环境之间实现配置共享，只需要提取一个以 spring.application.name 命名的配置文件，然后将其所有环境的公共配置放在里面即可。

5.1新建一个名为datasource.properties配置存放微服务的公共配置

5.2修改我们服务中的bootstrap.properties

#引用扩展的配置文件
#扩展文件的id
spring.cloud.nacos.config.extension-configs[0].data-id=datasource.properties
#扩展文件所在的组 默认为DEFAULT_GROUP
spring.cloud.nacos.config.extension-configs[0].group=DEFAULT_GROUP
#是否实时刷新
spring.cloud.nacos.config.extension-configs[0].refresh=true

6.命名空间

命名空间(Namespace) （dev开发环境  test测试环境  online线上环境）

命名空间可用于进行不同环境的配置隔离。一般一个环境划分到一个命名空间

6.1命名空间的创建:

6.2修改我们服务中的bootstrap.properties 

#指定配置文件所在的命名空间---默认为public
spring.cloud.nacos.config.namespace=36d53dc9-5c53-43e8-ba70-1f29fa7a145c