系列：Nacos 三篇实践笔记
上一篇：[01｜重新拾起 Nacos：为啥团队最后还是回到了它]
下一篇：[03｜Nacos 生产落地：多环境、踩坑、和 3.0 的 AI Registry 演进]
这一篇专门讲原理。不深挖代码，但把"为啥这样设计"讲透。
一、想用好 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 的内核性格就出来了：
可以用一句话概括它的设计哲学：
能 AP 就 AP，必须 CP 才 CP；写得快、推得近实时、客户端兜得住。
这个性格放在今天的微服务体系里非常合适。它没有去抢 Kafka、Etcd、ZooKeeper 各自擅长的领地，而是把"服务和配置"这两件最高频的事做扎实。
八、看完原理，对接入有什么启发
读完原理我自己改了几个习惯：
- 不再去纠结"Nacos 是 AP 还是 CP"。它两边都是，看你用哪一块。
- 配置中心至少 3 节点。这不是建议，是底线。
- 业务侧默认要做熔断。注册中心永远不能 100%。
- 临时实例假死要靠 K8s 探针 + 熔断双保险。
- 配置走 long-polling 没问题，但本地缓存要懂，否则会被"看起来推送了实则缓存"骗到。
这些不是新东西，但你只有理解了机制，才会自然把这些动作做出来，而不是靠"踩一个坑学一句"。
九、总结：内核不复杂，但每一步都很务实
Nacos 的内核没有那种让人眼前一亮的算法。
它做的事更像一个老练工程师写出来的东西：
- 该选 AP 选 AP
- 该选 CP 选 CP
- 推送做不到真推就用 long-polling 拟一个
- 客户端做缓存兜底
- 实例分临时和持久应对不同生命周期
每一步都对一线工程问题有清楚回应。这就是为什么它能撑住国内绝大多数互联网公司的微服务底座。
下一篇我会把它真正放进生产环境：多环境怎么切、集群怎么搭、踩过哪些坑、Nacos 3.0 加进来的 AI Registry / MCP 管理到底意味着什么。
上一篇：[01｜重新拾起 Nacos：为啥团队最后还是回到了它]
下一篇：[03｜Nacos 生产落地：多环境、踩坑、和 3.0 的 AI Registry 演进]
