Eureka详解

服务提供者

服务注册

服务提供者在启动的时候会通过发送rest请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server收到这个请求之后，将元数据信息存储在一个双层Map中，其中第一层key是服务名，第二层key是具体服务实例名。

服务同步

由于服务注册中心互相注册为服务，当服务提供者发送注册请求到服务注册中心，它会将该请求转发给集群中其他注册中心，从而实现注册中心之间的服务同步。

服务续约

服务注册完成后，服务提供者会维持一个心跳进行服务续约，间隔时间默认为30秒，服务失效时间默认为90秒，如果服务失效，服务注册中心将该实例从服务列表中剔除，并同步给其他注册中心

服务消费者

获取服务

当服务消费者启动时，将向注册中心发送一个rest请求，来获取服务清单，为了性能考虑服务注册中心会维护一份只读的服务清单来返回给客户端，该缓存默认30秒更新一次

服务调用

服务消费者在获取清单后，通过服务名可以对服务提供者进行调用，Ribbon默认采用轮询的方式进行调用

服务下线

当服务实例正常关闭时，会发送一个服务下线的请求给服务注册中心，服务注册中心接收到请求后，将服务状态改为下线（DOWN），并把下线事件广播出去

服务注册中心

Eureka Server 在启动的时候会创建一个定时任务，默认间隔60秒，将超过默认90秒没有续约的服务实例剔除

Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内低于85%，Eureka Server会将当前实例注册保护起来，让这些实例信息不过期

Eureka和Zookeeper区别

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

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是同样的值。

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

分区容错性（P）：如果集群中的机器被分成了两部分，这两部分不能互相通信，系统是否能继续正常工作。

Zookeeper保证CP

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

Eureka保证AP

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。