前情概要：
配置中心概述
这篇文章是微服务化改造系列的第三篇，主题是配置中心。上一篇我们谈到服务注册中心，即通过提供某种注册和发现的机制，解决服务互通的问题。那么问题来了，一个服务如何知道服务注册中心的地址呢？这就涉及到服务配置了。我们知道，大至一个PaaS平台，小至一个缓存框架，一般都依赖于特定的配置以正常提供服务，微服务也不例外。
配置分类
-
按配置的来源划分，主要有源代码（俗称hard-code），文件，数据库和远程调用。
-
按配置的适用环境划分，可分为开发环境，测试环境，预发布环境，生产环境等。
-
按配置的集成阶段划分，可分为编译时，打包时和运行时。编译时，最常见的有两种，一是源代码级的配置，二是把配置文件和源代码一起提交到代码仓库中。打包时，即在应用打包阶段通过某种方式将配置（一般是文件形式）打入最终的应用包中。运行时，是指应用启动前并不知道具体的配置，而是在启动时，先从本地或者远程获取配置，然后再正常启动。
-
按配置的加载方式划分，可分为单次加载型配置和动态加载型配置。
演变
随着业务复杂度的上升和技术架构的演变，对应用的配置方式也提出了越来越高的要求。一个典型的演变过程往往是这样的，起初所有配置跟源代码一起放在代码仓库中；之后出于安全性的考虑，将配置文件从代码仓库中分离出来，或者放在CI服务器上通过打包脚本打入应用包中，或者直接放到运行应用的服务器的特定目录下，剩下的非文件形式的关键配置则存入数据库中。上述这种方式，在单体应用阶段非常常见，也往往可以运行的很好，但到了微服务阶段，面对爆发式增长的应用数量和服务器数量，就显得无能为力了。这时，就轮到配置中心大显身手了。那什么是配置中心？简单来说，就是一种统一管理各种应用配置的基础服务组件。
可选框架
选型一个合格的配置中心，至少需要满足如下4个核心需求：
