演进中的配置
当我们是一个单机服务的是，我们的配置通常写在一个文件中的，代码发布的时候，把配置文件和程序推送到机器上去。 
当随着业务的用户量增加，通常我们会把我们的服务进行多机器（集群）部署。这时候，配置的发布就变成了如下： 
业务的急剧扩张，导致单机服务无法满业务需求。这时候需要对单体大服务进行切开，服务走向SOA(微服务化)。 
这种场景中，配置文件的部署可能如上图所示。这样去部署配置简直是一场噩梦，而且无法做到快速的动态的调整。失去了配置主要意义之一。这时候就需要今天说的统一配置中心。
配置中心之简版
首先来看下我们理想中的配置中心需要具备哪些特点。
配置的增删改查
不同环境配置隔离（开发、测试、预发布、灰度/线上）
高性能、高可用性
请求量多、高并发
读多写少
我们可以设计出如下的简版配置中心
设计说明点：
-
通过OA系统对每一条配置（每一个配置有唯一的配置ID）进行增删改查。
区分不同环境的配置，每个环境同一配置ID对应不同数据库记录。
配置最终以json格式（便于编辑和理解）储存在mysql数据库中。
引入redis集群，做配置的缓存（比如可以设置配置修改后1分钟后生效）
配置对外服务，多机器部署，满足性能需要。
如果有必要，可以引入配置历史修改记录。
很多时候，这样可以基本上满足我们对配置系统的基本需求。
这种设计，由于所有的配置都存放在集中式缓存中，这样集中式的缓存也会有他的性能瓶颈。而且，每次配置的访问都需要发起rpc请求(网络请求)，因此考虑在客户端引入本地缓存的选择及其原理（localCache，例如Ehcache）。
配置中心之性能改进
为了提高配置中心的可用性，减少网络请求等因素对性能带来的影响，我们考虑在客户端引入localcache，来解决系统的高可用，高性能、可伸缩性。 
相对于第一版的改进点是，在客户端引入localcache。开启线程异步调用配置服务，更新本地配置。这样可以减少rpc调用。
这种方式较为简单，但是存在一个问题，就是一旦用户量大的时候，会增加很多无意义的轮询。因为配置中心的定位就表明了他的修改并不会很多，所以大多数情况下的轮询都是无意义的。会给缓存系统增加很多无谓的压力。
同时，由于各个客户端的拉取时间及网络延迟等都不尽相同，也会存在数据一致性的问题，
配置中心之可用性改进
还好，配置通常都只会有一个入口修改，因此可以考虑在配置修改后，通知应用服务清理本地缓存和分布式缓存。这里可以引入mq或ZooKeeper。 
感兴趣的朋友可以了解下阿里巴巴的Diamond，他的工作原理就是这种通过推拉结合的方式，减少不必要的轮询，并且可以降低缓存系统的负载。