nacos 配置管理中心 -- 小白学习教程

学习于：https://nacos.io/zh-cn/docs/what-is-nacos.html 潘孝哥
小贷最近要迁移到新框架上，所以我来尝试一波 nacos.

首先看它的作用：用来配置参数的，就比如我们通常在 properties 文件中写的

dubbo.protocol.id = dubbo

dubbo.protocol.name = dubbo
#dubbo.protocol.port = 20882
#RegistryConfig Bean
dubbo.registry.id = lls-nacos-sample-service-registry
dubbo.registry.address = nacos://172.16.90.191:8848
dubbo.registry.parameters.namespace = 59b4250f-e36f-46f8-938d-20a5b295c63e
dubbo.metadata-report.address = nacos://172.16.90.191:8848
dubbo.metadata-report.parameters.namespace = c69d33cb-2e87-4b29-8383-3ce4059e6096

这些东西都是可以在 nacos 中进行配置。这样的话，本地就不需要存储大多数的配置参数了。
nacos 的优势：
1.最重要的优势：动态修改属性值。
2.方便控制多个服务的共享属性值和私有属性值
3.去掉了很多的配置文件，而且易于搭载在各种系统中，如 spring，springboot.

后面来慢慢讲解这些优势：
先来个最基本的理解：我们要取值的时候，一般从 3 个地方取，一个是启动参数 -D ，第二个是 xml 文件，第三个是 properties 文件。 现在我们多了一个地方，就是 nacos 服务器。
这个-D 是比较牛逼的，无论你 nacos 上的初始值是啥，只要-D 上的和你一样，那么刚开始就要以- D 上的为准。不过，如果之后你在 nacos 上再进行发布，那么就算你是-D，也要乖乖听我号令。这样就充分保证了 nacos 的霸主地位（经过实验验证,这里要注意啊，你在 nacos 上发布得要经过修改后发布啊，原模原样发布无法改变！只要字符串没发生变化，发布就无法改变值）
然后到 properties 文件，这个和-D 的实验现象一致。
然后-D 的优先级高于 properties 文件的优先级。
至于 xml 文件的，这个应该是定一个 xml 文件，然后 properties 标签定义几个值即可测试，但是我一致没找到它的 xml 文件声明，大家有机会的可以试试。

然后是基本的使用了：
这个主要参考 nacos 的官方文档即可。无论你是 spring 还是 springboot 项目都是可以轻轻松松搭载上去。

这里对一些东西做理解：
以潘孝哥的 demo 为例：

由于 properties 文件默认被 spring boot 加载，然后首先读取的就是这些配置。这个是用来连接 nacos 服务器的。第一个是服务器地址，第二个是连接的命名空间的标识符。

也就是在命名空间里就进行了区分。这个存储空间就第一个分隔开来。

然后是第二个：启动类上的配置：

这里的 dataid 就是前面命名空间里的一个存储空间。

这里又进行了一次数据存储区域的划分。这就表示你这个启动类要使用的是那个 dataid 里面的数据。

所以现在大概的启动流程是这样的：
启动先读取 nacos 连接的配置，然后连接到相应的命名空间，然后再根据启动类的 dataid 设置，确认此服务连接的是那个 dataid 的数据。然后这里注意后面的 after 标签，apply-service 的 after 为 common,也就是说优先级是 comon 的高，所以 comon 和 apply-service 中有相同的数据时，以 comon 的为准。这个从潘孝哥的测试数据也可以的得知。

然后就看使用：

这里也支持 spring 原生注解 value 的使用，不过它默认的是不会自动刷新，而上面的 nacosvalue 则配置有 autofresh=true，也就是说 nacos 上刷新，则这里的值也会改变。

这里注意的是，第二个 demovalue 只会在启动时读取一次配置中的 demovalue 的值，后面都不会再改变。

嗯，大概就是这样的一个使用过程。然后看潘孝哥的设计，猜测是以后可以将大部分的配置都放在 nacos 上，这样就非常有利于开发。可以一个服务连接多哥 dataid，然后设置公共的 data（比如 dubbo 的配置之类的，几个服务使用的 dubbo 配置都是一样的），然后再设置私有的。 这里还可以方面的设置优先级，调控起来非常好。

因为它可以动态修改属性值，而不需要修改配置文件，修改配置文件的话，要使 properties 文件生效，则需要重启服务，这样就很麻烦。 而再比如最原始的，把属性值直接定义在 Java 文件中，用 static final 修饰，这是一种更不可取的行为，因为此时如果要修改的话，就需要改代码了，改代码就意味着要上版本，就变得更麻烦（虽然目前我还不太懂具体麻烦在哪）。

这就是 nacos 的优势所在。

然后分享一个测试结果：就是我一个系统中，有一个服务是老系统的，一个服务改造成 springboot 了。springboot 直接按前面的方式使用即可。老系统本来以为无望迁移了，后来发现里面有 spring 可以和 nacos 用，然后就分别使用两种方式搭载 nacos，spring 的是配置类加注解即可。 然后两个服务之间公共的子包则可以直接在 pom 文件中引入，然后要使用的地方直接加 nacos 注解即可，这里就不用连接注册中心了，因为启动的是服务类。

这里有一个小小的调试手段，就是在 nacos server 这里怎么看有谁连接进到哪个 dataid 了。我没发现像 mq 那样的管理界面，只发现有个

监听查询。这里输入前面的 dataid 和默认的 group 就可以查哪个连接进来了。如果没有连接进来的就为空。

nacos 的配置中心管理功能基本使用就是这样了。它还有注册中心的功能，以后有需要使用再去学习。非常感谢潘孝哥的指点。
欢迎大家交流讨论。