目录

定义

实现原理

采用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那样使整个注册服务瘫痪