先说下我自己理解的什么是配置中心。究其本质是我们人类无法掌控和预知一切，映射到软件领域上，我们总是需要对系统的某些功能特性预留出一些控制的线头，以便我们在未来需要的时候，可以人为的拨弄这些线头从而控制系统的行为特征，我把它叫做 “系统运行时(runtime)飞行姿态的动态调整“。具体可以参考阿里中间件团队的这篇文章一篇好TM长的关于配置中心的文章。简明扼要，一个配置中心必须要做到能动态的获取配置参数，并且当配置发生变更了，能及时准确无误的获取最新的配置。阿里用的配置中心叫diamon，我们点评用的是自研的Lion，本篇文章我们来阅读下Lion的源码。
Lion架构
获取配置流程
上面流程图右边部分就是获取配置的流程，流程图上基本说的很清楚了，这里总结下。
- 本地缓存:先判断是否允许从本地缓存获取，如果可以，从缓存获取，缓存没有的话就从本地配置文件获取
- 本地配置文件:默认文件名applicationContext.properties，没有的话，就从zk获取
- zk:从zk获取，然后更新本地缓存和/data/appdatas/lion/lastWorkingConfig，并注册一个对该zk node的监听watcher。当然如果zk也失败，
就从机器/data/appdatas/lion/lastWorkingConfig获取，另外Lion后台会启动一些线程池来异步的同步或者上传数据。
变更配置流程
上面流程图左边部分是变更配置的流程。
开始在Lion.get(“xxx”)的时候，如果最终是通过获取zk node value，则会注册一个对该node监听的watcher。当该节点的value发生变化时候，会更新该key对应的本地缓存和/data/appdatas/lion/lastWorkingConfig，最终会调用客户端Lion.addConfigListener添加的listener的configChanged方法。
Lion的高可用相关
数据冗余
配置信息显然是很重要的，作为一个分布式配置中心，保存了那么多应用的配置信息，所以数据必须要持久化。我们配置信息不光存在zk上，上面也提到了，每个应用会在自己的/data/appdatas/lion/lastWorkingConfig下面保存应用用到的所有的配置，有多少个key，就有多少个对应的文件名，文件的内容就是key的value。另外后台会开启一个线程池lion-upload-stat-thread:定期把应用使用到的所有配置同步到lion-server端，估计可以作为zk挂了，本地应用磁盘挂了的另外一种备份吧
本地缓存
为了提高性能，减少不必要的访问zk，应用会缓存所有使用的key值，当然也不必担心数据不一致的情况。每次zk节点变化通知到客户端，客户端都会更新本地缓存
推拉结合
配置在发生变更时候，我们需要能及时的获取变更后的配置。目前是依赖zk的push，我们知道zk对网络比较敏感，有可能会发生zk的值变了，但是客户端没有收到通知。Lion客户端也会开启一个线程来定时主动去从zk pull最新的值。
