eureka与zookeeper的区别

在传统应用中，组件之间的调用，通过有规范的约束的接口来实现，从而实现不同模块间良好的协作。但是被拆分成微服务后，每个微服务实例的网络地址都可能动态变化，数量也会变化，使得原来硬编码的地址失去了作用。需要一个中心化的组件来进行服务的登记和管理。

一、eureka

1、本质：存储了每个客户端的注册信息。EurekaClient从EurekaServer同步获取服务注册列表。通过一定的规则选择一个服务进行调用。

2、Eureka构架图

 3、详解

服务提供者：是一个Eureka Cient，向Eureka Server注册和更新自己的信息，同时能从Eureka Server注册表中获取到其他服务的信息。

服务注册中心：提供服务注册和发现的功能。每个Eureka Cient向Eureka Server注册自己的信息，也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。

服务消费者：是一个Eureka Client，通过Eureka Server获取注册到其上其他服务的信息，从而根据信息找到所需的服务发起远程调用。

同步复制：Eureka Server之间注册表信息的同步复制，使Eureka Server集群中不同注册表中服务实例信息保持一致。

远程调用：服务客户端之间的远程调用

注册：Client端向Server端注册自身的元数据以供服务发现。

续约：通过发送心跳到Server以维持和更新注册表中服务实例元数据的有效性。当在一定时长内，Server没有收到Client的心跳信息，将默认服务下线，会把服务实例的信息从注册表中删除。

下线：Client在关闭时主动向Server注销服务实例元数据，这时Client的服务实例数据将从Server的注册表中删除。

获取注册表：Client向Server请求注册表信息，用于服务发现，从而发起服务间远程调用。

4、服务注册与发现包括两部分，一个是服务器端，另一个是客户端。

4.1 Server

Server是一个公共服务，为Client提供服务注册和发现的功能，维护注册到自身的Client的相关信息，同时提供接口给Clinet获取注册表中其他服务的信息，使得动态变化的Client能够进行服务间的相互调用。

• 接受服务注册

• 接受服务心跳

• 服务剔除

• 服务下线

• 集群同步（1.启动时从peer拉取信息，2.将注册到自己的服务同步到peer）

4.2 Client

Client将自己的服务信息通过一定的方式登记到Server上，并在正常范围内维护自己信息一致性，分别其他服务发现自己，同时可以通过Server获取到自己依赖的其他服务信息，完成服务调用，还内置了负载均衡器，用来进行基本的负载均衡。

• 拉取server注册表到本地。

• 注册服务。

• 初始化3个定时任务：心跳续约，定时拉取注册表，按需注（InstanceInfoReplicator#run）。

5、Eureka保证AP

可以通过运行多个Eureka server实例并相互注册的方式实现。Server节点之间会彼此增量地同步信息，从而确保节点中数据一致。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩下的节点依然可以提供注册和查询服务。Eureka的客户端在向莫哥Eureka服务注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就会认为客户端与注册中心出现网络故障，此时会出现以下几种情况：

（1）、Eureka不再注册列表中移除因为长时间没收到心跳而应该过期的服务。

（2）、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）

（3）、当网络稳定时，当前实例信的注册信息会被同步到其他节点中。

6、Eureka优化

  server:
      # 自我保护，看服务多少。
    enable-self-preservation: false
    # 自我保护阈值
    renewal-percent-threshold: 0.85
    # 剔除服务时间间隔
    eviction-interval-timer-in-ms: 1000
    # 关闭从readOnly读注册表
    use-read-only-response-cache: false
    # readWrite 和 readOnly 同步时间间隔。
    response-cache-update-interval-ms: 1000

7、zookeeper（保证CP）

zookeeper的设计就是保证数据（配置数据、状态数据）在多个服务系统之间保证一致性，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30到120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能勾最终恢复，但是漫长的选举时间导致的注册长期不可用事不能容忍的。