## 一、不同环境的配置文件隔离 1. Nacos地址和命名空间 * 直接通过运行参数设置：例如开发环境的nacos地址为127.0.0.1:8848，而生产环境的nacos地址为10.80.98.110，部署生产环境时只需要在项目的启动参数添加以下内容 ~~~ //以下参数是本项目个性化的，能同时影响配置中心和注册中心的地址 -Dpigframe.nacos.server-addr=10.80.98.110:8848 -Dpigframe.nacos.namespace=701cead9-85b6-4818-b411-130eef6d4336 ~~~ 2. 业务配置项 总共有3种方法实现(选择一种即可) 2.1. 通过spring.profiles.active ~~~ //通过运行参数设置 -Dspring.profiles.active=dev ~~~ 2.2. 通过Nacos 的 Group ~~~ //通过运行参数设置 -Dspring.cloud.nacos.config.group=DEVELOP_GROUP ~~~ 2.3. 通过Nacos 的 Namespace ~~~ //通过运行参数设置，值是namespace对应的id，id值可以在Nacos的控制台获取 -Dspring.cloud.nacos.config.namespace=701cead9-85b6-4818-b411-130eef6d4336 ~~~ ## 二、多环境总结 **第一种**：通过`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`也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。 * 缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。 * 建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？ >[warning] 多环境注意：不论用哪一种方式实现。对于指定环境的配置（`spring.profiles.active=DEV`、`spring.cloud.nacos.config.group=DEV_GROUP`、`spring.cloud.nacos.config.namespace=701cead9-85b6-4818-b411-130eef6d4336`），都不要配置在应用的`bootstrap.properties`中。而是在发布脚本的启动命令中，用`-Dspring.profiles.active=DEV`的方式来动态指定，会更加灵活！。 >[danger] Nacos使用注意 > > * Nacos本身的相关配置必须都放在`bootstrap.yml`文件中 > * 如果在Nacos添加了应用的配置文件 > 1.**应用读取配置后只会覆盖本地相同key的配置** > 2.**应用读取配置后会缓存起来，就算停掉Nacos也会生效**