Eureka和Zookeeper在服务注册方面的区别

	服务注册发现原理	一致性保障-CAP原理	服务注册发现的时效性	容量
zookeeper	集群中分为1个leader其他的机器为follower，只有leader能够进行写操作，即服务注册，然后把数据同步给follower，leader/follower都可以进行读	保证CP，即一致性，当zk集群中的leader挂掉，会重新进行leader的选举，在此期间整个集群处于不可用状态，直到选举出leader	时效性更好，注册或者挂了，一般秒级就能感知到	zk不适合部署大规模服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例（consumer），所以一旦服务规模太大，到了几千个机器的时候，会导致网络带宽短时间被大量占用
erueka	peer-to-peer,集群中每台机器的地位是相等的，各个服务可以向任何一个Eureka实例进行服务注册和服务发现，集群里任何一个Eureka实例接收到写请求之后，会自动同步给其他所有的Eureka实例	保证AP，一台Eureka刚接受到服务注册信息没来得及同步到其他实例就挂了，其他实例依然可以提供服务发现功能，只不过数据不是最新的，只能保证最终一致性	默认配置下，服务发现和感知需要十几秒甚至分钟级别	eureka也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求

为什么zk时效性好

zk的客户端可以在znode上创建watch对象，用于监听znode的相关事件 新增子node、修改、删除等，当发生事件时会及时获得通知。
而eureka采用多级缓存，定时轮询等存储更新服务列表，所以时效性相对较差