--spring.profiles.active 穿透性

今天在帮助 datamaster 接入配置中心时发现一个问题，就是如果在应用的 application.yml 像这样：

spring:
  application:
    name: datamaster-scheduler
  profiles:
    active: lc10

指定环境的话，在启动时会自动寻找 datamaster-scheduler-lc10.yml 这个配置文件，不论使用 bootrun 启动或者打成 jar 包都没有问题。

但是如果不在 application.yml 中指定 spring.profiles.active，而是打成 jar 包，使用 --spring.profiles.active=lc10 参数启动的话，就注册不上 Eureka，所以也就没办法正常拉取配置文件了。

出现这个问题可以理解，因为我们在封装微服务接入的 starter 时，只定义了两个 active：

---
spring:
  profiles: dev
  rabbitmq:
    host: 172.24.8.100
    port: 5672
    username: admin
    password: admin
  zipkin:
    base-url: http://172.24.8.100:7030

eureka:
  client:
    service-url:
      defaultZone: http://172.24.8.100:7011/eureka/,http://172.24.8.100:7012/eureka/,http://172.24.8.100:7013/eureka/

---
spring:
  profiles: beta
  rabbitmq:
    host: 172.24.8.100
    port: 5672
    username: admin
    password: admin
  zipkin:
    base-url: http://172.24.8.100:7030
eureka:
  client:
    service-url:
      defaultZone: http://172.24.8.100:7011/eureka/,http://172.24.8.100:7012/eureka/,http://172.24.8.100:7013/eureka/

所以使用这两种之外的环境是找不到配置中心的地址的，但是之前那种方式所得到的行为就不太理解了。

这个问题我得到的结论是这样的：在应用系统的 application.yml 中定义的 active 是不具有穿透性的，所以我们的 微服务 starter 是不会得到这里定义的 active 的，而且 微服务starter 中的 bootstrap.yml 中定义了：

spring:
  profiles:
    active: dev

所以在没有指定时会使用 dev，没有任何问题。

使用 --spring.profiles.active=lc10 指定的 active 具有穿透性，会让这个应用系统依赖的其他组件也使用指定的 active，所以这个时候 微服务 starter 也会切换到 lc10 的 active，因为我们没有在 starter 中配 lc10 对应的 active，也就就相当于没有指定 eureka 的注册地址，所以接下来的所有流程就都跑不通了。

为了解决这个问题，我在 微服务 starter 的 bootstrap.yml 中加上了默认的 eureka 注册地址和其他需要用到的配置，这样即便是指定的环境不存在的话也没有任何问题。

之后在为客户部署时，只需要在 微服务 starter 中增加一个客户所对应的环境，然后启动应用时指定客户的 active 就可以了。