一般我們會將SpringBoot應用需要的配置內容放在項目工程中,然后通過spring.profiles.active或是通過Maven來實現多環境的支持.但是,當團隊逐漸壯大,分工越來越細之后,往往不需要讓開發人員知道測試或生產環境的細節,而是希望由每個環境各自的負責人(QA或運維)來集中維護這些信息,那么如果還是以則海洋的方式存儲配置內容,對於不同環境配置的修改就不得不去獲取工程內容來修改這些配置內容,當應用非常多的時候就變得非常不方便.同時,配置內容對開發人員都可見,這本身也是一種安全隱患.對此,出現了很多將配置內容外部化的框架和工具,Spring Cloud Config就是其中之一.為了能夠更合理的重寫各個屬性的值,SpringBoot使用下面的順序來加載配置:
1.在命令行中傳入的參數; 2.SPRING_APPLICATION_JSON 中的屬性。SPRING_APPLICATION_JSON 是以JSON 格式配置在系統環境變量中的內容； 3.java:comp/env 中的 JNDI 屬性; 4.java 的系統屬性，可以通過System.getProperties()獲得的內容; 5.操作系統的環境變量。 6.通過random.*配置的隨機屬性； 7.位於當前應用jar包之外，針對不同{profile}環境的配置文件內容，例如 applicaiton-{profile}.properties 或是 yaml 定義的配置文件； 8.位於當前應用jar包之內，針對不同{profile}環境的配置文件內容，例如 applicaiton-{profile}.properites 或是 yaml 定義的配置文件； 9.位於當前應用jar包之外的 application.properties 和yaml配置內容； 10.位於當前應用jar包之內的 application.properties 和yaml配置內容； 11.在@Configration注解修改的類中，通過@PropertySource注解定義的屬性； 12.應用默認屬性，使用SpringApplication.setDefaultProperties定義的內容；
優先級按照上面的順序由高到低，數字越小優先級越高。
可以看到，第7項到第9項都是從應用jar包之外讀取配置文件，所以，實現外部化配置的原理就是從此切入，為其指定外部配置文件的加載位置來取代jar包之內的配置內容。通過這樣的實現，我們的工程在配置中就變得非常干凈，只需在本地放置開發需要的配置即可，而不需要其他環境的配置，由其對應環境的負責人去維護即可。