Nacos简单介绍与快速实现Nacos作为配置中心(私有配置)

1. Nacos简介
   Nacos除了实现了服务的注册发现之外，还将配置中心功能整合在了一起，
   通过Nacos的配置管理功能，我们可以将整个架构体系内的所有配置都集中在Nacos中存储。
   另外，在分布式系统中，由于服务数量巨多，为了实现更灵活的管理权限、安全性，
   实时更新以及一次打包，多处运行，所以需要分布式配置中心组件

   Spring Cloud Alibaba Nacos Config

2. 快速实现Nacos作为配置中心(私有配置)
   1.进入Nacos的控制页面，在配置列表功能页面中，点击右上角的“+”按钮，进入“新建配置”页面
   Data ID：填入nacos-config-client.yml，注意：Data ID 的默认扩展名为 .properties ，希望使用yml配置，此处必须指明是*.yml
   Group： 不修改，使用默认值DEFAULT_GROUP
   配置格式：选择yaml
   配置内容：应用要加载的配置内容，这里仅作为示例(注：请将下面内容改成yml格式填入，这里是为了书写方便)

                   cnf.message=hello nacos config clent
   

   注1：当新建配置的DataID的值与模块名相同时，表示此配置是此模块的私有配置

   2.导入nacos配置中心客户端依赖

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

 电脑启动：引导系统BIOS->windows操作系统

3.创建配置文件bootstrap.yml，并配置服务名称和Nacos地址(注：请将下面内容改成yml格式填入，这里是为了书写方便)

  server.port=7301                                                                            #项目端口号(boostrap.yml中配置后，可在application.yml中不配置)
  spring.application.name=nacos-config-client                               #应用名对应nacos配置中心的Data Id
  spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848           #指定nacos注册中心地址(boostrap.yml中配置后，可在application.yml中不配置)
  spring.cloud.nacos.config.prefix=${spring.application.name}      #不填写默认就是项目的应用名
  spring.cloud.nacos.config.server-addr=127.0.0.1:8848                #指定nacos配置中心地址
  spring.cloud.nacos.config.file-extension=yml                              #指定配置文件后缀名


  这里有两个坑：1. 配置文件必须是bootstrap.properties或者bootstrap.yml，如果配置application.properties或者application.yml会导致加载不到配置；
                          2. spring.cloud.nacos.config.namespace如果是默认的public，则不需填写，否则获取不到配置信息

  详情见：资料/nacos-config-client-bootstrap.yml

1. 创建NacosConfigController进行配置信息的读取
   @Value("${cnf.message}")
2. @RefreshScope实现自动刷新
   此注解主要用来让这个类下的配置内容支持动态刷新，也就是当我们的应用启动之后，修改了Nacos中的配置内容之后，这里也会马上生效

1. Nacos实现共享配置
   之前讲的都当前项目的私有配置，但一个真实项目中还会有许多的共享配置，比方说数据库、redis、log4j日志配置等，这些都可以放到nacos中，做到配置的共享加载与统一管理

   1.进入Nacos的控制页面，创建新的配置文件db.yml,hello.yml
   username=zs
   password=123

   hello=hello nacos

   2.修改bootstrap.yml添加如下配置
   spring.cloud.nacos.config.shared-dataids=db.yml,hello.yml
   spring.cloud.nacos.config.refreshable-dataids=db.yml,hello.yml
   注1：spring.cloud.nacos.config.shared-dataids参数用来配置多个共享配置的Data Id，多个的时候用用逗号分隔
   注2：spring.cloud.nacos.config.refreshable-dataids参数用来定义哪些共享配置的Data Id在配置变化时，应用中可以动态刷新，多个Data Id之间用逗号隔开。如果没有明确配置，默认情况下所有共享配置都不支持动态刷新
   注3：不能省略后缀名yml或properties

2. 多环境的配置管理
   本例使用了nacos的命名空间，来实现不同环境的切换，这也是nacos官方推荐的方式。还有其它两种方式，了解可参考附录四，详情请参考：资料/04,05,06

   1.进入Nacos的控制页面，创建新的命名空间dev/test/prd
   2.在配置列表的最上方，可以看到除了public之外，多了几个刚才创建的namepsace。分别在dev/test/prd空间下为nacos-config-client应用创建配置内容

   nacos-config-client.yml
   db.yml
   hello.yml

   3.修改bootstrap.yml添加如下配置

   spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a   #这里需要注意namespace的配置不是使用名称，而是使用Namespace的ID。
   
   注意事项：对于指定环境的配置

   （spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），

   都不要配置在应用的bootstrap.yml中。而是在发布脚本的启动命令中，
   用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活
   
   语法格式：java -jar xxx.jar --a1=aaa --b1=bbb
   java -jar nacos-config-client.jar --spring.cloud.nacos.config.namespace=d43d645d-0567-40f7-97d0-a39e2f0216b1
   

附录一：yml和properties文件区别
1.首先yml和properties文件都是属于配置文件，功能一样，使用哪种方式自己开心就好，建议使用yml，因为树状结构更加清晰，代码更少

附录二：application.yml和 bootstrap.yml区别
1.主要是application和bootstrap的加载顺序
bootstrap.yml在application.yml之前加载，用于应用程序上下文的引导阶段
注意：Spring Boot 配置文件的加载顺序，依次为 bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml ，其中 bootstrap.properties 配置为最高优先级

2.典型场景
1.当使用 Spring Cloud Config Server的时候，你应该在 bootstrap.yml里面指定spring.application.name和spring.cloud.nacos.config.server-addr
2.一些加密/解密的信息
3.属性覆盖问题
1.启动上下文时，Spring Cloud会创建一个Bootstrap Context，作为Spring应用的Application Context的父上下文。Bootstrap Context属性有高优先级，默认情况下，它们不会被本地配置覆盖。
2.初始化的时候，Bootstrap Context负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。
3.Bootstrap context和Application Context有着不同的约定，所以新增了一个bootstrap.yml文件，而不是使用application.yml (或者application.properties)。保证Bootstrap Context和Application Context配置的分离

附录三：Nacos共享配置的两种实现方式
shared-dataids方式：
适合于共享配置文件与项目默认配置文件处于相同Group时，直接两条命令就可以搞定
优点：配置方便
缺点：只能在同一Group中
ext-config方式：
它可以由开发者自定义要读取的共享配置文件的DataId、Group、refresh属性，这样刚好解决了shared-dataids存在的局限性。
优点：可以与shared-dataids方案结合使用，用户自定义配置。灵活性强
缺点：配置容易出错，要熟悉YAML语法

附录四：利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理
第一种：通过Data ID与profile实现。
优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现。
优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

第三种：通过Namespace实现。
优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活

附录四：
management.endpoints.web.exposure.include=*，默认只公开了/health和/info端点，要想暴露所有端点只需设置成星号即可