多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
# :-: Nacos配置中心 ## 4\. 配置中心 ### 4.1. 集成项目 * 引入jar ~~~ <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> ~~~ * `bootstrap.yml`增加以下配置 ~~~ spring: cloud: nacos: config: server-addr: ip:prot #nacos的地址 file-extension: yml #配置文件格式 shared-dataids: common.yml #公共配置文件 ~~~ ### 4.2. 核心功能介绍 #### 4.2.1. 全局共用配置 * 可通过以下方式配置所有项目共享的配置项 ~~~ spring: cloud: nacos: config: shared-dataids: common.yml refreshable-dataids: common.yml ~~~ > shared-dataids 配置全局的配置名称refreshable-dataids 配置需要自动刷新的全局配置(默认不支持自动刷新) #### 4.2.2. 自动刷新 ~~~ //配置类上添加RefreshScope注解 @RefreshScope ~~~ #### 4.2.3. 不同环境的配置文件隔离 1. Nacos本身的地址 * 直接通过运行参数设置 * 例如开发环境的nacos地址为127.0.0.1:8848,而生产环境的nacos地址为192.168.28.130,部署生产环境时只需要在项目的启动参数添加以下内容 2. ~~~ //以下参数是本项目个性化的,能同时影响配置中心和注册中心的地址 -Dzlt.nacos.server-addr=192.168.28.130:8848 ~~~ 3. 业务配置项总共有3种方法实现(选择一种即可) 1. 通过spring.profiles.active 4. ~~~ //通过运行参数设置 -Dspring.profiles.active=dev ~~~ ![](https://www.kancloud.cn/book/zlt2000/microservices-platform/preview/images/profile.png)2\. 通过Nacos 的 Group ~~~ //通过运行参数设置 -Dspring.cloud.nacos.config.group=DEVELOP_GROUP ~~~ ![](https://www.kancloud.cn/book/zlt2000/microservices-platform/preview/images/group.png)3\. 通过Nacos 的 Namespace ~~~ //通过运行参数设置,值是namespace对应的id,id值可以在Nacos的控制台获取 -Dspring.cloud.nacos.config.namespace=b3404bc0-d7dc-4855-b519-570ed34b62d7 ~~~ ![](https://www.kancloud.cn/book/zlt2000/microservices-platform/preview/images/screenshot_1548997069007.png) ##### 4.2.3.1. 多环境总结 **第一种**:通过`DataID`与`profile`实现。 * 优点:这种方式与Spring Cloud Config的实现非常像,用过Spring Cloud Config的用户,可以毫无违和感的过渡过来,由于命名规则类似,所以要从Spring Cloud Config中做迁移也非常简单。 * 缺点:这种方式在项目与环境多的时候,配置内容就会显得非常混乱。配置列表中会看到各种不同应用,不同环境的配置交织在一起,非常不利于管理。 * 建议:项目不多时使用,或者可以结合 `Group`对项目根据业务或者组织架构做一些拆分规划。 **第二种**:通过`Group`实现。 * 优点:通过 `Group`按环境讲各个应用的配置隔离开。可以非常方便的利用 `DataID`和 `Group`的搜索功能,分别从应用纬度和环境纬度来查看配置。 * 缺点:由于会占用 `Group`纬度,所以需要对 `Group`的使用做好规划,毕竟与业务上的一些配置分组起冲突等问题。 * 建议:这种方式虽然结构上比上一种更好一些,但是依然可能会有一些混乱,主要是在 `Group`的管理上要做好规划和控制。 **第三种**:通过`Namespace`实现。 * 优点:官方建议的方式,通过 `Namespace`来区分不同的环境,释放了 `Group`的自由度,这样可以让 `Group`的使用专注于做业务层面的分组管理。同时,Nacos控制页面上对于 `Namespace`也做了分组展示,不需要搜索,就可以隔离开不同的环境配置,非常易用。 * 缺点:没有啥缺点,可能就是多引入一个概念,需要用户去理解吧。 * 建议:直接用这种方式长远上来说会比较省心。虽然可能对小团队而言,项目不多,第一第二方式也够了,但是万一后面做大了呢? >[success] 多环境注意:不论用哪一种方式实现。对于指定环境的配置(`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`的方式来动态指定,会更加灵活!。 >[danger] Nacos使用注意 > * Nacos本身的相关配置必须都放在`bootstrap.yml`文件中 > * 如果在Nacos添加了应用的配置文件1. **应用读取配置后只会覆盖本地相同key的配置**2\. **应用读取配置后会缓存起来,就算停掉Nacos也会生效**