CAP
CAP 理论
现在大部分主流而且在使用中的注册中心都是满足 CP 的，但是在互联网大集群环境下，期望的结果是满足 AP 的同时，能够满足最终一致性。在大集群环境下，可用性往往比强一致性的优先级更高。以 Zookeeper 为例，Zookeeper 能够为分布式系统提供协调功能的服务，默认提供强一致性的数据服务，但是它在某些情况下是允许 Zookeeper 是不可用的。
列举一个场景,Zookeeper Leader 失效了，这时需要重新选举 Leader，而这个选举过程需要30 秒以上 (数据来自于网上的文章)，这段时间内 Zookeeper 对外是不可用的。
总结
1.满足CP
满足强数据一致性，因为是中心化的，leader只有一个。
满足容错，因为集群节点具有自恢复能力，即如果leader节点挂了，会选择Leader节点。
2.不满足A
不满足高可用，因为Leader挂了，要选举的这段时间(30s)，是不可用的。
leader节点
去中心化：Zookeeper 是有 Leader 机制，往 Zookeeper 里写数据都是往 Leader 里面写，这个 Leader 其实就是一个单点。所以整个写的过程是中心化的。而且 Zookeeper 对跨城跨机房的方案上，支持非常有限。
总结
是中心化的，即注册中心只有一个节点是leader节点，也只有这个leader节点对外提供服务，其他节点只是对内用于选举，不能对外提供服务，这样太浪费了。
watch机制/服务器主动推送数据机制/主动通知机制
数据推送的强控制：期望对推送的有更加强的灵活性。还是以 Zookeeper 为例，Zookeeper 中有 watch 机制，每个数据节点发生变更的时候，就会往外推送变更的通知。但是作为注册中心，我们期望能够控制它的推送频率，针对新增节点只需要一分钟里面推送 6 次就可以了，每十秒推送一次，这样可以合并一些变更通知，减少网络数据请求的数据量。
总结
可以配置推送更新数据的通知频率，而不是每次更新都通知到消费者。
为什么要控制呢？因为大型互联网应用的单个服务集群数量是非常吓人的，可能有千位数的量级，如果这个时候去推送数据，那么推送数据量就是 千位数*千位数 * 2 量级的数据，达到几百G，甚至T级别的数据，这么大量级的数据都不是业务数据，所以在网络/网卡传输的过程当中很可能影响正常业务数据的网络传输。
发展规划和发展趋势
前段时间和网易考拉在沟通过程中也发现，他们也在做一个自己的注册中心；新浪也有一个自己的服务注册中心。所以许多大的互联网公司，因为定制或者差异化的需求，都在自研注册中心。
总结
由于各种原因，即zookeeper的不完美，很多互联网公司会结合自身业务特点进行自研注册中心。
三个中心
总结
1.注册中心 //ip/port
2.元数据中心 //方法名字、方法参数名字
3.配置中心 //应用配置信息
