Skip to content

概念卡片:Nacos 服务注册与发现

一句话机制:Nacos 是「服务注册发现 + 动态配置」双合一平台——服务启动时注册到 Nacos(登记 IP+端口+元数据),调用方发现服务时从 Nacos 拉取最新列表并自动剔除失效实例,靠心跳维持实例活性;配置中心则让客户端实时感知配置变化

服务注册发现流程

服务启动 → 注册到 Nacos(登记 IP+端口)

心跳上报(每 5s,15s 无心跳标记、30s 剔除)

调用方 → 从 Nacos 拉服务列表 → 负载均衡选一个实例调用

Nacos vs Eureka(完整对比)

维度NacosEureka
数据存储数据库(MySQL/Oracle 等)内存 + 节点间复制
健康检查临时实例心跳 / 非临时实例主动检测客户端心跳
部署单机/集群/云原生需自建 Spring Boot 项目
CAP默认 AP,可切 CPAP
功能注册 + 配置 + 服务管理仅注册中心

⚠️ 常见误区纠正:很多教程说「Eureka 是 CP」,其实 Eureka 是 AP(可用性优先,牺牲一致性)。Nacos 默认也是 AP,但可通过配置切 CP。

为什么 Nacos 同时具备 AP 和 CP

CAP 定理下 P(分区容错)不可避免,A 和 C 只能二选一:

  • AP 模式(默认):网络分区时优先可用,节点数据可能短暂不一致——适合服务注册(短暂不一致可容忍)。
  • CP 模式:优先强一致,分区时可能部分服务不可用——适合配置中心等强一致场景。

Nacos 把两者拆开,按场景选择:临时实例走 AP(心跳),持久实例走 CP(强一致)

不变量(必须成立的约束)

  • 服务实例靠心跳维持活性:临时实例 15s 无心跳标记不健康、30s 剔除。
  • 注册中心是「服务间互相发现」的枢纽,服务间不写死 IP,只写服务名。
  • Nacos 默认 AP,追求强一致要显式切 CP(或选持久实例)。

踩坑案例

  • 现象:服务重启后,调用方仍请求到旧实例报连接失败。 原因:临时实例心跳中断到剔除有 30s 窗口,调用方列表未及时刷新。解决:下线前主动 deregister,或缩短心跳/剔除时间,调用方开启重试。

常见误解

  • 以为注册中心和配置中心是两回事要分开装 → Nacos 一个平台都做了,注册(服务发现)和配置(动态参数)是两个模块。
  • 以为 Eureka 是 CP → 实际 AP;Nacos 才是「默认 AP、可切 CP」的双模式。

关联

最近更新