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

Spring Cloud Eureka 与 Nacos 深度解析：从架构到对比

news 来源：原创 2025/7/15 7:28:30

一、Eureka：经典微服务注册中心

（一）核心定位与特性

Spring Cloud Eureka 是 Netflix 开源的服务注册与发现组件，在微服务架构中扮演 "大脑" 角色，负责服务的注册、发现与状态管理。其核心优势在于通过心跳机制和客户端缓存保障系统高可用性，即使注册中心集群宕机，客户端仍可基于本地缓存调用服务。

（二）核心工作机制

1. 服务生命周期管理

服务注册（Register）
微服务启动时，Eureka Client 通过 REST 请求向 Server 注册自身元数据（IP、端口、健康指标等），Server 将信息存储于双层 Map 结构（Map<应用名, Map<实例ID, 实例数据>>）。
服务续约（Renew）
客户端默认每 30 秒（eureka.instance.lease-renewal-interval-in-seconds）发送心跳续约，防止服务被剔除。
服务下线（Cancel）
服务关闭 / 重启前主动发送下线请求，Server 将服务状态置为 DOWN 并广播下线事件。
失效剔除（Evict）
Server 启动定时任务，默认每 60 秒检查实例状态，对 90 秒未续约的实例（eureka.instance.lease-expiration-duration-in-seconds）执行剔除。

2. 服务消费流程

服务发现：消费者启动时从 Server 获取全量服务清单并缓存本地。
增量更新：Server 每 30 秒更新缓存清单，客户端通过定时拉取或事件监听获取变更。
本地调用：消费者基于缓存地址通过负载均衡（如 Ribbon）发起远程调用。

（三）集群与高可用

数据同步：Server 节点通过 HTTP 复制实现数据同步，形成最终一致性集群。
自我保护机制：当续约失败率超过阈值（默认 85%），触发自我保护模式，暂停剔除服务实例，避免网络分区导致的误判（可通过 eureka.server.enable-self-preservation=false 关闭）。

二、Nacos：阿里巴巴一站式服务平台

（一）核心功能架构

Nacos（Naming and Configuration Service）是阿里巴巴开源的服务注册与配置中心，集成四大核心模块：

服务管理：支持服务 CRUD、域名管理、健康检查、权重配置等；
一致性协议：根据场景提供 AP/CP 模式切换，适配不同数据一致性需求；
OpenAPI：暴露 RESTful 接口，支持多语言客户端（Java/Python/Go 等）；
管理控制台：可视化界面实现服务治理、配置管理、集群监控。

（二）服务实例类型

特性	临时实例（默认）	非临时实例（永久实例）
宕机处理	超时未心跳则剔除	保留实例，需手动下线或配置检测
一致性模式	支持 AP 模式	需 CP 模式（基于 Raft 协议）
配置方式	`ephemeral=true`（默认）	`spring.cloud.nacos.discovery.ephemeral=false`

（三）部署与通信

轻量部署：直接下载 Nacos Server JAR 包（支持 Linux/Windows），通过 sh startup.sh 或 cmd startup.cmd 启动，无需创建 Spring Boot 项目。
长连接通信：基于 Netty 实现长连接，支持服务列表变更的实时推送（对比 Eureka 的短连接定时拉取）。

三、深度对比：Eureka vs Nacos

（一）核心架构差异

维度	Eureka	Nacos
一致性协议	仅支持 AP（最终一致性）	支持 AP（临时实例）/CP（永久实例）切换
健康检测	客户端主动心跳（30 秒续约）	临时实例：客户端心跳；永久实例：服务端主动检测
服务更新机制	客户端定时拉取（30 秒）	支持事件推送（长连接实时通知）
集群模式	对等节点 HTTP 复制	AP 模式：Distro 协议；CP 模式：Raft 协议
自我保护机制	全局阈值（所有服务统一判断）	基于服务级健康实例比例，更精细控制
连接方式	HTTP 短连接（定时交互）	Netty 长连接（支持动态刷新，`@RefreshScope`）

（二）高级特性对比

CAP 模式细节
- AP 模式（默认）：允许网络分区时注册临时实例，服务自动创建，适合高可用场景（如电商促销流量突发）。
- CP 模式：基于 Raft 协议保证强一致性，注册永久实例前需先创建服务，适合金融等对数据一致性要求高的场景。
- MIXED 模式：同时支持临时 / 永久实例，需手动创建服务，平衡可用性与一致性。
生态集成
- Eureka 依赖 Spring Cloud 生态，需配合 Ribbon/Feign 实现负载均衡与调用；
- Nacos 内置负载均衡（权重 / 元数据路由），支持与 Dubbo、K8s 等生态无缝集成。

四、选型建议

选择 Eureka：
适用于遗留 Spring Cloud 项目，或对注册中心可用性要求极高（依赖客户端缓存容错），且无需复杂服务治理的场景。
选择 Nacos：
推荐新项目使用，尤其适合需要动态配置管理、多语言支持、精细服务治理（如权重路由、健康检测模式自定义），或需在 AP/CP 模式间灵活切换的场景。

Spring Cloud Eureka 是注册中心，负责微服务的注册与发现，起到承上启下的作用，在微服务架构中相当于人体的大脑，很重要，Nacos 是阿里巴巴出的，功能类似 Eureka。

Nacos 的部署方式与 Spring Cloud Eureka 不太一样，Euraka 是需要创建 Spring Boot 项目，然后将Euraka 服务端通过依赖的方式加载进来，然后部署项目。Nacos 是直接从阿里巴巴 Nacos 的官网下载 jar 包，启动服务。

Eureka

EUREKA-SNAPSHOT

Eureka Server 之间通过复制的方式完成数据的同步，Eureka 还提供了客户端缓存机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的 API 。综上，Eureka 通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

EUREKA-ARCH

服务注册（register）：Eureka Client 会通过发送 REST 请求的方式，向 Eureka Server 注册自己的服务。注册时，提供自身的元数据，比如 ip 地址、端口、运行状况指标、主页地址等信息。Eureka Server 接收到注册请求后，就会把这些元数据信息存储在一个双层的 Map 中。什么时候注册？在启动微服务的时候。
服务续约（renew）：在服务注册后，Eureka Client 维护一个心跳来持续通知 Eureka Server，说明服务一直处于可用状态，防止被剔除。默认每隔 30 秒 eureka.instance.lease-renewal-interval-in-seconds 发送一次心跳来进行服务续约。
获取服务列表（get registry）：服务消费者（Eureka Client）在启动的时候，会发送一个 REST 请求给 Eureka Server，获取注册中心的服务清单，并且缓存在客户端本地。同时，为了性能及安全性考虑，Eureka Server 会每隔30秒更新一次缓存中的服务清单。
服务调用：服务消费者在获取到服务清单后，可以根据清单中的服务信息，查找到该服务的地址，从而进行访问(远程调用)。
服务下线（cancel）：当 Eureka Client 需要关闭或重启时，就不希望在这个时间段内再有请求进来，所以，就需要提前先发送 REST 请求给 Eureka Server，告诉 Eureka Server自己要下线了，Eureka Server 在收到请求后，就会把该服务状态置为下线（DOWN），并把该下线事件传播出去。
失效剔除（evict）：服务实例可能会因为网络故障等原因，导致不能提供服务，而此时该实例也没有发送请求给 Eureka Server 来进行服务下线。所以，还需要有服务剔除的机制。Eureka Server 在启动的时候会创建一个定时任务，每隔一段时间（默认 60 秒），从当前服务清单中把超时没有续约（默认 90 秒 eureka.instance.lease-expiration-duration-inseconds）的服务剔除。

Nacos

NACOS-ARCH

服务管理：实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能

一致性协议：解决不同数据，不同一致性要求情况下，不同一致性机制

OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成

Console：易用控制台，做服务管理、配置管理等操作

Nacos的服务实例分为两种类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:cloud:nacos:discovery:ephemeral: false # 设置为非临时实例

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异。

Ereka vs Nacos

共性

都支持服务注册和服务拉取
都支持服务提供者心跳方式做健康检测

区别

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

临时实例心跳不正常会被剔除，非临时实例则不会被剔除

Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

1、范围不同。

Nacos 的阈值是针对某个具体 Service 的，而不是针对所有服务的；但 Eureka 的自我保护阈值是针对所有服务的。Nacos 支持 CP 和 AP 两种；Eureka 只支持 AP 。Nacos 使用 Netty，是长连接；Eureka 是短连接，定时发送

2、保护方式不同。

Eureka 保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server 不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关（eureka.server.enable-self-preservation: false)。

Nacos 保护方式：当域名健康实例占总服务实例的比例小于阈值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例能正常工作。

3、连接方式不同。

Nacos 支持动态刷新，在控制器（Controller）上加＠RefreshScope 注解即可，采用 Netty 连接，是长连接；Eureka 本身不支持动态刷新，需要配合 MQ 完成动态刷新，且是短连接，是定时发送。

Nacos中CAP模式切换

Nacos 支持 AP 和 CP 模式的切换，这意味着 Nacos 同时支持两者一致性协议。这样，Nacos 能够以一个注册中心管理这些生态的服务。不过在 Nacos 中，AP 模式和 CP 模式的具体含义，还需要再说明下。

AP 模式为了服务的可能性而减弱了一致性，因此 AP 模式下只支持注册临时实例。AP 模式是在网络分区下也能够注册实例。在 AP 模式下也不能编辑服务的元数据等非实例级别的数据，但是允许创建一个默认配置的服务。同时注册实例前不需要进行创建服务的操作，因为这种模式下，服务其实降级成一个简单的字符创标识，不再存储任何属性，会在注册实例的时候自动创建。

CP 模式下则支持注册持久化实例，此时则是以 Raft 协议为集群运行模式，因此网络分区下不能够注册实例，在网络正常情况下，可以编辑服务器别的配置。该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。

MIXED 模式可能是一种比较让人迷惑的模式，这种模式的设立主要是为了能够同时支持临时实例和持久化实例的注册。这种模式下，注册实例之前必须创建服务，在服务已经存在的前提下，临时实例可以在网络分区的情况下进行注册。