低調的牛肉
針對這個問題我提幾種方案，因為不同的項目的背景不同，也別上來就上統一配置中心，還是針對實際情況，選擇不同的方案。
不同代碼基線，使用不同配置文件
正常情況，我們的代碼基線會有多條，比如最簡單的開發基線和生產基線，開發人員在開發基線上進行代碼開發，配置文件中的內容對應的是開發環境；同理，生產基線中的配置文件對應的是生產環境；
可以看出來，不同基線，代碼是一致的（或者說會最終一致），但是配置文件是不同的；如果配置文件需要修改的話，就不能通過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;
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
