使用环境变量，让Spring Boot应用部署更加灵活

Spring Boot可以说是目前最火的开发框架了，几乎所有新的企业应用都会优先考虑使用Spring Boot，甚至一些之前老的应用系统也会改造为Spring Boot构建。其约定优于配置的特性使开发工作变得简单，大大节省了开发工作量和成本。Java也是因为拥有和Spring Boot一样优秀的众多开源框架，才能一直在编程语言排行榜前几名。

一个应用程序，不可避免的要使用各种配置文件，比如配置应用名称，应用版本，应用服务端口等。Spring Boot本身提供了多种配置方式，你可以把配置写在application.yml中，通常我们会使用spring.profiles.active来进行配置分离，实现应用在不同环境下使用不同的配置参数。但是这样有一个问题，就是这些配置必须都提前配置好，比如dev环境使用什么参数、prod环境使用什么参数，这些配置都被打包进了我们的应用。而当我们需要改变某个配置是则需要重新打包发布，这是非常麻烦的，尤其是当我们使用云平台、自动化部署、容器等服务时，重新打包会造成不必要的浪费，毕竟我们只是修改了一个配置而已，并且大多数企业对于这种重新打包发布很敏感，你很难在生产环境实现重新部署（各种审核流程）。

Spring Boot可以读取环境变量（宿主机，运行容器等），在云平台越来越流行的今天，我们的服务通常不是运行在一个真实的物理机上面的。使用这些容器平台很容配置我们想要的环境变量，把我们的配置暴露给环境变量，可以方便我们的应用部署和参数调整。

比如，我需要配置应用连接数据库的配置，通常我们在application.yml或者使用指定环境的application-prod.yml配置文件，写入以下配置：

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1/demo?serverTimezone=Asia/Shanghai
    username: demo
    password: demo
    hikari:
      maximum-pool-size: 30
      max-lifetime: 60000
      minimum-idle: 5

像上面那样，如果这时如果我们的数据库的用户密码变了或者我们想调整一个连接池的相关配置，一般来讲我们需要修改以上配置文件，然后重新打包发布（或者你说可以在压缩包内修改配置文件？？），这种方式真是太糟糕了。

现在看看如果我们使用环境变量的方式来配置我们的参数，如下：

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: ${DEMO_APP_JDBC_URL:jdbc:mysql://127.0.0.1/demo?serverTimezone=Asia/Shanghai}
    username: ${DEMO_APP_JDBC_USERNAME:demo}
    password: ${DEMO_APP_JDBC_PASSWORD:demo}
    hikari:
      maximum-pool-size: ${DEMO_APP_JDBC_POOL_MAX_SIZE:30}
      max-lifetime: ${DEMO_APP_JDBC_POOL_MAX_LIFE_TIME:60000}
      minimum-idle: ${DEMO_APP_JDBC_POOL_MIN_SIZE:5}

以上使用${ENV:defauleValue}的形式配置了我们应用的相关参数，如果我们的运行环境配置了上面用到的环境变量，则使用环境变量中的配置，如果没有配置则使用默认的，比如我配置了环境变量DEMO_APP_JDBC_POOL_MAX_SIZE = 100，则应用程序中的连接池最大连接数就变成100了。使用这种方式我们甚至没必要使用spring.profiles.active来指定不同的配置文件了，简直一举两得。

注意：以上方式通常适用于云、容器等应用环境的部署，因为运行环境是被我们的应用独享的。我想你不愿意在一个运行着多个应用服务的环境上面配置这么多个性化的环境变量。