背景
Ponf的全称是Planet‘s Configuration的缩写，是为了当时代号星球项目专门编写的分布式配置中间件。
问：市面上已经有很多配置中心了，为什么要专门做一个配置中间件？
答：因为星球项目是源于老VIP项目的升级，它的目标是将VIP从一个单体项目（一套程序多机部署）升级为微服务项目，以解决团队快速增长，项目难以管控的问题。但升级不是一步到位的，要兼容之前的数据和代码，同时还要保证升级过程循序渐进不能耗费太多人力。
而在VIP项目中有一个非常复杂的配置系统，数据大概有几个G。我们的目标是不下线原本的配置系统，同时为微服务提供高效简介的配置服务。因此需要兼容原有的配置功能，同时还要进行微服务改进。
Ponf要解决的问题
原来配置服务存在的问题：
- 逻辑简单粗暴，每五分钟扫描Mysql获取全量配置，并全量分发给所有服务。
- 使用Thrift进行通讯，在目前微服务统一使用Dubbo进行通讯的背景下，又引入Thrift会增加学习成本。
- 原配置服务为单体服务，一旦出问题所有服务奔溃。
Ponf要解决的问题：
- 兼容原来配置服务数据（Mysql），同时可以使用原配置页面进行配置
- 开箱即用，提供最简单的get接口，让用户不需要理解任何实现原理
- 完全使用分布式架构，不再存在单点问题
- 高性能，高时效性
- 保证数据的一致性（原配置使用Mysql自然能保证完全的一致性，而Ponf的目标是实现时间一致性和最终一致性，时间一致性指的是在Ponf只能看到某一时间之前的数据，而不会既看见之前的数据又看到之后的数据）
- 使用Dubbo
方案
这是一套简单而又高效的方案，虽然不是完美的配置系统，但是是最适合星球项目的方案。
首先在Ponf中有多个ConfigServer，他们都注册为Dubbo服务，给所有客户端提供服务。同时ConfigServer无状态，所有的客户端可以任意选择自己的ConfigServer，也可以随时切换。
流程：
- 客户端发送心跳到ConfigServer，内容为客户端配置Version
- ConfigServer回复Version
- 客户端检查Version是否一致，若一致则等待下次心跳发送。
- 若不一致，则将自己所有的配置key的ID，以及每个Key对应的Version发送给ConfigServer（使用ID节约空间）
- ConfigServer将Version落后的Key的Value发送给客户端
- 客户端完成更新
若客户端业务程序在获取一个本地没有缓存的Key时，执行上面的4-6（这是比较耗时的操作，建议初始化时把key注册上）。当然如果业务不需要时间一致性，也可以直接获取。
ConfigServer内部逻辑，这里主要讲ConfigServer如何通过无锁的方式提供快照。
ConfigServer会定时从MySQL中获取最新的配置，首先先获取最新的Version，如果Version等与当前Version则不更新。
否则拉去所有Version大于ConfigServer的Version的数据。
在ConfigServer的配置存储在Config类中
class Config{
Map<String,ConfigEntity> entities;
Config prev;
}
class ConfigEntity{
String value;
int id;
int version;
}
当ConfigServer启动时会创建第一个Config，将所有配置存储在entities中。
之后配置更新时，新创建一个Config，将更新的配置存储在新的entity中，并将prev指向之前的Config。
然后使用Copy On Write的方式替换全局Config的引用。
当进行配置查询时看，ConfigServer会先查询当前Config，如果Key不存在再查询prevConfig。
当然如果单是这样，Config链表会越来越长，那么配置读取的性能也会变差，因此每隔一定时间，就会将链表进行Merge，然后再通过Copy On Write的方式替换掉原来的Config。
这样就完成了ConfigServer的快照读，由于完全不加锁，所以性能很好！
