要把配置中心整合进现有的项目，要做的事情还不少
接管spring mvc属性文件
现在的java应用一般都是spring框架的，spring属性文件配置占了绝大多数比例，所以配置中心的，首要任务就是把spring配置文件集中到配置中心来管理。其实spring cloud本身也有一套配置管理，它是通过git或svn进行配置的，在版本控制上比较方便，但在界面使用上就比太方便了。
spring mvc属性文件是通过PropertyPlaceholderConfigurer来管理的，所以要接管spring mvc属性文件，就可以实现自定义的PropertyPlaceholderConfigurer，并实现从配置中心的读取配置。
接管spring boot的application.properties 属性文件
Spring Boot 所提供的配置优先级顺序比较复杂。按照优先级从高到低的顺序，具体的列表如下所示。
- 命令行参数。
- 通过 System.getProperties() 获取的 Java 系统参数。
- 操作系统环境变量。
- 从 java:comp/env 得到的 JNDI 属性。
- 通过 RandomValuePropertySource 生成的“random.*”属性。
- 应用 Jar 文件之外的属性文件。(通过spring.config.location参数)
- 应用 Jar 文件内部的属性文件。
- 在应用配置 Java 类（包含“@Configuration”注解的 Java 类）中 通过“@PropertySource”注解声明的属性文件。
- 通过“SpringApplication.setDefaultProperties”声明的默认属性。
所以要方便把配置中心的配置注入，比较好的是2和9，但2会设置太多的System属性感觉不太好，所以最终使用SpringApplication.setDefaultProperties方法把配置塞进去。但这种方式也有个弊端，它优先级是最低的，application.properties的配置如果不去掉的话，会把配置中心的配置覆盖的。
接管其他工具类配置信息的读取
有些配置信息是通过自定义的工具类从自定义的配置文件中读取的，这些工具类都需要进行改造，改为从配置中心读取。
Freemarker 模板直接引用了maven profile（mvn）的属性
maven profile的属性都是编译时打进去的，跟上面提到的动态加载的不一样，不幸的是，现有的项目代码中有些 Freemarker 模板图方便，用到了maven的profile属性，这种情况怎么办？其实还是借助spring来进行动态配置。
1）先保证在spring mvc 配置中引用我配置中心自定义的propertyConfigurer 属性获取类
<bean id="propertyConfigurer" class="com.cehome.utils.config.PropertyPlaceholderConfigurer">
</bean>2）然后在freemarkerConfig 中增加freemarkerVariables属性，在里面配置多个变量，通过这种方式，把原来模版中静态编译的变量（如${baseUrl})换成由spring属性读取。
<bean id="freemarkerConfig"
class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
<property name="freemarkerVariables">
<map>
<entry key="baseUrl" value="${baseUrl}"></entry>
</map>
</property>
</bean>Js文件中包含了mvn配置项
Js 比较麻烦，原则上也是要去掉mvn属性项。一种方法是把js中的mvn的变量移出到模板页面中，在模板页面中加入变量定义，如：
原来util.js中包含mvn项：
var baseUrl ="${mvn.scheduler.baseUrl}";```
改为：
##Logback 日志环境变量修改（如日志级别）。
通过在logback.xml我们会定义一些占位符参数，如${logback.root.level}，也是通过mvn编译时候打进去的，这种也需要人为做些处理，取到配置中心的属性后，通过调用System.setProperty("logback.root.level","INFO") 进行动态注入，logback它是能够识别系统属性的。
## 配置合并
在实际改造当中发现，不同应用其实是由一些公共配置的，例如数据库配置、redis配置，如果每个应用都配置一遍感觉重复太多了。所以增加了公共配置信息，并有一个约定，缺省的情况下应用启动是时候先加载公共配置信息，然后再是应用本身的配置，应用本身的配置可以覆盖公共配置同名的配置项。