图文：摄于2015年湍口，危机四伏的密林深处

连载篇，继续唠DevOps。

在上一篇中谈到了「敏捷文化」，很多朋友质问我，上来就谈所谓“文化”太虚了吧，这不像你的风格啊。可我想说的是，在DevOps的路上，每天让我们感到最困难的，其实不是技术攻关，也未必是业务场景，而恰恰是敏捷思路与传统观念的转变。

技术，可以一针见血，无非出血量的多少罢了。

思路，只能慢慢培养，和谈恋爱其实差不多，开房很容易，但能一见面这就结婚吗？当然，这也可以，这却增加了离婚的可能性。

其实没什么，就是写写心得罢了。

当然，这种回复被身边的朋友叫做「这B装的我们给100分」「说不过你」。对此我来了个广告「请关注下一篇」。

没有DevOps之前，配置文件是怎么玩的呢？

在「群雄割据」的时代里，通常一个Jar或一个War就可以打天下，以Spring+properties为例，对配置文件的适用场景基本可分为两种类型：

配置文件位于classpath下

使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件，通过源码可以知道，默认加载的是classpath下的文件，配置如下：

如果有多个配置文件加载，则：

配置文件位于外部目录

但是对于外部目录的配置文件，使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的，不过要修改他的路径配置方式，如下：

这样就可以成功加载外部目录的配置文件了，${user.dir}是系统变量，指用户当前目录所在。

当我们从「群雄割据」来到「天下一统」的时期后，虽然DevOps提升了交付效率，越来越满足快速试错的原则，可随之而来的「技术污染」却与日体现：

…………

配置文件的版本如何与程序版本对应？

配置文件的管理如何更加简便？

配置文件的修改该有谁来操作？

配置文件的更新是否可以不影响正常服务？

…………

无论哪一项污染，只会与DevOps扯上关系，都是让人头痛不已。

撸起袖子，不要怂，咱们搞个配置中心吧。

有了DevOps之后，配置文件又是怎么玩的呢？

其实想通过DevOps获得业务收益，无论从哪个环节启动，都将是一场持久战。

随着系统产品化的改造，通过DevOps流水线的快速交付通道，任何一个交付版本都可以通过CI与CD环节后，利用自动化部署工具，轻松地完成升级或发布；

这段看似美妙的诱惑，首先挡住去路的，就是配置文件的使用与加载方式。

如果不将配置信息外移至配置中心，在DevOps中会出现哪些问题呢？

图1：配置中心在DevOps快速交付通道中

你不是常说你们的场景都是持续污染的吗？谈谈如何在污染环境下接入吧

的确，在整个接入过程中可以说是一波三折，原因很简单，之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案，现在你说统一就统一？

无法满足我要求的，我不接

这话表面看起来有些生硬，不过想想挺有道理的，所以在配置中心的方案中，我们提出了“三种适配器，两种推进器”的理念。

三种适配器

图2：适配器Trade，满足原有使用Properites的诸侯们

图3：适配器Native，满足已使用过自研独立配置服务的诸侯们

图4：适配器Ccms，满足使用Key/Value的诸侯们

两种推进器

图5：希望采用 “文件被动加载” 的诸侯们

图6：希望采用 “Key/Value实时推送” 的诸侯们

从某种角度来说，就算没有配置中心的存在，我相信DevOps的推进也会顺理成章，只不过相对不会如此平滑，或多或少给未来造成风险

有了配置中心，诸侯们的确享受到了福利：

写到这里，太阳出来了

每次在结束语中都会诉诉苦，不过年末的各种事项的确有点打乱节奏，写作时间也随之调整到了工作日的清晨6点-8点之间，所以效率与质量也或多或少受到影响。

本文主要讲述围绕配置信息管理和使用在DevOps过程中的那点事，所以对配置系统自身的原理与技术实现并未做详细的描述，如对这块有兴趣，欢迎大家在留言区中提出，我将通过独立的整篇文章加以叙述。

| 本系列连载文章

感谢您的阅读

您的支持是我最大的前进动力

ITPub博客

我们实施DevOps的挑战之二 -- 配置文件的困惑