0. 配置信息
配置信息特指程序啟動時對程序進行配置的信息,常見的如服務端口、數(shù)據(jù)庫連接信息、線程池信息等。
在系統(tǒng)啟動時,程序會通過不同的配置方案,主動獲取配置信息,以完成系統(tǒng)的初始化工作。
因此,配置信息的管理是一件非常重要的事情。
您的配置信息是怎么管理的呢?讓我們一起見證下配置信息管理的不同方案。
1. 將配置信息寫死在業(yè)務代碼中
在業(yè)務代碼中寫死配置信息絕對是大部分新手常干的事情。
該策略有以下幾個特點:
由于系統(tǒng)可能會被部署在不同的環(huán)境中(如開發(fā)環(huán)境、測試環(huán)境、生產環(huán)境等 ), 但不同環(huán)境之間存在的差異性 (如各個環(huán)境的URL不同、賬號/密碼不同、單機所允許申請的最大連接數(shù)不同等 ), 會使開發(fā)人員每次都只能通過修改業(yè)務代碼的方式進行適應。
在一些比較簡單的單元測試場景中,我們可以將配置信息寫死在測試代碼中。
2. 將配置信息配置到配置文件中
修改源碼會破壞系統(tǒng)的穩(wěn)定性,在大部分情況下,我們都會選擇將相關配置信息配置在配置文件中,當系統(tǒng)啟動時,會從指定文件進行加載,通過配置文件中的配置信息來完成環(huán)境的初始化工作。
此方案存在以下特征:
采用配置文件 ,我們可以很好地將可變的配置信息與業(yè)務代碼進行解耦。
該方案有個缺陷,就是在發(fā)布前需要手工修改配置信息。對此,可以借助構建工具的一些功能進行簡化,比如 Maven 的 Filter 功能。
3. 使用 Maven 的 Profile 功能
Maven 的 Profile 功能,可以在打包前完成配置文件的修改。
相對之前方案,只是使用構建工具把手工修改升級為自動配置,對整體方案影響不大。
相信,這應該是使用最普遍的一種配置管理策略。但該方案存在一個問題,每個環(huán)境使用不同的部署包,結果便是測試使用的部署包與線上使用的并非 100% 相同。
4. 全環(huán)境打包結合運行時配置
如何統(tǒng)一各環(huán)境使用的部署包呢?
我們可以使用全環(huán)境包結合運行時配置的方式達到統(tǒng)一。
該策略的特征如下:
通常的做法是在系統(tǒng)啟動時,通過JVM的啟動參數(shù)設置系統(tǒng)屬性(如 java -Denv=”dev”),當系統(tǒng)運行時通過 System 的 getProperty (String Key)方法獲取指定的系統(tǒng)屬性值來自動匹配當前環(huán)境,并加載配置文件中對應的配置信息,從而避免手動切換。
建議大家在配置文件中預先定義好不同環(huán)境所需的配置信息項,并由系統(tǒng)在運行時自動進行匹配和加載。這樣一來,從版本提測到最終測試通過,運維人員便可以直接將測試通過后的版本發(fā)布到生產環(huán)境中。
5. 集中式配置
在分布式環(huán)境中,系統(tǒng)往往都是采用集群部署的,那么集群環(huán)境中的每一個節(jié)點都持有同一份配置文件,一旦配置信息發(fā)生改變,就意味著集群環(huán)境中的所有配置文件都需要做出相應的調整。而隨著系統(tǒng)拆分的粒度越來越細,維護成本將會大大提升,并且配置出錯的可能性也隨之增加,因此需要一種集中式配置管理形式,以讓所有的集群節(jié)點共享同一份配置信息。
該策略有如下幾個特征:
除此以外,配置服務還提供了很多優(yōu)勢:
這個方案應該是微服務的標配,現(xiàn)在越來越流行開來。
6. 全環(huán)境打包結合集中配置
當然,各種配置管理策略并不是水火不容,我們可以將多種策略結合使用,如將環(huán)境打包和集中配置結合使用。
這樣,我們可以將敏感信息(數(shù)據(jù)庫連接地址、用戶名、密碼等)存儲在 git 中,進行統(tǒng)一管理;將應用配置存儲與配置文件中,由開發(fā)人員進行維護。
7. 小結
配置信息管理是系統(tǒng)平穩(wěn)運行不可或缺的重要組成部分,不同的管理策略,適應于不同的場景,我們需要熟知各種策略的優(yōu)缺點,根據(jù)自身的情況進行選擇。
切記,沒有最好的方案,只有最適合的方案。