应用配置信息的演化之路

   不论单体架构还是服务化架构甚至是微服务架构，系统中肯定保存必要的配置信息，比如连接的数据库地址、缓存地址、第三方服务地址、日志中间件配置、消息中间件配置等等。本文重点阐述了这些配置信息在开发演化过程中是如何动态变化的，不同时期的存储及应对方案。

一、初期

   应用系统初期，往往采用单体架构，基本上该阶段，技术是服务于业务的。毕竟公司要生存，平台要快速试错，允许快速发展。改阶段往往在系统中直接采用xml、json、properties、yml等格式的文件直接存储配置信息。如下：

spring:# 模板引擎  thymeleaf:    mode: HTML
    encoding: utf-8
# 禁用缓存    cache: false  jackson:    time-zone: GMT+8
    date-format: yyyy-MM-dd HH:mm:ss
  profiles:     active: druid
# 服务模块  devtools:    restart:# 热部署开关      enabled: true# MyBatismybatis:# 搜索指定包别名    typeAliasesPackage: com.ruoyi.project
# 配置mapper的扫描，找到所有的mapper.xml映射文件    mapperLocations: classpath:mybatis/**/*Mapper.xml
# 加载全局的配置文件    configLocation: classpath:mybatis/mybatis-config.xml

这么做优点是开发简单，部署运维方便，服务部署的节点不会太多，研发完成后只需要打包即可。该阶段的逻辑图如下：

缺点也很明显，每次修改都要打包，而且如果开发环境和测试环境，正式环境配置不一致，打包会比较麻烦。

二、多环境配置打包

本阶段主要解决开发环境多，配置文件动态变化的问题。以Java为例，可以使用Maven结合profile，springboot对于多环境支持更加方便，只需要在打包时指定环境，则自动使用指定的配置文件进行管理。

mvncleanpackage-pdev

对于多环境，只需要将有变化的配置文件提取出来，打包时使用动态命令即可满足上述需求。具体实例会在后续文章中详细讲解。

三、服务化打包

在应用服务化的需求下，部署的节点很多，单个服务打包部署，时间和人力成本非常高，怎么提高效率和防止配置错误问题。这个阶段通常会采用配置中心进行统一管理。应用采用持续集成的方式进行管理，打包后直接部署至对应环境，各应用根据配置中心的配置信息，动态读取信息，更方便高效的管理服务。该阶段的逻辑图如下：

引入配置中心的目的是，应用开发跟配置完全解耦。而且通过配置中心可以实现无感升级，应用不需要重启即可完成配置更新。关于配置中心的使用和案例，会在后续文章中和大家分享。

以上是应用开发过程中，配置文件的软件研发进程中的演进史。技术是业务的支撑，是协助业务实现。“脱离场景谈优化配置都是耍流氓”，针对不同的场景，结合现状，得到最符合当前业务的技术配置架构。对于配置优化，欢迎交流。