22、springboot的Profile（通过yml配置文件配置 profile，快速切换项目的开发环境）

springboot的Profile

★ 何谓Profile

 应用所在的运行环境发生切换时，配置文件常常就需要随之修改。

 Profile：——就是一组配置文件及组件的集合。

 可以整个应用在不同的profile之间切换（设置活动profile），整个应用都将使用该profile对应的配置文件及组件。

 ——每个运行环境（开发、测试、上线）都配置成一个对应profile，这样以后只要修改一下活动profile，
 应用就可以轻易地在不同的运行环境之间自由切换。

就是通过 配置的 profile 快速切换开发环境。

▲ 1. 声明Profile

  - @Profile修饰Spring组件（@Component、@Configuration、@ConfigurationProperties)，
    意味着该组件仅对特定profile有效。

  - 在配置文件中添加profile名，意味着该配置文件仅对特定profile生效。

  - 多profile的配置文件。

▲ 2. 设置活动Profile

    spring.profiles.active属性指定激活哪个Profile
    ——该属性可通过任意的外部配置源来指定。

★ 通用配置文件 和 Profile特定的配置文件 的区别

通用配置文件：  application.properties或者application.yml

profile相关：   application-{profile名}.properties或者application-{profile名}.yml

profile相关的配置文件的优先级更高（后加载，后加载的会覆盖前面加载的）

就是我们要弄一个叫 abc.profile 的配置文件，那么就可以这样写 application-abc.properties/yml
(中划线 -  加上 profile 名字)

代码演示：

演示如何通过profile配置文件，来快速切换开发环境。
步骤：
1、
添加一个正式环境用的yml----application-dev.yml，写对应的正式环境配置
添加一个测试环境用的yml----application-test.yml，写对应的测试环境配置
一个原本有的通用的application.yml—用来切换开发环境和测试环境

演示通过 application.yml 配置文件中，通过指定对应的 profile 名字，来切换开发环境

演示 用 java 类来查看
类用 @Profile 注解 来修饰
@Profile(“dev”) //注解作用：表示这个控制器仅对dev作为活动profile时才生效（就是把开发环境切换成 dev ，这个控制器才生效）

application.yml配置文件中使用 spring.profiles.active 属性，用于切换活动profile，意味着最终最多时能有一个活动profile，就是最终只能有一个开发环境，要么正式，要么测试，要么其他，只能有一个开发环境。

但是如果在application.yml 配置文件中，使用 spring.profiles.include属性 用于添加活动profile，意味着最终可能有多个活动profile，目前来看是多个profile修饰的controller生效。
一开始我以为是多个开发环境生效，比如正式环境和测试环境都生效，后面发现是覆盖的关系，看起来还是只有一个开发环境
新增的活动profile -> add 和 原来的活动profile -> dev ，其实它们会覆盖，但是具体谁覆盖谁，是不确定的。
下面演示添加活动profile

★ 添加活动Profile

▲ spring.profiles.include - 添加新的活动profile

          原有的，继续生效。
          没有的，新增。
          相同的，覆盖——Spring Boot并不确定使用新增profile覆盖原有的profile

▲ 调用SpringApplication的setAdditionalProfiles()来添加新的活动Profile

通过添加活动Profile，实际上就相当于让应用有了多个活动Profile。


【备注】：
          spring.profiles.active属性用于切换活动profile，意味着最终最多时能有一个活动profile
          spring.profiles.include属性用于添加活动profile，意味着最终可能有多个活动profile

如果在application.yml 配置文件中，使用 spring.profiles.include属性 用于添加活动profile，意味着最终可能有多个活动profile，目前来看是多个profile修饰的controller生效。
一开始我以为是多个开发环境生效，比如正式环境和测试环境都生效，后面发现是覆盖的关系，看起来还是只有一个开发环境

新增的活动profile -> add 和 原来的活动profile -> dev ，其实它们会覆盖，但是具体谁覆盖谁，是不确定的。

代码示例：
添加一个活动profile

2、使用这个新添加的活动profile，有两种方式：
方式1：在启动类添加，用 ctx.setAdditionalProfiles(“add”); 方法

方式2：在 application.yml 配置文件中添加，用 spring.profiles.include 属性

执行结果
application.yml 配置文件启动的profile 有 dev 和 add 两个开发环境，启动后使用的端口号是 add 的 8085

访问结果测试：

可以看出 当 application.yml 指定了 dev 和 add 两个开发环境后，只有 dev 和 add 两个controller 生效（生效：能访问到对应的被profile注解修饰的controller的方法），
但是开发环境是 add 覆盖了 dev 。
而test 开发环境 和 controller 都没生效。

★ Profile组

Profile组可以让一个应用里面有多个profile

Profile组也是一个Profile，但该Profile可包含另外几个Profile。例如：

spring.profiles.group.prod[0]=banner
spring.profiles.group.prod[1]=server

上面定义了一个Profile组：prod，该组包含banner和server两个Profile。


因此如果将上面prod设为活动Profile，那就意味着项目中有3个活动profile，依次是prod、banner、server

——通过使用这种方式，可以让项目设置多个活动Profile。

▲ Profile组及其成员的加载顺序：

先加载Profile组对应的资源（比如先加载prod）
然后按顺序加载各组成员Profile对应的资源（比如再加载banner、server）。
后加载的能覆盖先加载的。

——Profile组 对应的资源，总会被组成员对应的资源所覆盖。

【备注：】通过使用Profile组，可以设置多个活动profile，且它们的覆盖顺序是相当稳定的。
先加载组，然后再加载组里面的成员，后加载的会覆盖前面的。

代码演示：

需求：演示 profile 组 和 其成员的加载顺序。

1、先在application.yml 中设置一个profile组，叫gp，
然后创建一个 profile 叫 application-gp.yml
【spring.profiles.active属性用于切换活动profile，意味着最终最多时能有一个活动profile】

如图：可以看出用 active ，表示切换到 gp 这个profile ，所以最先加载的就是这个 gp profile，
然后再加载 gp 这个组里面的成员，加载顺序可以看成是按我们写的顺序从上往下，如图中，先加载 dev 这个 profile ，然后再加载 test 这个 profile。
加载顺序为：gp – dev – test
因为后加载的profile 会覆盖 先加载的profile，所以最终执行的 profile 就是 test 这个

访问各个profile的方法，验证加载顺序

可以看出来：
1、启动程序后，访问的端口是8084，因为test这个profile配置文件的端口就是8084，说明test是最后加载的，覆盖了前面的几个profile。
2、然后访问每个 profile 的控制器的方法，发现 gp、dev、test 都能访问成功，只有add这个profile访问失败，因为从上面的 application.yml 配置文件可以看出只配置了 gp、dev、test 这三个profile。而add这个没有配置，肯定访问失败
3、可以看出无论是访问 gp这个profile组，还是访问 dev、test 这两个活动profile，返回的结果都是 test 这个profile 的数据。说明因为配置了 gp、dev、test 这三个profile，所以表示gp、dev、test这三个控制器都生效，就是这三个开发环境都生效了。
但是因为test最后加载，把前面的gp和dev都覆盖了，所以最终的开发环境就是以test这个profile为主。

★ 混合复合类型

混合复合类型，其实就是多个profile的覆盖规则。

1. 若可从多个配置文件中加载List类型的属性时，后加载的List集合总是完全替换之前加载List集合。
   比如从第一个配置文件中加载的List集合包含2个元素，接着从第二个配置文件中加载的List集合包含1个元素，那么这个List集合属性最终就只有一个元素。


2. 若可从多个配置文件中加载Map类型的属性时，后加载的Map的key-value对将会添加到之前加载Map中。
   比如先从第一个配置文件中加载的Map包含2个key-value对，接着从第二个配置文件中加载的Map集合包含1个key-value对、且该key-value与之前的两个key-value对不冲突，那么这个Map属性最终会包含3个key-value对。

【归纳】： List集合是完全覆盖，Map集合则是元素添加。

代码演示：
需求：演示 profile 里面的 list （覆盖）和 Map （添加）

定义这个属性处理类，作用是：拿对应的yml配置文件中的值

这个是控制器中的方法，通过访问，能更直观的看到数据

测试结果： List集合是完全覆盖，Map集合则是元素添加。