配置框架建议
我们开始开发基于 Spring 的 Web 应用程序（在 20 个 JVM 上运行）。 Web 应用程序在不同的环境（例如开发、QA、测试、压力、生产）上运行。
我们正在考虑为具有以下设计目标的应用程序设计一个配置框架...
配置框架的设计目标
- 支持继承模型：
如果配置属性是静态的，则它应该能够全局定义，并继承到所有环境。环境应该能够覆盖继承属性的值。 - 消除冗余：
应该只需要在一个位置查看、修改和添加配置属性。这应该可以降低添加或修改属性时丢失文件的风险。 - 能够在运行时管理和维护属性。
应该能够轻松更改内存中一对多 JVM 中的属性，并可以选择在 JVM 重新启动时保留该更改。 - 调试能力。
为了确定功能开关等的当前状态，您应该能够轻松地从内存中转储属性（一对多属性）。 - 降低不同 INT、QA、STRESS 环境不同步且难以部署和维护的可能性。
- 支持轻松开发以及整个生产的部署过程。这一变化不应对本地开发商有效开发的能力产生负面影响。相反，它应该会让事情变得更容易。
对于在 Spring 中实现这种配置框架有什么建议/推荐吗？
We are starting to work on a spring based web application (to run on 20 JVM's). The web application runs on different on Environments (say Dev, QA, test, Stress, Production).
We are looking into designing a configuration framework for the application with the below design goals...
Design Goals for the configuration Framework
- Support an inheritance model :
If a config property is static, it should be able to be defined globally, and inherited to all environments. Environments should have the ability to override the value of an inherited property. - Elimination of redundancy :
Should only have to look in one location to view, modify, and add config properties. This should reduce the risk of missing a file when adding or modifying properties. - Ability to administer and maintain properties at runtime.
Should be able to change a property in one-to-many JVMs in memory with ease, with the option to persist that change when the JVM is restarted. - Ability to debug.
In order to determine current state of functional switches, etc, you should be able to easily dump properties out of memory (one-to-many properties). - Decrease the likelihood that different INT, QA, STRESS environments are out of sync and difficult to deploy to and maintain.
- Support ease of the development, as well as the deployment process up through production. This change should not negatively impact a local developer’s ability to be effective at developing. To the contrary, it should make it easier.
Any Suggestions/Recommendations for achieving this kind of configuration framework in Spring?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您有很多要求，我没有所有这些要求的答案，但我建议应用程序尽可能多地外部化其运行时配置参数。我喜欢在 bean 文件中使用属性替换，从文件系统上的众所周知的位置加载值。在生产环境中，应锁定该位置，以便只有管理员或应用程序可以读取/写入该位置。
因此，在您的开发环境中，您将拥有特定于开发人员需求的内容（例如本地数据库凭据等）。质量检查和生产也是如此。您构建应用程序一次（通常由构建框/持续集成服务器完成），并且它只是加载到其部署到的环境的配置中。这将所有细节与代码库分开，这对于将密码和加密密钥等敏感信息锁定在安全的地方非常有用。
如果您还不熟悉使用 Spring 执行属性替换，请查看此处：
PropertyPlaceholderConfigurer
You have a lot of requirements there, and I don't have an answer for all of them, but I recommend the applications externalize as much of their runtime configuration parameters as possible. I like to use property substitution in my bean files, with the values loaded from a well known location out on the file system. In a production environment that location should be locked down so that only an admin or the app can read/write that location.
So in your development environment, you'd have things specific to a developer's needs (like local database credentials, etc). Same thing for QA and production. You build the app once (typically done by your build box/continuous integration server), and it just loads in its configuration for the environment it's been deployed to. This separates all specifics from the codebase, which is nice for keeping sensitive information like passwords and encryption keys locked in a safe place.
If you aren't already familiar with using Spring to perform property substitution, look here:
PropertyPlaceholderConfigurer
我建议不要将其视为软件开发工作（Spring 或其他），而更像是配置管理工作。
为了实现大部分这些要求，我们所做的就是区分跨环境保持不变的配置和可能变化的配置。例如，许多应用程序连接将保持不变，而密码、Web 服务 URL 等会有所不同。 （请注意，有时应用程序接线也会发生变化。例如，也许在本地开发盒上您使用本地身份验证，但在其他环境中您使用 CAS。）
然后确保恒定的配置只是应用程序本身的一部分（即打包在WAR 或 EAR），并且不同的配置被外部化。
在哪里将其外部化？使用您最喜欢的版本控制工具设置版本控制存储库（配置存储库），然后为您的各种环境创建文件夹。将特定于环境的配置放入适当的文件夹中，然后设置部署脚本以从正确的文件夹中获取正确的配置。
这个方案还是蛮不错的。您可以获得配置的集中管理，这有助于控制偏差，并且还提供可审核性、回滚、诊断支持等。就像分支源代码一样分支配置。
具体就 Spring 而言，3.1 将包括对称为配置文件的支持，我认为它允许您根据特定环境定制配置。我还没看过，但这就是我在 SpringOne 2GX 上听到的。
I would suggest treating this not as a software development effort (Spring or otherwise) but more like a configuration management effort.
What we do to achieve most of these requirements is distinguish config that remains constant across environments from config that can potentially vary. For example, lots of your app wiring will remain constant, whereas passwords, web service URLs and so forth will vary. (Note that sometimes app wiring will change too. E.g. maybe on your local dev box you use local authentication but in other environments you use CAS.)
Then make sure that the config that's constant is just part of the app itself (i.e. packaged in the WAR or EAR), and the config that varies is externalized.
Where to externalize it? Set up a version control repository (a config repo) using your favorite version control tool, and then create folders for your various environments. Put the environment-specific config in the appropriate folder and then set your deployment scripts up to source the right config from the right folder.
This scheme is pretty nice. You get central management of config, which helps to control drift, and also provides for auditability, rollback, diagnostic support, etc. Branch the config just as you would branch source code.
Regarding Spring specifically, 3.1 will include support for something called profiles, which allows you to tailor configuration to specific environments I think. I haven't looked at it yet but that's what I remember hearing at SpringOne 2GX.
我同意 Jeff Hall 的回答，但您可能还想阅读
PropertyOverrideConfigurer类。如果
PropertyPlaceholderConfigurer和PropertyOverrideConfigurer类不满足您的需求，那么您可能需要考虑对 Jeff Hall 的答案进行以下两步修改/增强。步骤 1. 我的 Config4*（发音为“config 4 star”）配置文件解析器几乎可以满足您声明的所有要求，只不过它没有集成到 Spring 中。我建议您阅读“Config4* 入门指南”的第 2 章和第 3 章，以确定 Config4* 是否对您的项目有用。 如果您认为它可能有用，那么...
步骤 2. 复制 Spring
PropertyPlaceholderConfigurer类的源代码，并修改它以获取来自 Config4* 文件而不是属性文件的名称=值对。该两步建议的潜在好处是，您无需为每个 INT/QA/STRESS 环境和/或 20 个 JVM 维护单独的属性文件。相反，Config4* 的“自适应配置”功能将使您能够将所有这些环境和 JVM 的运行时配置值放入单个配置文件中。
I agree with Jeff Hall's answer, but you might also want to read the documentation for the
PropertyOverrideConfigurerclass.If the
PropertyPlaceholderConfigurerandPropertyOverrideConfigurerclasses do not suit your needs, then you might want to consider the following two-step modification/enhancement of Jeff Hall's answer.Step 1. My Config4* (pronounced "config 4 star") configuration-file parser addresses almost all of your stated requirements, except that it is not integrated into Spring. I suggest you read Chapters 2 and 3 of the "Config4* getting Started Guide" to decide if Config4* might be useful for your project. If you decide it might be useful, then...
Step 2. Make a copy of the source code of the Spring
PropertyPlaceholderConfigurerclass, and modify it to obtain name=value pairs from a Config4* file instead of a properties file.The potential benefit of that two-step suggestion is that you would not need to maintain separate properties files for each of your INT/QA/STRESS environments and/or for each of your 20 JVMs. Instead, the "adaptable configuration" capabilities of Config4* will enable you to put the runtime configuration values for all those environments and JVMs into a single configuration file.