AutoConfig工具使用指南-优快云博客

本文链接：https://blog.youkuaiyun.com/Chenbug666/article/details/103133536

第 13 章 AutoConfig工具使用指南

13.1. 需求分析

13.1.1. 解决方案

13.2. AutoConfig的设计

13.2.1. 角色与职责

13.2.2. 分享二进制目标文件

13.2.3. 部署二进制目标文件

13.2.4. AutoConfig特性列表

13.3. AutoConfig的使用 —— 开发者指南

13.3.1. 建立AutoConfig目录结构

13.3.2. 建立auto-config.xml描述文件

13.3.3. 建立模板文件

13.4. AutoConfig的使用 —— 部署者指南

13.4.1. 在命令行中使用AutoConfig

13.4.2. 在maven中使用AutoConfig

13.4.3. 运行并观察AutoConfig的结果

13.4.4. 共享properties文件

13.4.5. AutoConfig常用命令

13.5. 本章总结

13.1. 需求分析

在一个应用中，我们总是会遇到一些参数，例如：

数据库服务器IP地址、端口、用户名；
用来保存上传资料的目录。
一些参数，诸如是否打开cache、加密所用的密钥名称等等。

这些参数有一个共性，那就是：它们和应用的逻辑无关，只和当前环境、当前系统用户相关。以下场景很常见：

在开发、测试、发布阶段，使用不同的数据库服务器；
在开发阶段，使用Windows的A开发者将用户上传的文件存放在d:\my_upload目录中，而使用Linux的B开发者将同样的文件存放在/home/myname/my_upload目录中。
在开发阶段设置cache=off，在生产环境中设置cache=on。

很明显，这些参数不适合被“硬编码”在配置文件或代码中。因为每一个从源码库中取得它们的人，都有可能需要修改它们，使之与自己的环境相匹配。

13.1.1. 解决方案

13.1.1.1. 运行时替换的placeholders

很多框架支持在运行时刻替换配置文件中的placeholder占位符。例如， Webx/Spring就有这个功能。

例 13.1. 在Webx中定义placeholders

<services:property-placeholder />

<services:webx-configuration>
    <services:productionMode>${productionMode:true}</services:productionMode>
</services:webx-configuration>

在上面这个例子中，你可以在启动应用时，加上JVM参数：“-DproductionMode=false|true”来告诉系统用哪一种模式来工作。如果不指定，则取默认值“true”。

运行时替换placeholder是一种非常实用的技术，它有如下优缺点：

表 13.1. 运行时替换placeholders的优缺点

优点	缺点
配置文件是静态的、不变的。即使采用不同的参数值，你也不需要更改配置文件本身。你可以随时改变参数的值，只需要启动时指定不同的JVM参数、或指定不同的properties文件即可。这种配置对于应用程序各组件是透明的 —— 应用程序不需要做特别的编程，即可使用placeholders。	并非所有框架都支持这种技术。支持该技术的框架各有不同的用法。例如：Spring和Log4j都支持placeholder替换，然则它们的做法是完全不同的。Spring通过`PropertyPlaceholderConfigurer`类来配置，而Log4j则需要在`DomConfigurator`中把参数传进去。

13.1.1.2. 中心配置服务器（Config Server）

这也是一种运行时技术。它可以在运行时刻，将应用所需的参数推送到应用中。

它有如下优缺点：

表 13.2. 中心配置服务器的优缺点

优点	缺点
它可以集中管理所有应用的配置，避免可能的错误；它可以在运行时改变参数的值，并推送到所有应用中。参数的更改可立即生效。	需要一套独立的服务器系统。性能、可用性（availability）都是必须考虑的问题。对应用不是透明的，有一定的侵入性。应用程序必须主动来配合该技术。因此，该技术不可能适用于所有情况，特别对于第三方提供的代码，很难使用该技术。为了连接到中心配置服务器，你仍然需要配置适当的IP、端口等参数。你需要用其它技术来处理这些参数（例如placeholders）。

优点

缺点

它可以集中管理所有应用的配置，避免可能的错误；
它可以在运行时改变参数的值，并推送到所有应用中。参数的更改可立即生效。

需要一套独立的服务器系统。性能、可用性（availability）都是必须考虑的问题。
对应用不是透明的，有一定的侵入性。应用程序必须主动来配合该技术。因此，该技术不可能适用于所有情况，特别对于第三方提供的代码，很难使用该技术。
为了连接到中心配置服务器，你仍然需要配置适当的IP、端口等参数。你需要用其它技术来处理这些参数（例如placeholders）。

13.1.1.3. Maven Filtering机制

Maven提供了一种过滤机制，可以在资源文件被复制到目标目录的同时，替换其中的placeholders。

例 13.2. 配置Maven Filtering机制

假设你的项目目录结构如下：

web-project
 │  pom.xml
 │
 └─src
     └─main
         ├─java
         ├─resources
         └─webapp
             └─WEB-INF
                     web.xml

在pom.xml中这样写：

<build>
    <filters>
        <filter>${user.home}/antx.properties</filter> </filters>
    <resources>
        <resource>
            <directory>src/main/resources</directory> <includes>
                <include>**.xml</include>
            </includes>
            <filtering>true</filtering>
        </resource>
        <resource>
            <directory>src/main/resources</directory>
            <excludes>
                <exclude>**.xml</exclude>
            </excludes>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <artifactId>maven-war-plugin</artifactId>
            <configuration>
                <webResources>
                    <resource>
                        <directory>src/main/webapp</directory> <includes>
                            <include>WEB-INF/**.xml</include>
                        </includes>
                        <filtering>true</filtering>
                    </resource>
                    <resource>
                        <directory>src/main/webapp</directory>
                        <excludes>
                            <include>WEB-INF/**.xml</include>
                        </excludes>
                    </resource>
                </webResources>
            </configuration>
        </plugin>
    </plugins>
</build>

这段pom定义告诉maven：

	用指定的properties文件（`${user.home}/antx.properties`）中的值，替换文件中的placeholders。
	过滤`src/main/resources/`目录中的所有xml文件，替换其中的placeholders。
	过滤`src/webapp/WEB-INF/`目录中的所有xml文件，替换其中的placeholders。

如果上述xml文件中，包含“${xxx.yyy.zzz}”这样的placeholders，将被替换成properties文件中的相应值。

和运行时替换placeholders方案相比，Maven Filtering是一个build时进行的过程。它的优缺点是：

表 13.3. Maven Filtering机制的优缺点

优点	缺点
Maven filtering机制和应用所采用的技术、框架完全无关，对应用完全透明，通用性好。	Maven filtering机制在build时刻永久性改变被过滤的配置文件的内容，build结束以后无法更改。这将导致一个问题：如果要改变配置文件的参数，必须获取源码并重新build。缺少验证机制。当某个placeholder拼写错误；当properties中的值写错；当某配置文件中新增了一个placeholder，而你的properties文件中没有对应的值时，maven不会提醒你。而这些错误往往被拖延到应用程序运行时才会被报告出来。

优点

缺点

Maven filtering机制和应用所采用的技术、框架完全无关，对应用完全透明，通用性好。

Maven filtering机制在build时刻永久性改变被过滤的配置文件的内容，build结束以后无法更改。这将导致一个问题：如果要改变配置文件的参数，必须获取源码并重新build。
缺少验证机制。当某个placeholder拼写错误；当properties中的值写错；当某配置文件中新增了一个placeholder，而你的properties文件中没有对应的值时，maven不会提醒你。而这些错误往往被拖延到应用程序运行时才会被报告出来。

13.1.1.4. AutoConfig机制

AutoConfig是一种类似于Maven Filtering的build时刻的工具。这意味着该机制与应用所采用的技术、框架完全无关，对应用完全透明，具有良好的通用性。同时，AutoConfig与运行时的配置技术并不冲突。它可以和运行时替换的placeholders以及中心配置服务器完美并存，互为补充。

AutoConfig书写placeholder的方法和Maven Filtering机制完全相同。换言之，Maven Filtering的配置文件模板（前例中的/WEB-INF/**.xml）可以不加修改地用在AutoConfig中。

然而，autoconfig成功克服了Maven Filtering的主要问题。

表 13.4. Maven Filtering和AutoConfig的比较

问题	Maven Filtering	AutoConfig
如何修改配置文件的参数？	Maven Filtering必须获得源码并重新build；	而AutoConfig不需要提取源码，也不需要重新build，即可改变目标文件中所有配置文件中placeholders的值。
如何确保placeholder替换的正确性？	Maven Filtering不能验证placeholder值的缺失和错误；	但AutoConfig可以对placeholder及其值进行检查。