Nacos基本架构及原理

Nacos（Dynamic Naming and Configuration Service）是一个易于构建云原生应用的动态服务发现、配置和管理平台。其架构设计遵循高可用、高性能、最终一致性原则，通过分层模块化和异步处理机制，支持海量服务注册与发现。

一、整体架构分层

Nacos系统从逻辑上可以分为客户端组件 、接入层 、核心服务层 和一致性协议层，并支持多数据中心集群部署。

集群
一致性协议
核心服务层
接入层
客户端
Provider APP

Nacos Client/Sidecar
Consumer APP

Nacos Client/Sidecar
Name Server

DNS/VIP/Address Server
OpenAPI

HTTP/DNS/UDP/TLS
Config Service
Naming Service
Nacos Core
Consistency Protocol

Raft/Sync/Renew/RDBMS Based
Multi-Datacenter Nacos Cluster

各模块职责

Nacos Client/Sidecar：嵌入在服务提供者和消费者中的客户端，负责与服务端通信（注册、心跳、服务订阅、配置获取）。
Name Server：提供域名解析、VIP（虚拟IP）或地址服务器，用于客户端发现Nacos Server集群地址，实现负载均衡。
OpenAPI：统一的接入层接口，支持HTTP、DNS、UDP、TLS等多种协议，方便不同语言和场景的集成。
Config Service：配置管理服务，处理配置的发布、获取、监听等。
Naming Service：服务发现核心服务，处理服务实例的注册、注销、查询、健康检查。
Nacos Core：核心基础模块，提供事件驱动、任务调度、缓存管理等通用能力。
Consistency Protocol：一致性协议层，支持基于Raft的强一致性（如服务元数据）和基于异步同步的最终一致性（如健康状态），并支持多种存储后端（如RDBMS）。
Multi-Datacenter Nacos Cluster：多数据中心集群部署，实现跨地域的高可用和容灾。

二、核心工作原理

2.1 服务注册流程

当服务提供方启动时，通过Nacos Client向Nacos Server发起注册请求，流程如下：
注册表存储注册线程池阻塞队列 Nacos Server Nacos Client 服务提供者注册表存储注册线程池阻塞队列 Nacos Server Nacos Client 服务提供者启动，准备注册发送注册请求(Instance) 将请求放入阻塞队列立即响应成功异步取出任务执行注册(写入内存/持久化) 完成处理完毕

关键设计：

请求接收与处理分离：通过阻塞队列和专用注册线程池，避免高并发下直接写注册表导致锁竞争，提升吞吐量。
异步写入：主线程快速响应客户端，后台线程保证数据最终一致。

2.2 心跳机制与健康检查

服务提供者注册成功后，需定期发送心跳以维持健康状态。
每5秒发送心跳
否
是
是
否
服务提供者
Nacos Server
15秒内收到心跳？
标记实例为不健康
更新最后心跳时间，保持健康
30秒内是否恢复心跳？
重新标记为健康
从注册表删除实例
触发服务变更通知

健康状态流转：

健康：实例正常提供服务，心跳正常。
不健康：15秒未收到心跳，但实例仍保留在注册表中，消费者可能通过保护阈值等机制继续调用（避免全部剔除）。
移除：30秒内仍未收到心跳，则彻底删除实例，释放资源。

2.3 服务发现与本地缓存

服务消费者通过Nacos Client获取服务提供者列表，并缓存到本地，同时定时更新。
Nacos Server Nacos Client 服务消费者 Nacos Server Nacos Client 服务消费者 loop [定时任务(每10秒)] 首次获取服务列表发送查询请求返回实例列表缓存到本地拉取最新列表返回变更或全量列表更新本地缓存

2.4 服务变更通知机制

当服务实例发生变化（注册、下线、健康状态变更）时，Nacos Server需要通知所有订阅该服务的消费者。
客户端
服务端
成功
若UDP失败或未及时收到
服务实例变更
UDP推送变更
记录变更事件
UDP接收器
更新本地缓存
定时拉取任务

每10秒

双模式结合：

UDP推送：Server主动通过UDP向客户端发送变更数据。UDP无需建立连接，开销小，适合广播场景。若网络丢包，则推送失败（不重试）。
客户端定期拉取：作为补偿，客户端每10秒主动拉取一次全量或增量数据，保证最终一致性。

设计意图：在消费者远多于提供者的场景下，避免Server与海量消费者建立TCP长连接带来的资源消耗，同时利用UDP的实时性和客户端拉取的可靠性，实现高效变更通知。

三、关键设计亮点总结

设计点	描述	优势
异步注册处理	注册请求放入阻塞队列，由独立线程池处理	提高写入吞吐量，避免并发锁竞争
心跳健康检查	基于时间窗口的健康状态判定与自动剔除	无需额外探针，实现故障自动转移
UDP推送+客户端拉取	实时UDP通知 + 定期轮询补偿	兼顾实时性与可靠性，避免TCP长连接开销
多数据中心支持	通过一致性协议实现跨地域集群	提供容灾和就近访问能力
分层模块化	开放API、核心服务、一致性协议分离	易于扩展和维护，适应不同部署场景

四、核心流程整合图

以下流程图综合展示了服务注册、心跳、发现和变更通知的完整交互：
服务消费方
Nacos Server
服务提供方
15秒未收到
30秒未收到
UDP通知
拉取
注册 Instance
每5秒发送心跳
接收注册请求
放入阻塞队列
后台线程写入注册表
更新实例最后时间
心跳超时判断
标记不健康
删除实例
触发变更事件
UDP推送变更
记录变更供拉取
首次发现
拉取全量实例
缓存到本地
定时每10秒拉取
更新缓存

五、总结

用简单的话概括就是：
当服务提供方启动时候，会向nacos发送注册请求,nacos将注册请求放入到一个阻塞队列中，会有一个负责注册的线程池中单独执行注册请求，将处理请求写和注册的操作分离开，提高性能。采用内存队列，避免了并发写的异常。当服务提供方产生变化的时候，nacos会采用服务端udp推送和客户端主动拉取两种模式进行结合，udp协议非常快，不需要保持长连接。在注册中心的场景中服务的消费者往往多余服务的提供者，如果每一次服务更新，nacos要和成千上万的服务消费者去建立Tcp的话性能肯定是不行的。如果UDP通知失败，客户端每10秒还会主动去拉一次，客户端拉取和服务器推送是互补的。

也可以这样概括：

服务的提供方会向nacos server注册信息，这个注册信息会包装成Instance，放到ServiceInfo中
服务的提供方每隔5s会向nacos server发送心跳，如果server端在15秒内未收到Client心跳，则会标记为不健康的状态；若在30s内收到Client心跳，则恢复为健康状态，否则从Server的内存中清除该实例。（不健康的实例，server会自动清除）
服务消费者在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Server本地，同时在Nacos Server本地开启一个定时任务，定时拉取服务端最新的注册表信息更新到本地缓存中

最后：

Nacos通过分层架构 （客户端、接入层、核心服务、一致性协议）实现了高可扩展的服务注册与发现平台。其核心原理围绕异步处理注册 、心跳健康检查 、双模式变更通知展开，在保证高性能的同时，通过客户端缓存和定期拉取确保了数据的最终一致性。多数据中心支持和灵活的一致性协议，使其能够适应从单机到大规模分布式集群的各种部署需求，成为云原生微服务架构中的关键基础设施。