針對這個問題我提幾種方案，因為不同的專案的背景不同，也別上來就上統一配置中心，還是針對實際情況，選擇不同的方案。
正常情況，我們的程式碼基線會有多條，比如最簡單的開發基線和生產基線，開發人員在開發基線上進行程式碼開發，配置檔案中的內容對應的是開發環境；同理，生產基線中的配置檔案對應的是生產環境；
可以看出來，不同基線，程式碼是一致的（或者說會最終一致），但是配置檔案是不同的；如果配置檔案需要修改的話，就不能透過merge的方式進行程式碼合併了。
我們現在的專案都是基於Spring Boot，不同的配置檔案，比如資料來源的配置、遠端介面地址、日誌列印等，Spring Boot是支援透過不同的profile來配置不同環境的配置。大概的配置就是：
根據不同的環境，設定不同的yml檔案，命名：application-xxx.yml
設定spring.profiles.active的值，可以在打包的時候指定。
多個基線的程式碼可以是完全一樣。
這個拿一個實際專案舉例，是我們專案的做法，實現思路可能會有些怪異。我簡單說一下：
程式有兩個定時任務，分別是：job1和job2；
job1中的程式碼：if(job1run==true){邏輯處理}，job2類似；job1run和job2run預設false；
專案正常打包，不需要做額外處理，得到：project.jar
機器1執行：java -jar project.jar --job1run=true
機器2執行：java -jar project.jar --job2run=true
過程有些怪異，可以實現同一個程式碼包，再執行的時候指定它做什麼工作。
其實我是不排斥這種做法的，但是要注意：
有可能會發生變化的配置，放在資料庫中；
懶載入的方式讀取到記憶體中，不要每次使用的時候讀一次資料庫；
根據實際場景，決定載入到記憶體中的配置是否需要定時失效/過載。
隨著專案功能的增多：配置會越來越多，修改配置後實時生效的要求也會越來越高，所以很多公司會採用搭建【統一配置中心】的方式來解決這個問題。
配置中心的核心功能就是【配置】，但肯定不侷限於此，另外還需要有：審批、灰度釋出、回滾等功能；
常用的開源配置中心有：spring-cloud-config、Apollo、Nacos;
針對這個問題我提幾種方案，因為不同的專案的背景不同，也別上來就上統一配置中心，還是針對實際情況，選擇不同的方案。
不同程式碼基線，使用不同配置檔案正常情況，我們的程式碼基線會有多條，比如最簡單的開發基線和生產基線，開發人員在開發基線上進行程式碼開發，配置檔案中的內容對應的是開發環境；同理，生產基線中的配置檔案對應的是生產環境；
可以看出來，不同基線，程式碼是一致的（或者說會最終一致），但是配置檔案是不同的；如果配置檔案需要修改的話，就不能透過merge的方式進行程式碼合併了。
Spring Boot中配置不同環境的配置檔案我們現在的專案都是基於Spring Boot，不同的配置檔案，比如資料來源的配置、遠端介面地址、日誌列印等，Spring Boot是支援透過不同的profile來配置不同環境的配置。大概的配置就是：
根據不同的環境，設定不同的yml檔案，命名：application-xxx.yml
設定spring.profiles.active的值，可以在打包的時候指定。
多個基線的程式碼可以是完全一樣。
Spring Boot專案在啟動時指定配置這個拿一個實際專案舉例，是我們專案的做法，實現思路可能會有些怪異。我簡單說一下：
程式有兩個定時任務，分別是：job1和job2；
job1中的程式碼：if(job1run==true){邏輯處理}，job2類似；job1run和job2run預設false；
專案正常打包，不需要做額外處理，得到：project.jar
機器1執行：java -jar project.jar --job1run=true
機器2執行：java -jar project.jar --job2run=true
過程有些怪異，可以實現同一個程式碼包，再執行的時候指定它做什麼工作。
寫在資料庫中其實我是不排斥這種做法的，但是要注意：
有可能會發生變化的配置，放在資料庫中；
懶載入的方式讀取到記憶體中，不要每次使用的時候讀一次資料庫；
根據實際場景，決定載入到記憶體中的配置是否需要定時失效/過載。
統一配置中心隨著專案功能的增多：配置會越來越多，修改配置後實時生效的要求也會越來越高，所以很多公司會採用搭建【統一配置中心】的方式來解決這個問題。
配置中心的核心功能就是【配置】，但肯定不侷限於此，另外還需要有：審批、灰度釋出、回滾等功能；
常用的開源配置中心有：spring-cloud-config、Apollo、Nacos;