【微服务】springcloud-alibaba 配置多环境管理使用详解

一、前言

二、配置多环境问题概述

2.1 什么是微服务多环境配置管理

2.1.1 微服务多环境配置管理问题起源

2.2 为什么要做多环境配置管理

2.3 微服务多环境配置管理解决方案

三、springboot 配置多环境管理解决方案

3.1 前置准备

3.1.1 搭建一个springboot工程

3.1.2 添加配置文件

3.1.3 添加测试接口

3.2 springboot 配置多环境管理方式一

3.2.1 使用idea启动参数控制

3.2.2 jar包启动使用参数控制

3.2.3 在pom中统一管理profiles

四、Nacos 配置多环境管理解决方案

4.1 Namespace 概述

4.1.1 Namespace 介绍

4.1.2 Namespace 作用

4.2 通过Namespace(命名空间)管理多环境配置

4.2.1 创建几个Namespace

4.2.2 在public和dev空间下创建配置文件

4.2.3 工程配置文件中引用public命名空间

4.2.4 添加测试接口

4.2.5 切换配置文件到test命令空间

4.3 Group概述

4.3.1 Nacos Group介绍

4.3.2 Nacos Group作用

4.4 通过Group(分组)管理多环境配置

4.4.1 创建配置文件

4.4.2 修改配置文件

4.4.3 增加测试接口

4.5 使用profiles管理多环境配置文件

4.5.1 nacos添加两个配置文件

4.5.2 修改工程配置文件

4.5.3 添加测试接口

五、写在文末

一、前言

在微服务开发中，通常会涉及到配置的多环境问题，以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 default

3.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 dev

application-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: yaml

4.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: yaml

4.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中添加的配置内容