zookeeper和eureka有什么不同

当年许多企业级应用一般都会面临着以下难题：

1）用户数量越来越多，导致接入设备成本越来越大

2）业务体量和复杂程度不断增加

3）数据趋于海量，处理难度加大

4）安全环境也受重视
所以，随着代码量和愈渐复杂的需求，单体应用的关系也变得纷繁杂乱，导致开发测试和维护也难以为继。
至此，我们将单体应用拆分成面向服务的架构（SOA）即分布式架构；
分布式架构（SOA）系统是将其组件分布在联网的计算机上，在组件与组件之间通过传递消息进行同信和动作协调的系统 ，一个服务通常以独立的行驶存在于操作系统进程中。
而在SOA之下，为了满足更为强健的业务需求，我们又在SOA的基础至上做了升华，即微服务架构（MSA）；
为服务架构（MSA）一定是一个分布式架构，但反过来分布式架构并不一定都是微服务架构，MSA相对于SOA它强调的是“业务需要彻底的组件化和服务化”。
在一个分布式系统中，需要满足CPA理论，包括一致性（Consistency）+ 分区容错性（Partition tolerance）+ 可用性（Availability），但是，这三个要素不可能同时满足C（一致性）、P（分区容错性）和A（可用性），最多只能同时实现两点，不可能三者兼顾。
对于互联网来说，由于网络环境是不可信的，所以分区容错性（P）在分布式系统中是必须要保证的，因此我们只能在A和C之间权衡。故在此Zookeeper保证的是CP，而Eureka则保证的是AP。正常情况下，为了满足用户体验，应该先选可用性。

        Consistency（一致性）
    由于分布式环境存在多个节点，这些节点上的数据在同一时间所存储的数据必须是一致的，这就是一致性协议。
        Availability（可用性）
    可用性很好理解，任何时刻需要保证服务的可用和稳定。
        Partition Tolerance（分区容错）
    所谓分区容错是指某个时刻出现网络或者硬件不可用，甚至宕机，其它的机器还能保证正常可用。

Zookeeper：
Zookeeper采用CP保证数据的一致性的问题，原理采用Zab原子广播协议，当zk因为某种原因（如：master节点因为网络故障与其他节点失去联系）宕机的情况下，会自动触发重新进行leader选举，问题在于，为了保证选举过程中数据的一致性问题，选举leader的时间会过长，30s~120s，并且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。意味着微服务采用该模式情况下，可能无法实现通讯（本地有缓存除外）。
在云部署的环境下，因网络问题导致的Zookeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka：
Eureka 是 Netflix 在线影片公司开源的一个服务注册与发现的组件，和其他Netflix 公司的服务组件（例如负载均衡、熔断器、网关等） 一起，被Spring Cloud 社区整合为Spring Cloud Netflix 模块，提供相应的JAVA封装类。
Eureka各个节点都是平等的，节点之间相互平等，部分注册节点挂掉不会对集群产生影响，发现连接失败会自动切换至其他节点，剩余的节点依然可以提供注册和查询服务，即使只剩下一个节点，也可以正常的提供发现服务（保证可用性），但是查到的信息可能不是最新的（不保证强一致性）。
此外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

    Eureka不再从注册列表中溢出因为长时间没有收到心跳而应该过期的服务。

    Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）。
    当网络稳定时，当前实例新的注册信息会被同步到其他节点中。
在微服务的开发过程中，如果使用的是 Dubbo 那就必须使用到 Zookeeper ，在使用 Spring Cloud Eureka 时，自然其功能更强大得多。 而且Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
配置Eureka时可使用如下参数，可启动保护机制：
eureka.server.enable-self-preservation=true（当Eureka Server节点在短时间内丢失过多客户端时，那么这个节点将进入自我保护模式，不在注销任何微服务。网络稳定后自动退出自我保护模式）

最后我们总结一下，
Eureka基于AP， 注重服务的可用性，即使所有机器都挂了，也能拿到本地缓存的数据，保证高可用。
Zookeeper基于CP， 注重数据的一致性，若主机挂掉则zk集群整体不对外提供服务了，需要选一个新leader的出来（120s作用）才能继续对外提供服务，不保证高可用。