配置框架建议

时间:2011-04-06 19:04:58

标签: spring configuration configuration-management

我们开始研究基于Spring的Web应用程序(在20个JVM上运行)。 Web应用程序在不同的环境中运行(例如Dev,QA,test,Stress,Production)。

我们正在研究为应用程序设计一个配置框架,并具有以下设计目标......

配置框架的设计目标

  1. 支持继承模型:
            如果config属性是静态的,则应该能够全局定义,并继承到所有环境。环境应该能够覆盖继承属性的值。
  2. 消除冗余:
             只需查看一个位置即可查看,修改和添加配置属性。这可以降低添加或修改属性时丢失文件的风险。
  3. 能够在运行时管理和维护属性           应该能够轻松地更改内存中一对多JVM中的属性,并且可以选择在重新启动JVM时保留该更改。
  4. 调试能力。
              为了确定功能开关的当前状态等,您应该能够轻松地将属性转储出内存(一对多属性)。
  5. 降低不同INT,QA,STRESS环境不同步且难以部署和维护的可能性。
  6. 支持开发的简易性以及通过生产部署的过程。这种变化不应对当地开发商有效开发的能力产生负面影响。相反,它应该更容易。
  7. 有关在Spring中实现此类配置框架的任何建议/建议吗?

3 个答案:

答案 0 :(得分:1)

那里有很多要求,我没有对所有这些要求给出答案,但我建议应用程序尽可能多地外化其运行时配置参数。我喜欢在我的bean文件中使用属性替换,从文件系统上的一个众所周知的位置加载值。在生产环境中,应锁定该位置,以便只有管理员或应用程序才能读取/写入该位置。

因此,在您的开发环境中,您将拥有特定于开发人员需求的内容(如本地数据库凭据等)。质量保证和生产也是如此。您构建应用程序一次(通常由构建框/持续集成服务器完成),它只是在其配置中加载它已部署到的环境。这将所有细节与代码库分开,这样可以将密码和加密密钥等敏感信息锁定在安全的地方。

如果您还不熟悉使用Spring执行属性替换,请查看:

PropertyPlaceholderConfigurer

答案 1 :(得分:0)

我同意Jeff Hall的回答,但您可能还想阅读PropertyOverrideConfigurer课程的文档。

如果PropertyPlaceholderConfigurerPropertyOverrideConfigurer课程不符合您的需求,那么您可能需要考虑以下两步修改/增强Jeff Hall的答案。

步骤1.我的Config4*(发音为“config 4 star”)配置文件解析器几乎解决了所有规定的要求,但它没有集成到Spring中。我建议您阅读“Config4 *入门指南”的第2章和第3章,以确定Config4 *是否对您的项目有用。 如果你认为它可能有用,那么......

步骤2.复制Spring PropertyPlaceholderConfigurer类的源代码,并修改它以从Config4 *文件而不是属性文件中获取 name = value 对。

这个两步建议的潜在好处是,您不需要为每个INT / QA / STRESS环境和/或每个20个JVM维护单独的属性文件。相反,Config4 *的“自适应配置”功能将使您能够将所有这些环境和JVM的运行时配置值放入单个配置文件中。

答案 2 :(得分:0)

我建议将此视为软件开发工作(Spring或其他方式),而不是配置管理工作。

我们为实现大多数这些要求所做的工作是区分不同环境的配置和可能发生变化的配置。例如,您的许多应用程序布线将保持不变,而密码,Web服务URL等将有所不同。 (请注意,有时应用程序布线也会发生变化。例如,您可能在本地开发盒中使用本地身份验证,但在其他环境中使用CAS。)

然后确保该常量的配置只是应用程序本身的一部分(即打包在WAR或EAR中),并且变化的配置是外部化的。

在哪里外化?使用您喜欢的版本控制工具设置版本控制存储库(配置存储库),然后为各种环境创建文件夹。将特定于环境的配置放在相应的文件夹中,然后将部署脚本设置为从右侧文件夹中获取正确的配置。

这个计划非常好。您可以获得配置的集中管理,这有助于控制漂移,还提供可审计性,回滚,诊断支持等。如同分支源代码一样对分区进行分支。

特别针对Spring,3.1将包括对名为profiles的东西的支持,它允许您根据我认为的特定环境定制配置。我还没有看过它,但这是我记得在SpringOne 2GX上听到的。