1. 注册中心是 CP 还是 AP 系统     Eureka作为AP更适合服务注册中心；当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪；    Eureka  如果有节点挂掉， 剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 
    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
    2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 
    3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
  2. 当下，云部署服务越来越流行，出现网络分隔的情况变多（不同子网的网络互相不通信）；但是Eureka可以在自己独自子网继续提供服务
  3. 注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律
  4. 当数据中心服务规模超过一定数量 (服务规模=F{服务pub数,服务sub数})，作为注册中心的 ZooKeeper 很快就会像下图的驴子一样不堪重负
  5. 注册中心需要持久存储和事务日志     服务调用并不关注注册中心的本身节点的变化情况；只想关注提供服务的节点的一些元数据（比如中心标识、路由等）
  6. 健康检查，并不只是tcp链接的互通检查，真正关注的是服务的有效性
  7. 注册中心的容灾考虑  服务调用（请求响应流）链路应该是弱依赖注册中心，必须仅在服务发布，机器上下线，服务扩缩容等必要时才依赖注册中心
  8. zookeeper种种坑  难以掌握的Client/Session状态机