前言

版本选择：

spring-boot:2.3.2.RELEASE

spring-cloud:Hoxton.SR8

spring-cloud-alibaba:2.2.3.RELEASE

博客前瞻：

springcloud-alibaba-nacos（1）nacos组件功能介绍与下载安装

springcloud-alibaba-nacos（2）nacos启动，解决启动报错问题

springcloud-alibaba-nacos（3）nacos数据持久化到数据库

springcloud-alibaba-nacos（4）nacos作为注册中心

有了config组件，为什么Nacos还要将配置中心功能进行整合？

我们以前开发微服务项目的时候，为了方便配置文件的统一管理，通常都会引入netfilx的config组件，于是整个微服务架构变成了这样！

当我们服务配置交由了配置中心管理，我们服务在启动时，都会从config-server中拉取服务，通常呢，为了方便配置文件的管理，我们config-server都不会启动local存放配置，一般都会放在git仓库，或者svn仓库。

config组件的弊端

1.微服务配置实际上仍是在git或者svn上管理的…config-sever仅仅只是起到了一个项目启动时，去远端仓库拉取对应服务配置的作用！

2.配置文件变更时无法感知并通知服务器（默认）,必须借助git的Webhook功能以及cloud bus组件广播通知服务

---

config给我一种什么感觉呢，以前无法描述，最近经历了一些事情，终于可以较为贴切的描述出来了！

最近长租公寓某壳暴雷事件大火，很不幸，我也是某壳公寓下的一枚租户…

预付了一年的房租给二房东(某壳)，二房东每月（每季）向一房东(房屋产权持有人)交纳房屋租赁费，最近，二房东出现了问题，资金链断裂，没法向一房东按约支付房屋租赁费，导致一房东直接向租客施压，甚者将已经交纳过租金的租客赶出房门…

上边故事的二房东就如同于我们的confg组件,一房东就如同我们真正管理配置的地方—git、svn

config-server对微服务配置统一管理提供了作用，但并未提供最最核心的作用，因为实际上管理配置文件的并不是config-server 而是git、svn，config-server只是起到了一个拉取配置的作用罢了，这不一种中间商的感觉吗！>>>>>>>二房东起到了寻找房源的作用，但房子仍是一房东的

config-server服务down掉，导致整个微服务业务群不可用 >>>>>>> 二房东出事，租客大面积遭殃…

配置文件实际管理者git、svn更改了配置文件config-server没有默认的通知微服务从新拉取并应用最新配置的功能>>>>>>>> 一房东没有收到二房东应给付的房屋租赁租金,但顾客并不清粗…

以上种种，感觉实在太贴切了…都是血与泪的教训啊！！！！

---

使用nacos作为配置中心，将打破二手房东(中间商)这个桥梁，让我们租户（微服务）直接与一手房东(配置管理)接触…

微服务使用Nacos作为配置中心：

引入依赖

使用Nacos作为配置中心，我们需要额外再引入配置支持的依赖

        <!--引入Nacos配置中心客户端依赖-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>

注：工程项目引入了此依赖后，其默认就开启了配置中心客户端功能，在配置文件中必须要配置nacos的信息，否则启动项目会直接失败…

项目配置

我们首先，先看一下Nacos 配置中心的管控台

DataId 以及Group目前来说，不清楚是什么

没事，我们来看官网说明

那么，我们微服务在从Nacos配置中心拉取配置的时候，是如何找到对应配置的呢？？font>

我们以逛商场东西为例…

1.找命名空间

上上图的public就是命名空间信息了

什么是命名空间呢？理解为对应哪个商场？

2.找对应分组

上上图的Group，便是分组信息了

什么是分组呢？就类似于商场里的商品分类，生鲜区、零食区、水果区等等

3.找对应的标识

上上图的DataId，便是标识信息了，比方说，生鲜区的A1-xx-xx-1、零食区的A1-xx-xx-1…

#指定当前服务端口号
#server:
#  port: 30020
spring:
  application:
    #指定当前服务名字
    name: app-login
  cloud:
    nacos:
      #指定nacos服务端的位置（当前仅是作为一个变量罢了）  默认为localhost:8848
      server-addr: http://xxxx:8848
      discovery:
        # nacos注册中心服务端位置（注册中心服务端地址的实际使用） 默认就是此配置，可省略不写
        server-addr: ${spring.cloud.nacos.server-addr}
      config:
        #nacos配置中心服务端位置 默认就是此配置，可省略不写
        server-addr: ${spring.cloud.nacos.server-addr}
        #服务端配置文件内容格式
        file-extension: yaml

配置文件默认命名空间就为public,所以无特殊指定，可忽略不写

配置文件默认的分组Group为DEFAULT_GROUP,所以无特殊指定，可忽略不写

实际上，最基础的使用只需要注意两个配置：

1.spring.appliaction.name

需要构建DataId的 前缀

一个完整的DataId的组成对应配置文件应该为spring.application.name-spring.profiles.active.配置文件后缀（yml、properties）

2.spring.cloud.nacos.server-addr

spring.cloud.nacos.server-addr在配置文件中处于一个变量的位置，配置文件中的注册中心地址以及配置中心地址默认都是引用的此配置，所以其非常重要

Nacos控制台添加配置文件

注意此刻我们现在在public,这个命名空间位置下

实战演示，我们以前边的app-login服务为例子

没有指定环境，那么DataId组成则为 服务名.配置文件后缀 即app-login.yml

控制台保存配置

微服务项目更改配置文件名

原本项目配置文件application.yml 或者application.properties需要更名为bootstrap.yml 或者bootstrap.properties

测试配置中心功能

启动项目

发现项目成功拉取到了位于Nacos配置中心的配置文件，将端口号更改为了30020…

如此，则证明了配置中心功能完成了

配置文件精简

实际上，由于配置文件中许多的默认配置，如果无特殊更改，可精简至如下：

为了演示配置中心功能，我才将服务端口信息保存到了远端配置文件，但实际开发，为了更好接入项目，我们通常都会基础信息配置在本地…

server:
  port: 30020
spring:
  application:
    name: app-login
  cloud:
    nacos:
      server-addr: ip:8848
      config:
        #服务端配置文件后缀
        file-extension: yml

Nacos动态刷新项目配置文件

首先呢，我们把我们前边的app-user也改造为nacos 配置中心客户端

使用@value读取我们自定义的配置

@RestController
@RequestMapping("/user")
public class UserController {
    @Value("${systemInfo.name}")
    private String userName;

    @GetMapping("/test/refresh")
    public String testRefreshConfig() {
        System.out.println(userName);
        return userName;
    }
}

构建app-user的配置文件存于nacos

启动项目，测试我们的接口/user/test/refresh 尝试获取配置文件中自定义配置systemInfo.name

能成功启动且读取到nacos的配置文件，这说明app-user 作为nacos配置中心客户端已经OK了…

当然,这只是以往config组件相关的功能,实际上Nacos配置中心的功能远远不止如此！

前边讲过，Nacos作为配置中心，消除了中间商，配置更改无需借助Bus消息总线即可达到广播通知客户端服务的强大效果！接下来，我们就来演示一下！

开启动态刷新配置

nacos默认是没有开启配置动态刷新的，我们需要使用注解开启！

在需要刷新配置的类上，打上注解@RefreshScope

测试：

首先，我们在nacos控制台上更改app-user的配置文件

当一点击提交确定，客户端立马感知到了配置文件的变化！！！

此时，我们并没有重启项目，直接再次访问接口http://localhost:40020/user//test/refresh

发现自定义配置systemInfo.name的值已然发生了改变！！！

注意点：

1、nacos客户端虽然可以秒级感应客户端配置，但这种情况仅限于自定义配置等…如果您想动态刷新数据库的数据源，你还需要额外的复写很多类…

2、不要过度依赖其动态刷新配置的功能，尤其是生产环境

项目源码：

springcloud-aibaba-nacos