Nacos 集群核心架构原理分析

一、Nacos 集群架构

1、Nacos 集群架构图

官方推荐用户把所有服务列表放到一个vip下面，然后挂到一个域名下面。

http://nacos.com:port/openAPI 域名 + SLB模式(内网SLB，不可暴露到公网，以免带来安全风险)，可读性好，而且换ip方便，推荐模式

2、Nacos 集群架构设计要点

1、微服务并不是直接通过 IP 地址访问后端服务，而是采用域名访问。通过 DNS（域名解析服务）转换为具体的 IP 地址，通过域名方式屏蔽后端容易产生变化的 IP 地址。

2、底层 Nacos 自带集群间节点与数据同步方案，因此需要 Nacos 节点对外暴露 8848 与 7848 端口。其中 8848 端口的作用是对外暴露 API 与集群间数据同步，而 7848 端口则用于节点选举来确定集群领袖（Leader）。同时 Nacos 在集群环境下需要持久化应用配置、用户权限、历史信息等内置数据，因此需要额外部署 MySQL 数据库提供统一存储。

3、在 Nacos 层面，每一台服务器都有独立的 IP。我们并不建议直接将物理 IP 对外暴露，而是额外增加 VIP（虚拟 IP），通过 DNS 服务绑定 VIP，这样的好处是通过 VIP 屏蔽了Nacos集群实际的物理IP地址，同时为访问者提供了统一的接入入口，使微服务的注册接入和Nacos 集群实现细节彼此解耦，提高架构的维护性。

二、Nacos 集群工作原理

1、Nacos 集群 Leader 节点选举原理

Nacos 因为选举算法的特殊性，要求最少三个节点才能组成一个有效的集群。一般选举算法都建议奇数个节点，2个节点的数据一致性可能无法保障。

Nacos 集群采用 Raft 算法实现。它是一种比较简单的选举算法，用于选举出 Nacos 集群中最重要的 Leader（领导）节点。

在 Nacos 集群中，每个节点都拥有以下三种角色中的一种。

1. Leader：领导者，集群中最重要的角色，用于向其他节点下达指令。
2. Candidate：参选者，参与竞选 Leader 的节点。
3. Follower：跟随者，用于接收来自 Leader 或者 Candidate 的请求并进行处理。

在集群中选举出 Leader 是最重要的工作，产生选举的时机有三个：

1. 在 Nacos 节点启动后，还没有产生Leader时选举；
2. 集群成员总量变更时重新选举；
3. 当 Leader 停止服务后重新选举。

在开始介绍选举过程前，先理解任期（Term）的含义:

Raft 算法将时间划分成为任意不同长度的任期（Term）。任期用连续的数字进行表示。每一个任期的开始都是一次选举（Election），一个或多个候选人会试图成为 Leader。

为了便于理解，我们使用文字+表格的形式说明选举过程。

1. 当最开始的时候，所有 Nacos 节点都没有启动。角色默认为 Follower（跟随者），任期都是 0。

2. 当第一个节点（ip1）启动后，节点角色会变为 Candidate（参选者），ip1 节点在每一个任期开始时便会尝试向其他节点发出投票请求，征求自己能否成为 Leader（领导者）节点。只有算上自己获得超过半数的选票，这个 Candidate 才能转正为 Leader。

在当前案例，因为 ip1 发起选举投票，但 ip2/ip3 两个节点不在线，尽管 ip1 会投自己一票，但在总 3 票中未过半数，因此无法成为 Leader。因为第一次选举没有产生 Leader，过段时间在下一个任期开始时，ip1 任期自增加 1，同时会再次向其他节点发起投票请求争取其他节点同意，直到同意票过半。

3. 在 Raft 算法中，成为 Leader 的必要条件是某个 Candidate 获得过半选票，如果 ip2 节点上线，遇到 ip1 再次发起投票。ip2 投票给 ip1 节点，ip1 获得两票超过半数就会成为 Leader，ip2 节点自动成为 Follower（跟随者）。之后 ip3 节点上线，因为集群中已有 Leader，因此自动成为 Follower。

4. 当 Leader 节点宕机或停止服务，会在剩余 2 个 Nacos 节点中产生新的 Leader。如下所示ip3获得两票成为 Leader，ip2 成为 Follower，ip1已经下线但角色暂时仍为 Leader。

之后 ip1 恢复上线，但此时 Nacos 集群已有 Leader 存在，ip1 自动变为 Follower，且任期归0。

对于 Nacos 集群来说，只要 UP 状态节点不少于"1+N/2"，集群就能正常运行。但少于“1+N/2”，集群仍然可以提供基本服务，但已无法保证 Nacos 各节点数据一致性。

以上就是 Nacos 基于 Raft 算法的 Leader 选举过程，确定 Leader 是维持 Nacos 集群数据一致的最重要前提，下面咱们来讲解在微服务注册时 Nacos 集群节点信息同步的过程。

2、Nacos 节点间的数据同步过程

Nacos 节点间的数据同步过程

在 Raft 算法中，只有 Leader 才拥有数据处理与信息分发的权利。因此当微服务启动时，假如注册中心指定为 Follower 节点，则步骤如下：

第一步，Follower 会自动将注册心跳包转给 Leader 节点；

第二步，Leader 节点完成实质的注册登记工作；

第三步，完成注册后向其他 Follower 节点发起“同步注册日志”的指令；

第四步，所有可用的 Follower 在收到指令后进行“ack应答”，通知 Leader 消息已收到；

第五步，当 Leader 接收过半数 Follower 节点的 “ack 应答”后，返回给微服务“注册成功”的响应信息。

此外，对于其他无效的 Follower 节点，Leader 仍会不断重新发送，直到所有 Follower 的状态与 Leader 保持同步。

三、Nacos 配置中心原理剖析

在分布式系统中，配置中心扮演着连接服务与配置的关键角色，而 Nacos 作为开源配置中心的佼佼者，其高效的配置同步能力背后，是长轮询与推送机制的精妙结合。本文将深入剖析这两种机制的底层原理，对比其技术特性，并揭示 Nacos 如何通过创新优化实现 “实时性” 与 “资源效率” 的平衡。

1、配置同步的核心命题：实时性与稳定性的博弈

配置中心的核心功能是确保分布式环境中所有服务实例的配置保持一致，其面临的核心挑战在于：如何在配置变更后快速通知所有客户端，同时避免因频繁通信导致的服务器资源消耗和网络拥塞。

传统的配置同步方案存在明显缺陷：

• 短轮询：客户端定期（如每秒）向服务器发送请求查询配置是否变更。这种方式简单直接，但会造成大量无效请求（99% 的查询结果为 “无变更”），浪费带宽和 CPU 资源；
• TCP 长连接推送：服务器通过长连接主动向客户端推送变更。虽然能实现实时通知，但在客户端数量庞大（如数万实例）时，服务器需要维护海量长连接，容易引发内存溢出和句柄耗尽问题。

Nacos 创新性地采用 “长轮询为主、推送为辅” 的混合策略，既规避了短轮询的资源浪费，又解决了纯推送的 scalability 瓶颈，成为配置中心领域的标杆设计。

1、长轮询机制：Nacos 的 “按需响应” 策略

长轮询（Long Polling）是 Nacos 配置同步的核心机制，其设计思想是 “客户端发起请求后，服务器不立即响应，而是将请求挂起，直到配置发生变更或超时才返回结果”。这种 “按需响应” 的模式大幅减少了无效通信。

1.长轮询的工作流程

Nacos 的长轮询交互分为四个关键步骤：

1. 客户端发起长轮询请求：客户端向 Nacos 服务器发送 HTTP 请求，携带当前配置的 MD5 值（用于快速校验变更）和超时时间（默认 30 秒），并声明 “若 30 秒内配置无变更，等待至超时后返回；若期间发生变更，立即返回新配置”。
2. 服务器端的请求挂起与监听：服务器接收到请求后，首先校验配置 MD5 是否与最新值一致：

• • 若不一致（配置已变更），立即返回新配置和最新 MD5；
• • 若一致，将请求存入 “待通知队列”，并注册一个监听器（Watch），同时启动 30 秒倒计时。

3. 配置变更时的即时唤醒：当运维人员通过 Nacos 控制台修改配置后，服务器会触发配置变更事件，遍历 “待通知队列” 中所有监听该配置的长轮询请求，立即返回新配置并终止倒计时。
4. 超时唤醒与重试：若 30 秒内配置未变更，服务器会主动结束挂起状态，向客户端返回 “无变更” 响应。客户端收到后，立即发起下一次长轮询，形成持续监听。

这种机制下，客户端与服务器的通信频率完全由配置变更频率决定 —— 配置稳定时，每 30 秒一次请求；配置频繁变更时，请求频率随变更频率动态提升，实现了 “变更越频繁，响应越及时；变更越稳定，资源越节省” 的自适应效果。

2. 长轮询的技术优势

• 低资源消耗：相比短轮询（假设 1 秒 1 次），长轮询在配置稳定时可减少 97% 的请求量（30 秒 1 次）；
• 接近实时的响应：配置变更后，服务器能在毫秒级唤醒挂起的请求，通知延迟通常低于 100ms；
• 兼容性强：基于 HTTP 协议实现，无需额外开发 TCP 长连接组件，适配各种网络环境和编程语言；
• 天然支持负载均衡：客户端可随机连接 Nacos 集群中的任一节点，通过集群分担请求压力。

3、推送机制：高优先级场景的 “主动通知” 补充

尽管长轮询已能满足大部分场景，Nacos 仍保留了推送机制作为补充，主要用于 “高优先级配置变更”（如服务紧急下线、安全策略更新）的快速扩散。

1. 推送机制的实现方式

Nacos 的推送机制基于 TCP 长连接，仅在以下场景触发：

• 配置标记为 “紧急变更”（如通过 API 设置urgent=true）；
• 客户端数量较少（如低于 1000 实例），服务器可高效维护长连接。

其工作流程为：

1. 客户端启动时，与 Nacos 服务器建立 TCP 长连接，并注册监听的配置项；
2. 当高优先级配置变更时，服务器通过该长连接主动向客户端发送二进制变更通知；
3. 客户端收到通知后，立即发起 HTTP 请求拉取完整配置（推送仅传递 “变更标识”，避免大报文传输）。

这种 “轻量推送 + 按需拉取” 的设计，既保证了紧急变更的实时性，又减少了纯推送模式下的带宽消耗。

2. 推送与长轮询的协同策略

Nacos 通过 “动态切换机制” 平衡两种模式：

• 当客户端数量超过阈值（默认 5000），自动关闭推送功能，仅使用长轮询；
• 单个客户端若 3 次推送失败（如网络波动），自动降级为长轮询，避免无效重试；
• 紧急配置变更时，即使默认使用长轮询的客户端，也会触发一次推送通知，确保优先响应。

4、Nacos 的极致优化：从机制到细节的打磨

Nacos 的配置同步能力之所以领先，不仅在于机制选择，更在于细节上的深度优化：

1. 配置变更的高效检测

• MD5 快速校验：服务器将配置内容的 MD5 值作为变更标识，客户端只需传递 MD5 即可快速判断是否需要更新，避免全量配置传输；
• 分组监听与批量处理：客户端可按 “配置分组” 批量监听（如com.alibaba.service.*），服务器按分组管理变更事件，减少监听器数量。

2. 服务器端的资源控制

• 请求队列隔离：不同 namespace 的长轮询请求被放入独立队列，避免某一业务线的配置变更影响其他队列；
• 超时时间自适应：服务器根据当前连接数动态调整客户端的长轮询超时时间（连接数越多，超时时间越短），防止请求堆积。

3. 客户端的容错设计

• 本地缓存兜底：客户端将配置缓存至本地文件，若 Nacos 服务器不可用，可加载缓存配置启动，保证服务可用性；
• 重试退避策略：长轮询失败后，客户端采用指数退避（1s→2s→4s）重试，避免风暴式请求冲击服务器。

5、实践对比：长轮询 vs 推送的场景适配

在实际应用中，两种机制的选择需结合业务场景：

• 中小规模集群（<1000 实例） ：启用推送 + 长轮询混合模式，既能享受推送的实时性，又不会给服务器带来太大压力，适合金融交易、实时监控等对延迟敏感的场景；
• 大规模集群（>10000 实例） ：仅使用长轮询，通过 Nacos 集群的负载均衡能力分散请求，适合电商、社交等客户端数量庞大的场景；
• 网络不稳定环境：优先使用长轮询，其基于 HTTP 的重试机制比 TCP 推送更易恢复，适合跨地域部署的分布式系统。

Nacos 的配置同步机制证明：优秀的技术方案不是非此即彼的选择，而是对场景的深刻理解与机制的灵活组合。长轮询通过 “按需响应” 解决了资源效率问题，推送机制通过 “主动通知” 保障了关键场景的实时性，而 Nacos 的创新优化则让两者无缝协同，实现了 “毫秒级响应” 与 “百万级客户端支撑” 的兼得。

对于分布式系统开发者而言，理解 Nacos 的设计思想不仅能更好地使用配置中心，更能启发在其他场景（如消息通知、状态同步）中平衡 “实时性” 与 “资源消耗” 的思考，让技术方案真正服务于业务需求。