基础
zookeeper（Dubbo通常选型）：
Leader+Follower两种角色
只有Leader可写（服务注册），并同步数据给Follower；
读时，Leader/Follower都可以读
Euraka（Spring Cloud通常选型）:
peer-to-peer，部署一个集群，集群中每个机器地位是对等的；
各服务可以向任何一个eureka实例进行服务注册和服务发现；
集群中任何一个eureka实例收到写请求后，会自动同步给其他所有eureka实例
两者对比
一致性报障：CP or AP
zk：有leader接收数据，并同步其他节点。如果leader挂掉，要重选leader，不可用一段时间；为了保证C，牺牲A。
eureka：peer模式，可能还没数据同步过去，自己先挂掉；此时可以从其他机器拉取注册表，但是看到的不是最终数据，所以保证了可用性，最终一致性。
服务注册发现时效性：
zk： 时效性更好，秒级就可感知到
eureka： 默认配置糟糕，服务发现感知要几十秒，甚至分钟级别。上线一个服务实例，到其他人可发现，极端情况下，可能要1min时间（跟内部架构有关，有定时同步机制），ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡你。
服务故障：隔60s才取检查心跳，发现这个服务上次心跳是60s前，隔60s再去检查心跳，超过90s无心跳才认为服务挂掉。
三分钟都过去了，如果你的服务实例挂掉了，此时别人感知到，可能2到3min时间。一般1~2min时间就已很漫长。
容量：
zk： 不适合大规模服务实例，因为服务上下线需要瞬间推动数据通知到所有其他服务实例，一旦服务规模扩大，几千实例时会对导致网络带宽被大量占用。
eureka： 也很难支撑大规模服务实例，每个eureka实例都接受所有请求，实例多了压力大扛不住，也很难到几千级别。