02 Nacos 内核拆一拆：Distro、Raft、长轮询到底在干啥

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

很多人对 Nacos 的认知是"一个工具"。其实它内部干的是两件性质完全不同的活：

服务注册与发现：要快、要可用，丢一两条问题不大。 配置管理：可以慢一点，但绝对不能丢。

这两件事天然要不同的一致性策略。Nacos 的内核就是按这个差异分两套的：

模块	一致性	协议	典型 CAP 取舍
服务发现	最终一致	Distro（Nacos 自研）	AP
配置管理	强一致	Raft（JRaft 实现）	CP

把这张图刻在脑子里，后面所有东西都好理解了。

二、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。Nacos 配置最终落库（默认 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 管理到底意味着什么。