配置框架建議

Question

我們正在開發基於Spring的Web應用程序（在20個JVM上運行）。 Web應用程序在環境上運行不同（稱Dev，QA，測試，壓力，生產）。

我們正在研究設計與下面的設計目標應用程序的配置框架...

爲配置框架

1. 支持的繼承模型的設計目標：
   如果config屬性是靜態的，它應該能夠被全局定義，並繼承到所有環境。環境應該能夠覆蓋繼承屬性的值。
2. 消除冗餘：
   應該只需查看一個位置即可查看，修改和添加配置屬性。這應該可以降低添加或修改屬性時丟失文件的風險。
3. 在運行時管理和維護屬性的能力。
   應該能夠輕鬆地在內存中的一對多JVM中更改屬性，並且可以在重新啓動JVM時保留該更改。
4. 調試能力。
   爲了確定功能開關的當前狀態等，您應該能夠輕鬆地將屬性轉儲出內存（一對多屬性）。
5. 降低不同INT，QA，STRESS環境不同步且難以部署和維護的可能性。
6. 支持開發的簡易性以及部署過程。這種改變不應該對本地開發人員有效開發的能力產生負面影響。相反，它應該使它更容易。

有關在Spring中實現這種配置框架的任何建議/建議？

Answer 1

您對這方面有很多要求，我沒有全部答案，但我建議應用盡可能多地使用其運行時配置參數進行外部化。我喜歡在我的bean文件中使用屬性替換，並將值從文件系統上衆所周知的位置加載。在生產環境中，應鎖定位置，以便只有管理員或應用可以讀取/寫入該位置。

因此，在您的開發環境中，您將擁有特定於開發人員需求的事物（如本地數據庫憑證等）。質量保證和生產同樣如此。您只需構建一次應用程序（通常由您的構建箱/持續集成服務器完成），並且只爲其已部署到的環境加載其配置。這將所有細節從代碼庫中分離出來，這非常適合將密碼和加密密鑰等敏感信息鎖定在安全的地方。

如果您還不熟悉使用Spring進行財產置換，請看這裏：

PropertyPlaceholderConfigurer

Answer 2

我同意傑夫·霍爾的答案，但你可能還需要閱讀的PropertyOverrideConfigurer文檔類。

如果PropertyPlaceholderConfigurer和PropertyOverrideConfigurer類不適合您的需求，那麼您可能需要考慮以下兩步修改/增強Jeff Hall的答案。

第1步。我的Config4*（發音爲「config 4 star」）配置文件解析器解決了您幾乎所有的需求，只是它沒有集成到Spring中。我建議您閱讀「Config4 *入門指南」的第2章和第3章，以確定Config4 *對您的項目是否有用。 如果你決定它可能是有用的，然後......

第2步，在彈簧PropertyPlaceholderConfigurer類的源代碼的副本，並將其修改爲從CONFIG4 *文件獲得名稱=值雙而不是屬性文件。

該兩步式建議的潛在好處是，您不需要爲每個INT/QA/STRESS環境和/或每個20 JVM維護單獨的屬性文件。相反，Config4 *的「自適應配置」功能將使您能夠將運行時配置值的所有這些環境和JVM放入單個配置文件中。

Answer 3

我會建議把它看作是一個軟件開發工作（Spring或其他），但更像是一個配置管理工作。

我們爲了實現大多數這些要求所做的工作是區分不同環境中不同環境的配置，這些配置可能會有所不同。例如，很多應用程序的佈線將保持不變，而密碼，Web服務URL等等會有所不同。 （請注意，有時應用的佈線也可能發生變化。例如，也許在您的本地開發框您使用本地身份驗證，但在其它環境中使用CAS）

然後確保這是不變的配置僅僅是應用程序本身的一部分（即打包在WAR或EAR中），並且變化的配置被外化。

何處將其外化？使用您最喜愛的版本控制工具設置版本控制庫（配置庫），然後爲您的各種環境創建文件夾。將特定於環境的配置文件放入適當的文件夾中，然後將您的部署腳本設置爲從正確的文件夾獲取正確的配置文件。

這個方案很不錯。您可以對config進行集中管理，這有助於控制漂移，還可以提供可審計性，回滾，診斷支持等。像配置源代碼一樣分支配置。

關於Spring的具體情況，3.1將包括對所謂的配置文件的支持，它允許您根據特定的環境定製配置。我還沒有看過它，但這是我記得在SpringOne 2GX上聽到的。