目录

定义

实现原理

采用C-S的架构设计

Eureka Server

Eureka Client

自我保护机制

定义

目的

触发条件

和Zookeeper的区别

CAP原则

Zookeeper 保证的是CP

Eureka 保证的是AP

Reference


定义

Eureka是Netflix的一个子模块,也是核心模块之一。Eureka是基于REST的服务,用于定位服务,以实现云端中间件层服务发现和故障转移。

服务注册与发现对于微服务来说是非常重要的,有了服务注册与发现,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了,功能类似于Dubbo的注册中心,比如Zookeeper。

实现原理

采用C-S的架构设计

  • 分为Eureka Server 和 Eureka Client两个组件

Eureka Server

  • 作为服务注册功能的服务器,是服务注册中心
  • 各个节点启动后,要在 Eureka Server 中进行注册,这样Eureka Server中的服务注册表中将会存储所有服务节点的信息,服务节点的信息可以在界面中直观的看到

Eureka Client

  • 是一个Java客户端,用于简化Eureka Server的交互,同时也具备一个内置的,使用轮询负载算法的负载均衡器
  • 在应用启动后,将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务节点移除掉(默认周期为90s)

自我保护机制

定义

  • 某时刻某一微服务不可用,Eureka不会立即清理,依旧会对该微服务的信息进行保存
  • Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  • Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上 (即保证当前节点依然可用)
  • 当网络稳定时,当前实例新的注册信息会被同步到其他节点中

目的

  • 该保护机制的目的是避免网络连接故障,在发生网络故障时,微服务和注册中心之间无法正常通信,但服务本身是健康的,不应该注销该服务,如果Eureka因网络故障而把微服务误删了,那即使网络恢复了,该微服务也不会重新注册到Eureka Server了,因为只有在微服务启动的时候才会发起注册请求,后面只会发送心跳和服务列表请求,这样的话,该实例虽然是运行着,但永远不会被其它服务所感知

触发条件

  • Eureka Server在短时间内丢失过多的客户端心跳时(在15分钟内超过85%的节点都没有正常的心跳),会进入自我保护模式,该模式下,Eureka会保护注册表中的信息,不再注销任何微服务,当网络故障恢复后,Eureka会自动退出保护模式。

和Zookeeper的区别

CAP原则

Zookeeper 保证的是CP

  • 注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接收服务直接down掉不可用,服务注册功能对一致性的要求要高于可用性。
  • 当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader投票选举。选举leader的时间太长(30-120s),且选举期间整个zookeeper集群是不可用的,导致选举期间注册服务瘫痪。
  • 在云部署的环境下,因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件,虽然服务最终能够恢复,但是,漫长的选举时间导致注册长期不可用,是不可容忍的。

Eureka 保证的是AP

  • Eureka在设计时就优先保证可用性。
  • Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的。
  • Eureka有自我保护机制。
  • 故Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪