Nacos内核拆解 Distro Raft 长轮询原理

一、想用好 Nacos，先认清它在干两件不同的事

许多开发者初识 Nacos 时，往往只把它当作“一个工具”。但深入剖析便会发现，其内部承载着两种性质迥异的职责：

• 服务注册与发现：追求速度与可用性，偶尔丢失少量数据影响不大。
• 配置管理：允许适当延迟，但数据必须绝对不丢。

这两个场景天然需要差异化的一致性策略。Nacos 的内核正是基于这一差异，构建了两套独立运作的体系：

将这张图牢记于心，后续所有逻辑便豁然开朗。

二、Distro：服务发现为啥默认用 AP

为何不采用强一致？

服务实例数量庞大且上下线频繁。若每次变更都走 Raft 那样的“多数派确认”，集群将承受巨大压力。

况且，服务发现本身的容错特性颇为特殊：

• 多一个实例，最多增加一次失败重试。
• 少一个实例，最多短暂损失部分流量处理能力。

短时间的不一致，对业务体验几乎无感。因此，此处实在没有必要强行上 CP。

Distro 的运行机制

Distro 是 Nacos 自研的协议，设计思路非常务实：

• 责任分片：每个 Nacos 节点仅负责一部分服务实例的“权威数据”。
• 本地写入、异步同步：客户端注册到任意节点后，节点先写入本地，再通过异步广播同步至其他节点。
• 最终一致性：经过短暂时间，集群内同一服务实例的视图将趋于一致。
• 节点故障可恢复：某节点宕机后，其负责的实例数据由其他节点接管，重启后还能重新拉取。

这一设计的精妙之处在于——它坦然承认“服务发现本就是 AP 场景”，并未为了追求强一致而强行套用 Raft。

三、Raft：配置中心为何必须 CP

配置管理则截然不同。

设想这样一个场景：你在控制台中将核心限流值从 1000 改为 100。如果此时 Nacos 集群内部不一致，部分节点已收到新值，部分节点仍保留旧值——

这种后果远比“多一个旧实例”严重得多。因此，配置中心必须采用 CP 模式，写入操作需在多数派确认成功后才算真正完成。

Nacos 配置中心基于 JRaft，即 Raft 协议的工程化实现版本：

有几个工程细节值得重点说明：

• 节点数必须 ≥ 3。Raft 需要选举，2 个节点无法完成。
• 写入操作均由 Leader 处理。Follower 收到写入请求后会转发或直接拒绝。
• Leader 宕机后会触发重新选举。选举期间短暂不可写入，这属于正常行为。
• 配置最终存储于 MySQL（默认）。Raft 负责协调一致性，而非存储本身。

这套机制堪称教科书级别的 CP 实现。千万不要尝试用 2 节点运行 Nacos 配置中心——从工程角度来看，这是错误的做法。

四、配置推送：长轮询，而非 WebSocket

在做技术选型时，不少人曾误以为 Nacos 配置推送走的是 WebSocket。
但事实并非如此。

它实际采用的是 长轮询（long polling）。大致流程如下：

为什么选择长轮询而非 WebSocket？

• 实现简单：基于 HTTP 协议，所有 SDK 都能轻松对接，运维和网关压力更小。
• 网络穿透性强：WebSocket 在一些企业网络中需要协议升级，而长轮询就是普通的 HTTP 请求。
• 效果近乎实时：客户端感知到变更通常在 1 秒以内，业务体验上就是“实时推送”。

很多教程会写“Nacos 是推送的”，严格来说这并不准确。它实际是通过 long-polling 模拟出的“准实时”效果。但从体验上看并无差别，工程上反而更加稳定。

五、临时实例 vs 持久实例：上一篇埋下的坑，现在拆开细讲

上一篇曾提到：“Nacos 默认是临时实例，假死会有坑”。这里展开详细说明。

两种实例的核心区别

假死场景为何危险

业务微服务默认采用临时实例。问题在于：

• 进程并未完全终止，心跳线程仍在运行
• 但业务线程已卡死，无法处理请求
• 从 Nacos 视角看：心跳正常，实例状态健康
• 流量持续打入 → 大量请求超时

如何应对

常见的几种解决方案：

• 配合健康检查 / Readiness 探针。让 K8s 或网关自行判断健康状态，而非完全依赖 Nacos。
• 关键基础设施改为持久实例。比如内部网关、定时任务调度器等“挂了会影响全局”的组件，让 Nacos 主动进行健康检查。
• 下游做好熔断。再优秀的注册中心也无法保证 100% 准确，下游必须有熔断机制兜底。

这条原则应刻入团队 SOP：注册中心是辅助手段，不能替代调用方自身的容错能力。

六、客户端缓存：Nacos 挂了为何还能撑一阵

很多人并不了解：Nacos 客户端默认会将服务列表和配置缓存到本地磁盘。

这意味着什么？

• 即使 Nacos 集群整体宕机，业务短时间内仍能依靠旧的服务列表和配置继续运转。
• 服务重启时，若无法连接 Nacos，会读取本地快照完成启动。

这是 Nacos 在 AP 路径上设置的又一道保险。

但需要注意两点：

• 缓存的是上一次的快照，并非最新数据。
• 在 Nacos 完全宕机期间，新实例上下线以及配置变更均无法被感知。

线上排查时，遇到“Nacos 挂了一会儿，业务居然没受影响”的情况，原因往往就出在这个缓存机制上。

七、把这些模块拼起来，看 Nacos 的“性格”

将本文的几块内容整合起来，Nacos 的内核性格便清晰可见：

可以用一句话概括它的设计哲学：

这种性格在当今的微服务体系下非常契合。它并未试图抢占 Kafka、Etcd、ZooKeeper 各自擅长的领域，而是把“服务与配置”这两个最高频的场景做深做透。

八、看完原理，对实际接入有何启发

读懂原理之后，有几个习惯值得调整：

• 不再纠结“Nacos 是 AP 还是 CP”。它两者兼具，取决于你使用哪个模块。
• 配置中心至少部署 3 节点。这不是建议，而是底线。
• 业务侧默认要做熔断。注册中心永远无法达到 100% 可靠。
• 临时实例的假死问题，要靠 K8s 探针 + 熔断双重保险来应对。
• 配置走 long-polling 完全可行，但必须理解本地缓存的机制，否则可能被“看似推送实则缓存”的现象所迷惑。

这些并非新鲜知识，但只有真正理解了底层机制，你才会自然而然地付诸实践，而不是靠“踩一个坑才学一句”。

九、总结：内核并不复杂，但每一步都务实

Nacos 的内核并没有那种令人眼前一亮的炫酷算法。

它更像是出自一位老练工程师之手：

• 该选 AP 时就选 AP
• 该选 CP 时就选 CP
• 推送做不到真正实时，就用 long-polling 来模拟
• 客户端做缓存作为兜底
• 实例分为临时和持久，以应对不同的生命周期需求

每一步都对一线工程问题给出了清晰的回应。这正是它能支撑起国内绝大多数互联网公司微服务底座的原因所在。

下一篇将把它真正放入生产环境：多环境如何切换、集群如何搭建、踩过哪些坑、Nacos 3.0 引入的 AI Registry / MCP 管理究竟意味着什么。