以前在做服务推送时候，用过zk来作为内部的服务发现，对zk的只限于使用。这几天把zk又重新看了一遍，愈发感觉zk并不适合做服务发现，
- 首先一点内部的2PC机制，就会导致效率跟不上高并发的场景，
- 再一个zk基于CP理论设计，那么发生脑裂时候，导致新服务不能接入，老服务上下线不能注册去注册，
- 最后一点他的保活机制有些缺陷，如果服务假死了那么负责保活的线程还活着，那么会出现判断不准确的问题。
另外使用起来，官方提供的zkclient包并不是很完美，最起码内部没有集成相关缓存。当然也可以自己开发zkclient。还有一个关键点，zk往往用在分布式系统中，但zk自身又是一个中心系统，所有的系统都得围绕zk运行，感觉有点反转的意味。
此外看了很多人推荐的etcd，确实比zk要好很多，不管是通信机制还是自身监控，都要优于zk。但etcd系统也是基于cp模型设计，同样也是一个分布式系统里的中心系统。
于是干脆自己造轮子吧。
- 是基于AP模型。
- 不能做重中心，协议用gossip协议，rediscluster用的也是这个协议，这个协议比较有趣和病毒传播一样，无中心化。
- 需要一个可视化的界面能够看到相关监控，结合相关业务提供一个指令下发服务，方便操作集群内部的服务，比如下发熔断指令重启指令等等。
- 数据分为元数据和自定义数据，元数据包括服务ip，port，url，status，updateTime, version, serverName, method. 数据是否需要落盘这块儿，考虑了下没这个必要，如果注册中心集群全部挂掉，那么plugin应该有备份，这个时候是不影响业务的。 如果集群中单个注册中心挂掉，重启后会很快同步回来。因此注册中心是不需要落盘数据，而服务管理平台需要落盘相应的数据。
- 保活机制，完美的方式应该是由调用方来报告业务服务是否存活，比如网关层调用业务服务发现业务服务出问题向注册中心进行报告，同时网关层进行相应的熔断处理。这块儿主要是业务逻辑处理方面的事儿， 先保留心跳机制。整个逻辑是心跳和上报同时存在，以上报的为准，心跳为辅。
ccc 控制中心客户端---管理平台使用
ccs 控制中心服务
ccp 控制中心插件---业务服务使用
smp 服务管理平台