Eureka原理分析

https://blog.csdn.net/JinXYan/article/details/90721953

• Zookeeper保证CP，在云部署的环境下，
  • 因网络问题使得zk集群失去master节点是较大几率会发生的事，
  • 虽然服务可以最终恢复，
  • 可是漫长的选举时间致使的注册长期不可用是不能容忍的。

• Eureka保证AP，在Eureka平台中，

  • 多个Eureka Server之间经过P2P复制的方式完成服务注册表的同步
  • 若是某台服务器宕机，Eureka不会有相似于ZooKeeper的选举leader的过程；
  • 客户端请求会自动切换 到新的Eureka节点；
  • 当宕机的服务器从新恢复后，Eureka会再次将其归入到服务器集群管理之中；
  • 而对于它来讲，全部要作的无非是同步一些新的服务 注册信息而已。
  • 因此，不再用担忧有“掉队”的服务器恢复之后，会从Eureka服务器集群中剔除出去的风险了。
  • Eureka还有一种自我保护机制，
    • 若是在15分钟内超过85%的节点都没有正常的心跳，
    • 那么Eureka就认为客户端与注册中心出现了网络故障，
    • 此时会出现如下几种状况：
      • Eureka再也不从注册列表中移除由于长时间没收到心跳而应该过时的服务
      • Eureka仍然可以接受新服务的注册和查询请求，可是不会被同步到其它节点上(即保证当前节点依然可用)
      • 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
      • 所以， Eureka能够很好的应对因网络故障致使部分节点失去联系的状况，
        • 而不会像zookeeper那样使整个注册服务瘫痪。