Eureka注册原理解析

Eureka注册原理解析：

Eureka Client

client注册的流程其实很简单，无非就是以下几个步骤：

先读eureka server的配置信息，从而知道eureka server在哪，以便后面进行注册
接着再读取自己的配置信息，然后将自己的信息封装在InstanceInfo实例中，等下将实例发送到eureka server中
通过上面步骤已经知道eureka server的地址了，此时先把注册拉取到本地缓存起来
将上面封装的InstanceInfo实例发送到eureka server进行注册，然后初始化心跳检测以及缓存刷新（这些都是通过开启后台线程完成的）
再次拉取注册表更新本地注册表信息

InstanceInfo实例部分代码：可以看到几个主要的信息比如：instanceId、ipAddr、port、appName、appGroupName、lastUpdatedTimestamp等

Eureka Server

Eureka Server是一个开箱即用的服务注册中心，开发人员只需要导入相关的依赖即可，它提供以下功能：

服务注册
接受eureka client发送过来的心跳检测
服务剔除（当一个client心跳超时）
服务下线（client请求关闭）
集群同步（不同eureka server中注册表信息同步）
获取注册表中服务实例信息（每个eureka server同时也是一个eureka client，eureka server可以把自己注册到eureka集群中）
服务注册时eureka client会将服务实例InstanceInfo发送到eureka server。
服务实例通过ConcurrentHashMap保存在内存中，在服务注册的过程中会先获取一个锁，防止其他线程对registry注册表进行数据操作，避免数据不一致。
eureka server接收到client发送过来的InstanceInfo实例时，会先根据唯一的instanceId检查注册表中是否已存在该实例。
如果没有该实例，说明这是一次新的注册服务，server会将InstanceInfo信息保存到注册表中
如果存在该实例，说明这是一次心跳检测或者实例信息更新操作，会比较lastUpdatedTimestamp字段保留最新的InstanceInfo实例信息。

集群同步

为了保持注册表的一致性，集群中的eureka server需要一个同步机制来维护注册表。
集群同步分为两个部分，我个人将其理解为pull和push：
pull：eureka server启动时从集群中其他节点pull注册表信息进行本地注册表的初始化
push：eureka server对本地的注册表进行更新操作后（包括增删改）会将操作push（也就是同步）到其他节点中
集群模式下的eureka server，多个eureka server之间互相注册并同步注册表信息，即使集群中个别节点出现故障或宕机，集群还是能够稳定提供服务。
缺陷：Eureka Server集群的节点之间是通过http的方式进行同步的，网络存在不可靠性，为了保持高可用性，eureka server 牺牲了数据一致性，eureka server不满足 CAP找那个C（数据一致性）。

Eureka和ZooKeeper的区别

在分布式领域有一个很著名的CAP定理：C：数据一致性。A：服务可用性。P：分区容错性（服务对网络分区故障的容错性）。

Eureka（保证AP），Zookeeper（保证CP）

Zookeeper保证CP:

当master节点因为网络故障与其它节点失去联系时，剩余节点会重新进行leader选举。选举时间太长，30~120s，且选举期间整个zk集群都是不可用的，导致注册服务瘫痪。

Eureka保证AP

Eureka各个节点都是平等的，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。

Eureka有自我保护机制，15分钟超过85%的节点都没有正常的心跳，Eureka就认为客户端与注册中心出现网络故障，此时出现以下几种情况：

Eureka不在从注册表中移除因为长时间没收到心跳过期的服务
Eureka依然能接受新服务的注册和查询请求，但是不会同步到其它节点
当网络稳定时，当前实例新的注册信息会被同步到其它节点上

因此，Eureka可以很好的应对网络故障导致的部分节点失去联系的情况，而不会像zookeeper那样整个服务瘫痪

原文地址： Eureka注册原理解析 - 同喜 - 博客园 (cnblogs.com)