App配置中心
配置中心的数据结构需要兼顾统一性和个性化。 统一的数据结构是抽象管理逻辑的基础，针对同一的数据结构可以设计出通用的管理界面，存储逻辑。 而具有一定的个性化则能针对不同场景更好的码字业务需求
# 模型
采用Key-List-Object三层数据结构。也就是说配置数据整体是一个Map，Map中每一项都是一个List，而List中的项则不规定数据结构，可以自由发挥。
- Key - 表示模块名
- List - 表示模块数据
- Object - 表示模块中的一条配置项
为了支持版本的需求，还需要设计平台-应用-版本-模块的元信息模型
- 平台 - 如：iOS, Android
- 应用 - 可以支撑多款应用
- 版本 - 即App的软件版本
- 模块 - 对应到数据结构的Key上
元信息模型和数据模型结合起来组成了完整的配置中心数据模型。数据项直接关联应用、版本和模块三个元信息，任意一个获取配置信息请求到达后：
- 提取请求元信息：应用、版本
- 根据应用和版本找到关联的模块列表
- 根据模块列表获取全部相关配置项
- 全部构建成Key-List-Object的结构返回
# 个性化
个性化则体现在配置项上，在Key-List-Object数据结构中对配置项没有硬性的格式要求，所以每一项都可以有其个性结构，只需要满足JSON Schema的要求即可。
这样也可以保证对List没有需求的场景，可以在首个配置项中有最高程度的设计自由度，定义适合业务的结构。
# 多版本修改
为每个配置项设置一个独立的关系，当对某一个版本中的某一个配置项进行查询，同时可以查询到与之关联的其他版本中的项。修改某一个配置项也可以同步到同一个关系下的其他关联项。通过关系解决了对配置信息的关联处理
# 增量更新
任意一个模块发生数据更新后，将向系统提交一次版本更新请求，整个配置版本号加1，配置中心记录了每一次版本变更的模块信息和配置信息的MD5值，当数据请求到达配置中心后，系统将比对当前最新版本和请求上行的App本地版本，并计算出版本差之间发生变更的模块数据，构造一次增量数据返回。
为保证客户端最终生成的配置与服务端保持一致，客户端在做增量更新后，用该配置生成MD5值，与服务端下发增量更新时写打的最新配置的MD5值进行比较，在一致的情况下采取缓存配置，避免因为增量更新造成App无法使用。
# 站点
查询全部配置信息
查询模块配置信息
添加和编辑配置内容
导入配置
# 客户端
客户端应用配置中心组件实现以下功能
提供检查配置信息更新的API给App在启动的时候选择在合适位置检查更新，组件并从本地读取缓存信息到内存
- 本地无配置信息版本号，拉取此版本全量配置信息
- App版本号比缓存App版本号大，拉取新版本全量信息
- 服务端返回App版本增量更新配置后，更新内存中配置信息（Key-List-Object），并计算MD5和返回的是否一致，如果一致将内存中配置缓存到本地，不一致则重新从本地缓存读取到内存中
提供查询配置信息的API给业务模块使用，
- 根据业务模块查看业务模块下所有配置项信息
- 根据业务模块和配置信息唯一名称查询配置项信息
组件缓存App版本号、配置版本号、配置信息（Key-List-Object），其中App版本号和配置版本号用于检查更新
注意：在进行增量更新的过程中，使用MD5进行校验不一定准确，因为配置json信息有引号、格式和顺序的差异，都会导致MD5变化。在实际使用过程中这一块的安全性校验暂时忽略了。