对于配置文件，我们不陌生，它提供我们可以动态修改程序运行能力。引用别人的一句话就是：
系统运行时(runtime)飞行姿态的动态调整
我可以把我们的工作称之为在快速飞行的飞机上修理零件。我们人类总是无法掌控和预知一切。对于我们系统来说，我们总是需要预留一些控制线条，以便在我们需要的时候做出调整，控制系统方向（如灰度控制、限流调整），这对于拥抱变化的互联网行业尤为重要。对于单机版，我们称之为配置（文件），对于分布式集群系统，我们称之为配置中心（系统）;下面聊聊我们的配置中心。
他山之石
- 配置中心Lion：http://yeming.me/2017/11/27/lion/
- Apollo配置中心介绍：https://github.com/ctripcorp/apollo/wiki/Apollo配置中心介绍
- QConf搭建配置中心：https://segmentfault.com/a/1190000008949515
- 动态调整的基础 —— 配置中心：http://pingguohe.net/2016/03/18/config-center.html
- 一篇好TM长的关于配置中心的文章：http://jm.taobao.org/2016/09/28/an-article-about-config-center/
演进中的配置
当我们是一个单机服务的是，我们的配置通常写在一个文件中的，代码发布的时候，把配置文件和程序推送到机器上去。
当随着业务的用户量增加，通常我们会把我们的服务进行多机器（集群）部署。这时候，配置的发布就变成了如下：
行，这样发配置也能接受
业务的急剧扩张，导致单机服务无法满业务需求。这时候需要对单体大服务进行切开，服务走向SOA(微服务化)。
这样去部署配置简直是一场噩梦，而且无法做到快速的动态的调整。失去了配置主要意义之一。这时候就需要今天说的统一配置中心。
配置中心之简版
配置中心的特点
- 配置的增删改查
- 不同环境配置隔离（开发、测试、预发布、灰度/线上）
- 高性能、高可用性
- 请求量多、高并发
- 读多写少
我们可以设计出如下的简版配置中心
设计说明点：
- 通过OA系统对每一条配置（每一个配置有唯一的配置ID）进行增删改查。
- 区分不同环境的配置，每个环境同一配置ID对应不同数据库记录。
- 配置最终以json格式（便于编辑和理解）储存在mysql数据库中。
- 引入redis集群，做配置的缓存（比如可以设置配置修改后1分钟后生效）
- 配置对外服务，多机器部署，满足性能需要。
- 如果有必要，可以引入配置历史修改记录。
很多时候，这样可以基本上满足我们对配置系统的基本需求，对配置的增删改查，能容忍一段时间的数据不一致性。
这种设计，由于所有的配置都存放在集中式缓存中，这样集中式的缓存也会有他的性能瓶颈。而且，每次配置的访问都需要发起rpc请求(网络请求)，因此考虑在客户端引入本地缓存（localCache，例如Ehcache）。
本地缓存可以参考我之前文章：【180409】本地缓存的选择及其原理
配置中心之性能可用性改进
考虑到，减少网络请求的因素，在客户端引入localcache，来解决系统的高可用，高性能、可伸缩性。
相对于第一版的改进点是，在客户端引入localcache。开启线程异步调用配置服务，更新本地配置。
这样可以减少rpc调用。
基于数据的CAP原理，该方式只做到了AP，这里会存在数据的一段时间的不一致性，但最终会保证是配置的最终一致性。如何解决这个数据不一致性问题？
配置中心之数据一致性改进
还好，配置通常都只会有一个入口修改，因此可以考虑在配置修改后，通知应用服务清理本地缓存和分布式缓存。这里可以引入mq或ZooKeeper。
最后通过，推拉相结合的方式，完成数据的一致性。
都看到这里了，成神之路上，要不要一起？
