注册中心Eureka简介

Eureka概要

如图所示，Eureka注册中心，包含服务端（Eureka Server）和客户端（Eureka Client）。客户端分为服务消费方和 服务提供方。
服务端提供的功能包括：
服务注册：客户端启动时，会向服务端注册服务，服务端会存储和维护这个服务列表（注册表）
提供注册表：提供注册表给客户端
自我保护机制：为了防止因网络故障导致的误注销情况，eureka server会统计15分钟内超过一个阈值(默认85%)的客户端节点都没有正常的心跳，那么就认为出现了网络故障，启动自我保护机制。

进入自我保护机制之后：
1 服务端不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2 服务端仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上
3 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。

客户端具备的功能包括：
服务注册：将自身的ip地址，端口号，运行状况等信息发送到服务端进行注册
Renew服务续约：默认每隔30S，发送一次心跳完成续约。如果服务端在90秒内没有收到客户端的续约，会从注册表将其删除。
     eureka.instance.lease-renewal-interval-in-seconds=30
     eureka.instance.lease-expiration-duration-in-seconds=90
Cancel服务下线：客户端下线时，会向服务端发送下线请求
远程调用：客户端（消费方）从服务端获取服务提供方api信息之后，可以通过http请求调用相应api，提供方有多个时，可以通过feign实现负载均衡。
注册表缓存：客户端从服务端拉取注册表后，会缓存相应的信息。因此即便服务端宕机了，服务消费方依然可以通过http调用服务提供方的api（前提是服务提供方正常）。但是，服务列表更新时，会出现信息不一致。

Eureka和Zookeeper的简单比较

CAP定理指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。但选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP。各个Server节点都是平等的，一部分挂了，剩余的节点依然可以提供服务，保证分区容错性（P）。而 Eureka Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性A)，只不过查到的信息可能不是最新的(不保证强一致性C)。