当前位置：首页 > news >正文

SpringCloud之Eureka

news 2025/7/12 12:37:08

SpringCloud之Eureka

推荐参考：https://www.springcloud.cc/spring-cloud-dalston.html#_service_discovery_eureka_clients

1. 什么是Eureka

Eureka 用于简化分布式系统的服务治理，基于REST的服务，用于服务的注册与发现。通过注册发现、客户端负载均衡和故障转移机制，提升中间层服务的弹性与可维护性。有了服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。 其设计优先保障可用性（AP 模型），尤其适合云环境中动态伸缩的服务架构。在 Spring Cloud 生态中，它已成为微服务基础设施的关键组件。

2. 核心作用

服务注册与发现

服务注册：服务提供者（Provider）启动时，将自身信息（如 IP、端口、服务名）注册到 Eureka Server，形成服务注册表。

服务发现：服务消费者（Consumer）通过 Eureka Server 查询并获取目标服务的可用实例列表，基于本地缓存实现快速调用。

动态更新：客户端每 30 秒拉取一次服务注册表，确保信息时效性。
中间层负载均衡

针对微服务架构中的中间层服务（如数据库访问层、业务逻辑层），提供客户端负载均衡能力，支持轮询等基础算法。

与 AWS ELB（面向终端 Web 流量）互补，解决 AWS 环境下中间层服务暴露的安全性问题。
故障转移与健康监测

心跳机制：服务实例每 30 秒向 Eureka Server 发送心跳。若 90 秒未收到心跳，则自动剔除该实例。

故障切换：消费者通过本地缓存的服务列表，自动切换到健康实例，避免单点故障影响系统可用性。

3. 基本架构

Springcloud 封装了Netflix公司开发的Eureka模块来实现服务注册与发现.
Eureka采用了 C-S 的架构设计，Eureka Server作为服务注册功能的服务器，他是服务注册中心.
而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行，Springcloud 的一些其他模块 (比如Zuul) 就可以通过Eureka Server来发现系统中的其他微服务，并执行相关的逻辑.
Eureka 包含两个组件：Eureka Server 和 Eureka Client:

Eureka Server 提供服务注册，各个节点启动后，回在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会储存所有课用服务节点的信息，服务节点的信息可以在界面中直观的看到.

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

Eureka Server：提供服务的注册与发现

Service Provider：服务生产方，将自身服务注册到Eureka中，从而使服务消费方能够找到

Service Consumer：服务消费方，从Eureka中获取注册服务列表，从而找到消费服务

4. 自我保护机制

.
默认情况下，当Eureka Server在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除

（默认是90秒），但是，如果短时间内丢失大量的实例心跳，便会触发Eureka Server的自我保护机

制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把Eureka Server一起重启

（因为在开发过程中不会修改Eureka 注册中心），当一分钟内收到的心跳数大量减少时，会触发该

保护机制。可以在Eureka 管理界面看到Renews threshold和Renews(last min)，当后者（最后一分钟

收到的心跳数）小于前者（心跳阈值）的时候，触发保护机制，会出现红色的警告：

EMERGENCY!EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN
THEY’RE NOT.RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES
ARE NOT BEGING EXPIRED JUST TO BE SAFE.

从警告中可以看到，Eureka 认为虽然收不到实例的心跳，但它认为实例还是健康的，Eureka 会保护这些实例，不会把它们从注册表中删掉。

该保护机制的目的是避免网络连接故障，在发生网络故障时，微服务和注册中心之间无法正常通

信，但服务本身是健康的，不应该注销该服务，如果Eureka因网络故障而把微服务误删了，那即使

网络恢复了，该微服务也不会重新注册到Eureka Server了，因为只有在微服务启动的时候才会发起

注册请求，后面只会发送心跳和服务列表请求，这样的话，该实例虽然是运行着，但永远不会被其

它服务所感知。所以，Eureka Server在短时间内丢失过多的客户端心跳时，会进入自我保护模式，
该模式下，Eureka 会保护注册表中的信息，不在注销任何微服务，当网络故障恢复后，Eureka 会自动退出保护模式。自我保护模式可以让集群更加健壮。

但是我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删

除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。

所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在Eureka server配置文件中加上如下

配置即可：eureka.server.enable-self-preservation=false【不推荐关闭自我保护机制】

5. 主流注册中心对比（Eureka，Consul，Zookeeper，Nacos）

.
根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类, CAP理论
指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错的系统，通常性能不是特别高
AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

对比图表:

注册中心	CAP模型	一致性协议	设计侧重点	典型适用场景
Eureka	AP	自定义复制协议	高可用性、最终一致性	Netflix 生态、Spring Cloud 体系、容忍短暂不一致的云原生环境
Consul	CP	Raft	强一致性、多数据中心支持	金融、政务等强一致需求场景；多数据中心管理
Zookeeper	CP	ZAB（类Paxos）	强一致性、顺序一致性	分布式协调场景（如Kafka、Hadoop）、分布式锁、选主
Nacos	混合模式（AP/CP可切换）	Distro（AP）Raft（CP）	灵活适配、临时实例AP/持久实例CP	全场景覆盖，微服务注册发现与配置中心；动态切换需求

6. 问：作为分布式服务注册中心，Eureka比Zookeeper好在哪里？

.
答：

Zookeeper保证的是CP：

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

Eureka保证的是AP：

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：