1

我们开始开发基于 Spring 的 Web 应用程序（在 20 个 JVM 上运行）。Web 应用程序在不同的环境（例如 Dev、QA、test、Stress、Production）上运行。

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

配置框架的设计目标

  1. 支持继承模型：
    如果配置属性是静态的，它应该能够全局定义，并继承到所有环境。环境应该能够覆盖继承属性的值。
  2. 消除冗余：
    应该只需要在一个位置查看、修改和添加配置属性。这应该可以降低添加或修改属性时丢失文件的风险。
  3. 能够在运行时管理和维护属性。
    应该能够轻松地更改内存中一对多 JVM 中的属性，并且可以选择在 JVM 重新启动时保留该更改。
  4. 调试能力。
    为了确定功能开关等的当前状态，您应该能够轻松地将属性转储出内存（一对多属性）。
  5. 降低不同 INT、QA、STRESS 环境不同步且难以部署和维护的可能性。
  6. 支持轻松的开发，以及通过生产的部署过程。此更改不应对本地开发人员有效开发的能力产生负面影响。相反，它应该使它更容易。

在 Spring 中实现这种配置框架的任何建议/建议？

4

3 回答 3

1

你有很多需求，我没有所有的答案，但我建议应用程序尽可能多地外部化它们的运行时配置参数。我喜欢在我的 bean 文件中使用属性替换，并从文件系统上一个众所周知的位置加载值。在生产环境中，该位置应该被锁定，以便只有管理员或应用程序可以读取/写入该位置。

因此，在您的开发环境中，您将拥有特定于开发人员需求的东西（例如本地数据库凭据等）。质量检查和生产也是如此。您构建应用程序一次（通常由您的构建盒/持续集成服务器完成），它只是加载其部署到的环境的配置。这将所有细节与代码库分开，这有助于将密码和加密密钥等敏感信息锁定在安全的地方。

如果您还不熟悉使用 Spring 执行属性替换，请看这里：

PropertyPlaceholderConfigurer

于 2011-04-06T23:20:55.643 回答
0

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

如果PropertyPlaceholderConfigurer和PropertyOverrideConfigurer类不适合您的需求，那么您可能需要考虑对 Jeff Hall 的答案进行以下两步修改/增强。

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

步骤 2. 复制 SpringPropertyPlaceholderConfigurer类的源代码，并对其进行修改以从 Config4* 文件而不是属性文件中获取名称=值对。

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

于 2011-04-07T06:23:30.543 回答
0

我建议不要将其视为软件开发工作（Spring 或其他），而更像是配置管理工作。

我们为实现这些要求中的大部分所做的是将跨环境保持不变的配置与可能发生变化的配置区分开来。例如，您的许多应用程序连接将保持不变，而密码、Web 服务 URL 等会有所不同。（请注意，有时应用程序接线也会发生变化。例如，您可能在本地开发盒上使用本地身份验证，但在其他环境中使用 CAS。）

然后确保不变的配置只是应用程序本身的一部分（即打包在 WAR 或 EAR 中），而变化的配置是外部化的。

在哪里外化它？使用您最喜欢的版本控制工具设置版本控制存储库（配置存储库），然后为您的各种环境创建文件夹。将特定于环境的配置放在适当的文件夹中，然后设置您的部署脚本以从正确的文件夹中获取正确的配置。

这个方案很不错。您可以获得配置的集中管理，这有助于控制漂移，还提供可审计性、回滚、诊断支持等。像分支源代码一样分支配置。

特别是关于 Spring，3.1 将包括对称为配置文件的支持，它允许您根据我认为的特定环境定制配置。我还没有看过它，但这就是我记得在 SpringOne 2GX 上听到的。

于 2011-04-07T06:38:19.480 回答