1.引言
上一节我们借助于Nacos实现注册中心，完美替换了Eureka在项目之初的功能，开始本章节之前我们一起回忆下Nacos实现注册中心的关键步骤
引入springcloud-alibaba/nacos-discovery依赖
去除原eureka依赖、去除配置文件中eureka注册信息
新增nacos注册信息：spring.cloud.nacos.server-addr:localhost:8848
重启项目并验证
在此基础之上我们验证了Nacos的负载均衡策略、权重控制、环境隔离等信息，希望大家还能有点印象。
2.为什么需要配置中心
试想最初的单体应用到如今的微服务部署（服务可能上百个），配置文件从修改到重启完成，服务中断可以按分钟计。以笔者负责应用为例，当数十数百个应用都需要修改配置，每个都重启部署的时候，服务中断将不再是可估算的现象。
因此我们需要一个类似注册中心的中间件，将配置中心从应用中解耦，应用不再是完全读取本地配置（部分不会频繁热更新的参数仍应用自身维护），而是直接拉取配置中心的信息作为应用参数，后续执行自己的业务流程。
下图为Nacos实现原理图：
但是引入配置中心的同时，我们不免思考一些Nacos已经遇到过、并成功解决的问题：
配置中心挂了怎么办？
谁负责将配置变更同步给应用？pull?push？
配置中心本身多节点部署，自身数据不同步又该如何解决呢？
Nacos是如何解决这些问题的，读者们可以参见上一节：Nacos白皮书或等笔者后续给出分析，基于上述背景，我们本章节将借助Nacos带领大家实现一个配置中心。
3.Nacos实现配置中心
3.1 新增配置信息
Nacos实现配置中心较为简单，首先在服务端新增一个配置信息（profile指项目运行环节：dev/test/pro）
注意：此处笔者新增在public空间下，如有部分读者是dev添加，则对应需要追加namespace(参见上节)
3.2 微服务拉取配置信息
配置完成之后，下一步就是在应用中拉取到刚才的配置信息。回顾我们原来的应用启动过程，应用启动时会读取本地配置文件application.yml，nacos也不例外他会将nacos配置信息同application.yml中的信息合并输出。那么问题来了：如果应用不能先读取到nacos配置信息（nacos地址-->配置信息）又怎么合并到一起呢？因此Spring引入一个新的配置文件：bootstarp.yaml文件，其读取顺序要优先于application.yml文件，如下：
1.引入nacos-config依赖
在user-service中新增nacos-config依赖
2.新增bootstrap.yaml文件
在user-service中新增配置文件：bootstrap.yaml，内容如下：
此时应用就会使用以下规则作为文件的DataId匹配对应的配置文件：{spring.application.name}-${spring.procile.active}.${spring.cloud.nacos.config.file-extension}
以本例为准读取的即为：userservice-dev.yaml
3.应用读取nacos配置
对于nacos的配置其使用也做到了开箱即用，只需借助@Value注解即可，我们做如下添加
访问应用发现即生效
4.Nacos配置热更新
如果只是做到了配置中心，显然对于Nacos的配置中心的能力是有所低估的，nacos可以做到毫秒级配置热更新，其实现也有多种方式。
1.@RefreshScope
在@Value注入变量所在类上增加@RefreshScope即可，代码如下：
修改后我们重启应用并发完一次，发现访问效果没变，此时我们修改配置文件如下，并点击发布：
注意：此时我们做了两件事情：①修改配置 ②发布配置，但是没有重启应用
再次访问，发现配置已及时生效，如下所示，感兴趣的也可以做更多格式的尝试，会发现都是及时生效
实际当用户修改配置文件时，nacos会通知客户端此时配置更新，日志如下：
如果有读者对@RefreshScope的热更新感兴趣，可移步至：@RefreshScope热更新原理
2.@ConfigurationProperties注解替代@Value
我们在user-service工程中新增一个配置类，用于读取此例中配置信息，代码如下：
需注意，此配置类我们约定死了配置的前缀，即默认：约定大于配置，后续此配置类将只获取pattern开头的配置信息，通过拼接属性值得到完整的配置信息，此例中即：前缀（pattern）+ 属性（dateformat），通过此唯一key去nacos获取配置信息。重启应用后发现同样生效。
5.Nacos配置共享
对于微服务部署情况下，每个应用都会配置多个环境的配置文件，通过不同环境的active标识获取指定环境的配置信息，但也存在部分配置文件没有profile信息，例如：
[spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml
[spring.application.name].yaml，例如：userservice.yaml
此时[spring.application.name].yaml 因不包含环境信息，将被多个环境所共享。下面我们实例展示
1.添加共享文件配置
在nacos服务端新增一个：userservice.yaml文件，此文件没标识任何环境信息
2.服务读取共享配置
首先在配置文件类中增加新增配置内容
接着我们新增一个http接口，用来访问整个配置信息
此时我们修改8081、8082两个启动类环境配置信息如下：
因我们目前只有dev、公共两部分配置信息，所以profile=dev可以读取到dev + 共享，而profile=test的因没有test配置信息，因此只能读取共享信息。验证生效，效果如下：
6.Nacos配置共享优先级
对于本地配置、共享配置、服务名-profile配置优先级有如下规则关系：
为了验证效果，我们同时在三个文件中增加一组配置信息，并进行验证：
本地新增
userservice.yaml新增并发布
userservice-dev.yaml新增
在代码中新增属性值，重启服务
验证效果如下
7.搭建Nacos集群
虽然前面我们对Nacos的功能和特性做了详细的论述和实战，然而对于Nacos本身的架构部署，我们却一直采用单点，对于一个新引入的中间件来说，如果它自身就不能保证高可用，那么对于整体架构而言它就是有待商榷的。因此在Nacos功能学习的最后一章节，我们将会搭建一个Nacos集群，模拟真实的生产Nacos情况。
1.架构模型
对于Nacos集群的部署情况，Nacos官方给出如下架构图：
即部署nacos对应三个节点，同时借助负载均衡代理3个nacos节点，实现整体高可用。本节中我们将借助于Nginx实现负载均衡，架构模型如下（MySQL此案例中采用单实例模拟）：
3个节点对应ip、端口如下
节点
IP
端口
nacos1
本地ip
8845
nacos2
本地ip
8846
nacos3
本地ip
8847
2.集群搭建
搭建整体步骤如下，我们将依次展开
初始化nacos数据库表结构
下载nacos安装包并配置启动参数（IP/端口）
启动nacos集群
nginx实现反向代理
2.1 初始化数据库表
Nacos官方默认数据存储采用内嵌数据库Derby，不属于生产可用的数据库。官方推荐最佳实践是使用支持主从的高可用数据库集群，如有兴趣可以进一步学习：黑马程序员-MySQL高阶教程，此例中为方便实践采用单点模式，我们新建一个nacos数据库，导入下面的DDL、DML语句
2.2 下载安装包并配置启动参数
nacos下载安装，可以参照前面课程：Nacos下载安装，如不想下载可直接采用本教程安装包：
nacos-server-1.4.1.zip
(75.4 MB)
1.解压安装包
注意：nacos文件夹路径不允许包含中文，否则运行异常
上述文件夹中bin主要包含：启动、停止脚本；config包含：配置文件
2.更改cluster.conf.example
修改文件名称：cluster.conf.example --> cluster.conf
编辑cluster.conf，新增以下配置，此处IP以自己本地ip为准(在cmd控制台可使用ipconfig指令查看对应IPv4地址)
此时启动会发现会因数据库连接失败而启动失败，因此下一步我们需要配置nacos数据源
3.配置nacos数据源
在nacos-config文件夹中编辑：application.properties，会发现下面一段注释信息，因此我们接下来需要修改的就是此处
放开注释并修改为本地连接，以笔者为例，此处如下，读者们需以自己mysql本地端口、用户名、密码为准进行修改。修改后保存、重启nacos
2.3 启动nacos集群
基于上述步骤，我们完成一个nacos节点的更改，但是细心的同学应该可以发现目前还存在两个问题：
nacos默认启动端口：8848，我们集群中3个节点没有此端口，并且我们尚未修改
3个nacos节点，当前我们只完成了一个，还剩余两个尚未修改
因此接下来，我们重命名nacos文件夹为：nacos1，并基于nacos1复制出：nacos2、nacos3，然后修改每个文件夹中的启动端口，如下：
nacos1文件下，application.properties --> server.port=8845
nacos2文件下，application.properties --> server.port=8846
nacos3文件下，application.properties --> server.port=8847
最后我们分别启动3个nacos节点，启动方式同单个启动无差异
注意：前面我们启动nacos指令为：startup.cmd -m standalone，即为单机启动，此时启动直接启动startup.cmd即可，此时启动为集群启动，通过查看下面启动日志也可以看到是以集群方式启动。
此时我们访问任意端口的nacos均能发现3个节点信息
2.4 nginx反向代理
解压此安装包到任意非中文目录：
nginx-1.18.0.zip
(1.6 MB)
，修改：nginx-1.18.0/conf/nginx.conf文件，在http模块中加入以下配置
如下图所示：
其中upstream后nacos-cluster为配置项名称KEY，我们给三个ip+端口配置进去VALUE，当访问localhost:80端口 + /nacos后，就自动对访问路径http://key中key对应的value做负载均衡。
我们启动nginx(nginx目录下 start nginx.exe)后访问：http://localhost/nacos，会发现负载均衡配置成功。
3.应用接入
当访问入口从单个nacos应用变成Nginx后，我们对应的注册地址也将发生变化：
修改后重启应用，会发现服务依然注册成功，如下：
8.总结
本章节我们针对Nacos作为配置中心的功能特性做了实战性演练，同时针对Nacos实际部署情况做了一个集群搭建演示，但同时这个集群搭建也给我们预留了一些更多的思考：
Nginx代理本身localhost这种IP应该变成域名，这样后续及时有服务迁移，nacos客户端也无需修改配置
Nacos的多节点部署应考虑异地容灾，同城备份，从而保证服务的高可用性
在本章节需要大家重点关注Nacos实现配置中心的步骤、热更新的实现方式，以及多配置文件的优先级顺序（后续生产发现配置信息读取不一致可借助此进行排查），集群搭建一般会运维团队搭建但也不排除大家自己上手的可能性。
截止本节，完整代码工程：
cloud-demo.zip
(139 KB)
