创建应用程序/产品配置的设计模式/指南 [英] Design patterns/guidelines on creating application/product configurations

问题描述

我想知道是否有任何用于创建应用程序配置结构，数据和文件的设计模式，指南或记录的widsom /最佳实践。
我意识到这个问题在一些帖子中被部分地触及，但我希望以下问题从另一个方面提示看主题。

I was wondering if there are any design patterns, guidelines or documented widsom/best practices for creating 'application configuration' structure, data, and files. I realize this questions has been partially touched in some posts but I hope the following questions prompt looking at the topic from another aspect.

<

• 需要考虑什么样的力量？


• 基于什么样的分析来创建配置结构？应用配置分析/创建发挥作用;是对主设计活动（由应用设计决定）还是与主设计和本身的结构/架构工作相互依赖的后续思考或后续？




• 需要捕获或意识到什么样的需求（灵活性，覆盖能力，缺乏重复，选择，...） ）


• 在开发不良应用配置时支付的费用是多少？

• Basically what kind of analysis goes into creating the configuration structure?
• What kind of forces are at play that one needs to consider?
• When does application configuration analysis/creation come into play; is it an after-thought or followup to the main design activity (is dictated by application design) or interdependent with the main design and a structuring/architecture effort in its own right?
• What pros and cons for structuring configuration data in one way rather than another.
• What kind of requirements needs to be captured or aware of (flexibility, override capability, lack of duplication, selection, ...)
• What is the cost paid in developing bad application configurations?

是否有任何实际的项目，有足够的复杂程度，其配置可以研究？

Are there any actual projects out there with sufficient level of sophistication whose configuration could be studied?

我的问题不是针对文件的格式或类型（是否使用flat ini或json，xml，...），而是如何首先到达配置。

My question is not aimed at format or type of files (whether to use flat ini, or json, xml, ...) but at how to arrive at configurations in the first place.

感谢

推荐答案

许多应用程序都已部署（即已安装，配置和运行）多次。例如，应用程序可能部署在开发人员的机器上;然后在一个或多个测试机（具有诸如UAT，分级或预生产的名称）上;然后可能在多个生产机器上。生产中的多个部署可能出于各种原因，例如：

Many applications are deployed (that is, installed, configured and run) multiple times. For example, an application might be deployed on the developer's machine; then on one or more testing machines (with a name such as UAT, Staging or pre-production); then possibly on multiple production machines. The multiple deployments in production might arise for a variety of reasons, for example:

• 您要部署服务器应用程序的多个副本，然后使用负载平衡技术将客户端请求路由到这些服务器副本。


• 您希望在公司有办公室的每个地理位置部署一个单独的应用程序实例。 li>
  
• 您的应用程序具有插件架构，并且您要部署应用程序的多个实例，每个实例都具有不同的插件集。

您可能需要为应用程序的每个部署提供一个大部分相似但略有不同的配置文件集。如果您使用复制和粘贴方法来创建这些多组配置文件，则可能导致维护问题。我知道有两种方法来减少这个问题。

You will probably need to have a "mostly similar but slightly different" set of configuration files for each deployment of your application. That can result in a maintenance problem if you use a copy-and-paste approach to creating those multiple sets of configuration files. I know of two approaches to reducing that problem.

第一种方法是使用 Config4 * 为您的配置文件语法（免责声明：我是Config4 *的主要维护者），因为它的语法提供了各种方式，如if-then-else语句，以使配置文件能够适应其部署环境，同时仍然重用常用的 name = value 设置。我建议您阅读第2章（ HTML ）和3（ HTML ） （ PDF ），以了解其语法和API的概述。不幸的是，Murphy的法律规定，您的应用程序将利用一些第三方库使用除Config4 *之外的其他配置（例如XML或Java属性文件）进行配置，因此Config4 *不会帮助您。但是，我认为仍然值得阅读上面提到的文档，因为一些Config4 *的能力可能提供食物的思考。

The first approach is to use Config4* for your configuration-file syntax (disclaimer: I am the main maintainer of Config4*), because it's syntax provides a variety of ways, such as "if-then-else" and "include" statements to enable a configuration file to adapt to its deployment environment while still reusing common name=value settings. I suggest you read Chapters 2 (HTML) and 3 (HTML) of the Config4* Getting Started Guide (PDF) to get an overview of its syntax and API. Unfortunately, Murphy's Law states that your application will make use of some third-party libraries that use something other than Config4* (e.g., XML or Java properties files) for their configuration, so Config4* won't help you with that. However, I think it is still worthwhile reading the above mentioned documentation, since some of Config4*'s abilities might provide food for thought.

第二种方法是写一个模板为每种配置文件，其中模板主要包含纯文本，但具有几个占位符。下面是一个示例模板配置文件，使用符号 $ {foo} 表示占位符。

The second approach is to write a "template" for each kind of configuration file, where the template contains mostly plain text, but with a few placeholders. Here is an example template configuration file, using the notation ${foo} to denote a placeholder.

serverName  = "${serverName}"
listenPort  = "${serverPort}"
logDir      = "/data/logs/${serverName}";
idleTimeout = "5 minutes";
workingDir  = "/tmp";

如果你这样做的应用程序使用的所有配置文件，那么你可能会发现，对模板配置文件的全局搜索和替换具有相对较少数量的占位符的值将产生用于特定部署的准备运行的配置文件。我在一个项目中使用了这种方法，每个部署有超过2000行配置文件，大约60个部署，因此导致超过100,000行配置文件。要应用于模板文件的搜索和替换数据比从其生成的现成部署配置文件少了50倍的行，因此显着更容易维护。如果您正在寻找一种简单的方法，在模板文件中对占位符执行全局搜索和替换，那么您可能需要考虑 Apache Velocity 。

If you do that for all the configuration files used by your application, then you will probably find that performing a global-search-and-replace on the template configuration files with values for a relatively small number of placeholders will yield the ready-to-run configuration files for a particular deployment. I have used this approach in a project where there was over 2000 lines of configuration files per deployment, and about 60 deployments, thus resulting in over 100,000 lines of configuration files. The search-and-replace data to be applied to the template files had about 50 times fewer lines than the ready-to-deploy configuration files that were produced from it, and thus were significantly easier to maintain. If you are looking for an easy way to perform global search-and-replace on placeholders in template files, then you might want to consider Apache Velocity.

无论是手写配置文件还是从模板生成它们，都是配置中的数据运行时验证的问题文件。不幸的是，相对较少的配置文件格式提供模式验证。我唯一知道的如下。 Config4 *提供了一个易于使用的模式验证引擎（在上述文档的第3章中讨论）。还有一个 JSON的模式验证语言。当然，有许多 XML的模式验证语言，但他们通常有一个陡峭的学习曲线。

Independent of whether you hand-write configuration files or generate them from templates is the issue of run-time validation of the data in the configuration files. Unfortunately, relatively few configuration-file formats provide schema validation. The only ones I know of are as follows. Config4* provides an easy-to-use schema validation engine (discussed in Chapter 3 of the documentation mentioned above). There is also a schema validation language for JSON. And, of course, there are numerous schema validation languages for XML, but they typically have a steep learning curve.

这篇关于创建应用程序/产品配置的设计模式/指南的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！