目录
一、前言
在微服务开发中，通常会涉及到配置的多环境问题，以springboot项目为例，在开发阶段使用的是开发环境的配置信息，比如连接的是开发环境数据库，使用的是开发环境redis，但到了测试阶段，需要使用测试环境的配置信息，最后发布到生产环境又需要重新整一套配置，不同环境的配置管理就为项目部署和实施过程中带来了一定的麻烦，针对这个问题，该如何解决呢，这就是本文将探讨的。
二、配置多环境问题概述
2.1 什么是微服务多环境配置管理
微服务多环境配置管理是指在微服务架构中，针对不同的环境（如开发、测试、生产等）管理和维护不同的配置信息的过程。这些配置信息包括但不限于数据库连接信息、日志级别、缓存设置、外部服务的终端点等。通过微服务多环境配置管理，可以使每个微服务在不同环境中具有灵活的配置，从而实现更好的灵活性、隔离性和可维护性。
2.1.1 微服务多环境配置管理问题起源
微服务多环境配置管理问题通常源自以下情况：
环境差异
不同环境（如开发、测试、生产）之间存在各种差异，包括数据库连接、API终端点、日志级别等，这导致需要针对不同环境进行配置管理。
人为错误
在多环境配置管理过程中，可能会出现人为错误，比如将开发环境的配置误用于生产环境，这可能导致系统故障或安全漏洞。
维护困难
随着微服务数量的增加，手动管理多个微服务在多个环境下的配置变得困难，容易导致配置不一致或遗漏。
部署流程不一致
由于多环境配置管理不规范，可能导致不同环境下的部署流程不一致，增加了部署过程中的不确定性和风险。
安全性和合规性
在多环境配置管理中，需要确保敏感信息（如数据库密码、API密钥等）的安全性和合规性，这增加了管理难度。
2.2 为什么要做多环境配置管理
多环境配置管理在微服务架构设计以及开发运维中非常重要，主要原因如下：
灵活性高
微服务架构通常由多个微服务组成，每个服务可能需要在不同环境（如开发、测试、生产）中运行。通过多环境配置管理，可以使每个服务在不同环境中具有灵活的配置，无需修改代码。
隔离性好
不同环境可能需要不同的配置，如数据库连接、日志级别、缓存设置等，通过多环境配置管理，可以避免将开发环境配置误用于生产环境，从而提高系统的隔离性和安全性。
部署流程标准化与规范化
多环境配置管理可以帮助简化部署流程，使部署过程更加标准化和自动化。开发人员和运维人员可以根据环境需求轻松地部署服务，减少人为错误的可能性。
便于测试
不同环境下的配置管理有助于更好地进行测试，包括单元测试、集成测试和端到端测试。通过在不同环境中测试服务，可以确保服务在各个阶段都能够正常运行。
2.3 微服务多环境配置管理解决方案
针对微服务多环境配置管理，通常可以采用以下解决方案：
环境变量管理
使用操作系统或容器提供的环境变量功能，通过在不同环境中设置不同的环境变量来实现微服务的配置管理。
配置文件管理
将不同环境的配置信息存储在独立的配置文件中，例如使用JSON、YAML或Properties格式。通过部署时选择相应的配置文件来加载不同环境的配置信息。在springboot，springcloud中通常采用这种方式来命名配置文件。
配置中心
使用专门的配置中心服务，如Spring Cloud Config、Consul、Zookeeper等，通过这些服务集中管理微服务的配置信息，根据环境动态加载配置。
自动化部署工具集成
结合自动化部署工具，如Jenkins、Ansible、Docker等，实现在不同环境中自动加载相应的配置信息，并确保微服务的正确部署和配置。
集成密钥管理
在多环境配置管理中，确保对敏感信息（如数据库密码、API密钥等）的安全管理。可以利用密钥管理服务（如AWS KMS、HashiCorp Vault等）来安全地存储和获取这些敏感信息。
三、springboot 配置多环境管理解决方案
3.1 前置准备
3.1.1 搭建一个springboot工程
引入如下核心依赖：
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.30</version>
</dependency>
</dependencies>3.1.2 添加配置文件
在默认的application.yml配置文件中添加如下配置信息
server:
port: 8088
app:
user:
name: springboot default3.1.3 添加测试接口
添加一个测试接口，读取上述配置文件的信息
@Value("${app.user.name}")
private String appUserName;
//localhost:8088/getConfig
@GetMapping("/getConfig")
public Object getConfig(){
System.out.println(appUserName);
return appUserName;
}测试一下接口
3.2 springboot 配置多环境管理方式一
Spring Profile是 SpringBoot 框架用于处理不同环境配置的解决方案。Spring Boot 为每个 Profile 提供了一个独立的 application.properties（或 application.yml）配置文件。当你激活一个特定 Profile 时，Spring Boot 会查找名为 application-{profile}.properties 的文件，{profile}是环境标识，并把其中的属性加载到 Spring Environment 中。
Profile 可以帮助我们在不改变应用代码的情况下，根据当前环境动态地激活或者切换不同的配置。默认情况下，Spring Boot 使用的是 application.properties 文件。
如下，在resources目录下再创建两个配置文件，分别命名为：application-dev.yaml和application-test.yaml
application-dev.yaml配置内容如下
server:
port: 8088
app:
user:
name: springboot devapplication-test.yaml配置内容如下
server:
port: 8088
app:
user:
name: springboot test然后再在application.yaml配置文件中，使用Spring Profile来区分使用上面的哪个配置文件
spring:
profiles:
active: dev启动工程后，再次访问接口，由于这里active中的配置是：dev，即使用dev的那个配置文件中的配置信息，和预期的结果一致。
3.2.1 使用idea启动参数控制
在idea中启动时，通过设置vm启动参数的变量来控制使用哪个配置文件
#vm启动设置：
-Dspring.profiles.active=test
#Program设置
--spring.profiles.active=test
在保持上面的配置文件情况下，重新启动工程，浏览器再次访问一下，可以看到本次读取的是test配置文件中的信息
3.2.2 jar包启动使用参数控制
打成jar包之后，也可以通过在启动命令中添加参数的形式控制使用哪个配置文件
java -jar -Dspring.profiles.active=test boot-mi-1.0-SNAPSHOT.jar
再次访问，看到如下效果
3.2.3 在pom中统一管理profiles
这是一种在打包时候指定使用哪个环境的配置文件的方式，在公共pom中添加如下配置，最外层为profiles标签，里面可以添加多个profile标签，每个profile标签包裹的内容即为不同环境下的配置引用，activeByDefault标签熟悉为默认开启的环境。
<profiles>
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
</properties>
</profile>
</profiles>application.yaml配置文件中，做如下修改，active后的参数使用上述pom中的参数
spring:
profiles:
active: @spring.profiles.active@然后在打包阶段，具体指定使用开启哪个环境的配置，命令如下：
#使用test环境的配置文件
mvn clean package -Ptest
#使用dev环境的配置文件
mvn clean package -Pdev
打完包之后，再次启动测试，通过这种方式，也能切换为test环境下的配置信息
补充说明
pom中使用了profiles标签管理之后，在idea中打包阶段，能够看到在右侧会出现dev和test的勾选框，通过这里进行勾选打包也可以达到相同的效果
四、Nacos 配置多环境管理解决方案
在使用了微服务治理框架之后，配置的多环境管理问题就更加突出了，主要是微服务的模块更多，彼此之间存在互相依赖，互相调用，一旦控制不好，不仅未能快速的定位和解决问题，反而会在配置管理的事情上消耗很多时间精力。而引入了配置中心之后，通过配置中心对配置信息的统一管理，可以很好的做到按环境隔离配置文件的目的。下面以大家熟知的Nacos为例，详细说说如何基于Nacos 解决配置的多环境管理问题。
4.1 Namespace 概述
4.1.1 Namespace 介绍
Nacos的Namespace（命名空间）是用来实现配置和服务的逻辑隔离的功能。通过命名空间，可以将不同的配置和服务实例划分到不同的逻辑空间中，以实现隔离和管理。命名空间在多租户场景下非常有用，可以让不同的租户或团队在同一个Nacos集群中独立地管理它们的配置和服务注册。
4.1.2 Namespace 作用
具体来说，Nacos的Namespace可以实现以下作用：
隔离配置和服务
不同的Namespace下的配置和服务相互隔离，不会相互干扰。这样可以确保不同的团队或租户在使用Nacos时能够独立管理它们的资源。
权限控制
通过Namespace可以实现针对不同租户或团队的权限控制，可以限制对特定Namespace下的配置和服务的访问权限，保障安全性。
资源管理
命名空间可以让不同团队或租户对自己的资源进行独立管理，包括配置的发布和服务的注册，有利于资源的精细化管理。
接下来通过两个实际的案例说明下如何基于Namespace管理多环境的配置信息，参考如下操作步骤。
4.2 通过Namespace(命名空间)管理多环境配置
4.2.1 创建几个Namespace
如下，为演示使用，创建多个Namespace
4.2.2 在public和dev空间下创建配置文件
分别在public和dev命名空间下创建一个相同的配置文件，配置内容稍作区分
public下配置内容：
test配置内容：
4.2.3 工程配置文件中引用public命名空间
在springcloud的工程配置文件中，config下引用的配置空间使用public的ID，如下：
server:
port: 8081
spring:
application:
name: producer-server
profiles:
active: test
cloud:
nacos:
server-addr: nacos地址:8848
#非必须，如果不填，将使用 public
discovery:
group: DEFAULT_GROUP
namespace: public
server-addr: nacos地址:8848
config:
namespace: public
group: DEFAULT_GROUP
server-addr: nacos地址:8848
#----- 引用的nacos配置文件 ----- 这个时候会去拼接dataid的完整信息
prefix: app-user
file-extension: yaml4.2.4 添加测试接口
工程中添加一个测试接口，用于读取nacos的public中添加的配置文件中的配置信息
@Value("${app.user.name}")
private String appUserName;
//localhost:8081/getConfig
@GetMapping("/getConfig")
public String getConfig(){
System.out.println(appUserName);
return appUserName;
}启动工程后，测试接口，可以看到能够从指定的public命名空间中拉取到配置信息
4.2.5 切换配置文件到test命令空间
将下面的配置文件中namespace改为test的ID
再次启动工程访问，可以看到本次访问的就是test空间的下配置内容
4.3 Group概述
4.3.1 Nacos Group介绍
在Nacos中，Group是用来对服务实例或配置项进行逻辑分组的功能。通过Group，用户可以将服务实例或配置项进行分类，以便更好地组织和管理这些资源。Group的引入可以帮助用户在服务发现、路由控制和配置管理等方面更加灵活地进行管理和操作。
在服务注册与发现中，可以针对不同的Group实施路由规则的定义和管理，以实现更灵活的服务调用控制。此外，针对不同的Group还可以实施不同的权限控制，确保在多团队或多租户的场景下，资源得到适当的访问控制。
在配置管理中，同样可以使用Group进行不同版本配置的管理和区分，便于进行灰度发布或版本回滚等操作。通过Group的引入，Nacos可以支持更加细粒度和灵活的资源管理和控制。
4.3.2 Nacos Group作用
Nacos中的Group（分组）具有以下作用：
逻辑分类
通过Group可以将不同的服务实例或配置项进行逻辑分类，从而更好地组织和管理这些资源。
路由规则
在服务注册与发现中，可以根据Group对服务进行路由规则的定义和管理，以实现更灵活的服务调用控制。
权限控制
可以针对不同的Group实施不同的权限控制，确保在多团队或多租户的场景下，资源得到适当的访问控制。
版本管理
在配置管理中，可以使用Group进行不同版本配置的管理和区分，便于进行灰度发布或版本回滚。
4.4 通过Group(分组)管理多环境配置
4.4.1 创建配置文件
Group是针对某个具体的Namespace来说的，即在同一个Namespace下，相同的配置文件，可以通过不同的Group分组来进行区分，如下，我们在public 空间下创建两个相同的配置文件，分别归在不同的group下面。
第一个分组为：DEV_GROUP
第二个分组为：TEST_GROUP
4.4.2 修改配置文件
配置文件中，配置连接nacos的group使用DEV_GROUP，同时prefix那里，注意更换为nacos里面的那个app-data配置文件
server:
port: 8081
spring:
application:
name: producer-server
profiles:
active: test
cloud:
nacos:
server-addr: IP:8848
#服务发现
discovery:
group: DEFAULT_GROUP
namespace: public
server-addr: IP:8848
config:
namespace: public
group: DEV_GROUP
server-addr: IP:8848
#----- 引用的nacos配置文件 ----- 这个时候会去拼接dataid的完整信息
prefix: app-data
file-extension: yaml4.4.3 增加测试接口
添加如下测试接口
@Value("${app.group.url}")
private String appGroupUrl;
//localhost:8081/getConfigGroup
@GetMapping("/getConfigGroup")
public String getConfigGroup(){
System.out.println(appGroupUrl);
return appGroupUrl;
}启动工程之后测试一下接口，可以看到读取的是DEV_GROUP下配置文件的内容
再将连接的分组信息切换为TEST_GROUP
再次启动工程进行测试
4.5 使用profiles管理多环境配置文件
这里的profiles与上述springboot中提到的有相似的地方，但是与springboot中不同的是，在springcloud-alibaba配置文件中，对于这个配置项的启用有自己的一套规则，具体来说如下：
托管到nacos-server上面的配置都有一个唯一的key，这个唯一key的确定标准为：namespace/group/dataId，有点类似于maven中确定一个jar包的坐标定位，如何在应用程序中读取配置的dataId呢？nacos的SDK中根据dataId去nacos server获取一个配置文件内容，而dataId的组成格式如下：
${prefix}-${spring.profiles.active}.${file-extension}
参数说明：
prefix，默认为spring.application.name，也可以通过配置项：spring.cloud.nacos.config.prefix来手动指定，比如在上面的演示中使用的就是自定义配置文件名称的格式；
springles.active，即为当前环境对应的profile；
注意：当spring.profiles.active为空的时候，对应的连接符 - 也不存在了，dataId的拼接格式将退化为：${prefix}.${file-extension}，比如上面案例中，最后读取的nacos配置文件为： app-data.yaml；
file-extension，为配置内容的数据格式，通过配置项：spring.cloud.nacos.config.file-extension来指定，目前支持的格式主要是两种，yaml和properties；
下面结合实际案例来演示下这种方式的使用。
4.5.1 nacos添加两个配置文件
在public命名空间下增加两个配置文件，名称分别为：app-data-test.yaml和app-data-dev.yaml，配置内容分别如下：
app-data-test.yaml
app-data-dev.yaml
4.5.2 修改工程配置文件
修改工程中连接配置文件的信息，其他地方暂时不动，主要是下面这里，改为test；
通过上面对于应用读取nacos上面配置文件的格式可以知道，这种方式下，读取的nacos配置文件完整名称为：app-data-test.yaml；
4.5.3 添加测试接口
增加下面的测试接口，读取上面的配置信息
@Value("${app.data.test}")
private String appDataTest;
//localhost:8081/getAppDataTest
@GetMapping("/getAppDataTest")
public String getAppDataTest(){
System.out.println(appDataTest);
return appDataTest;
}启动工程进行测试，此时读取到的是app-data-test.yaml中添加的配置内容
profiles.active 切换为dev，然后重新启动工程再次测试，此时读取到的是app-data-dev.yaml中添加的配置内容
五、写在文末
本文通过实际案例详细介绍了springboot配置多环境管理的使用，以及基于nacos的配置多环境管理的实践，在实际开发中，配置多环境管理是一个很难避开的问题，同时也是微服务治理中一个很重要的内容，值得深入探究，本文到此结束，感谢观看。
