系列导读
前面几篇我们从单机视角拆解了 Nacos 的注册中心、配置中心、Distro 协议与 Raft 协议。但生产环境从来不会只部署一个节点，如何把 Nacos 搭成一个跨机房、甚至跨地域的高可用集群？节点之间如何同步数据？客户端怎么做到就近访问？扩缩容时要注意什么？这篇将为你补上运维落地的关键一环，让你不仅能“看懂” Nacos，还能“用好” Nacos。

---

一、Nacos 集群的基础部署模式

1.1 对等节点集群

Nacos 集群并不像 ZooKeeper 那样有明确的 Leader/Follower 角色划分，所有服务端节点地位对等，都可以处理读写请求。但在具体一致性协议的层面上：

• 对于服务发现模块（Distro），所有节点是对等的，通过一致性哈希分配部分数据的“写责任”，但读能力完全对等。

• 对于配置中心模块（Raft），节点间有 Raft 协议的 Leader 和 Follower 角色，但这是 JRaft 内部的状态，对运维透明。

所以在物理部署时，你只需要启动多个 Nacos 实例，并通过 cluster.conf 让它们互相认识即可。

1.2 最小高可用集群

通常推荐部署 3 个节点（或更多奇数节点）。3 节点集群可以容忍 1 台宕机，同时满足 Raft 过半写入的要求，也是成本与可靠性的最佳平衡点。

部署结构如下：

text

     ┌─────────┐
     │ Nacos 1 │
     └────┬────┘
          │
┌─────────┼─────────┐
│         │         │
│    ┌────┴────┐    │
│    │ Nacos 2 │    │
│    └────┬────┘    │
│         │         │
│    ┌────┴────┐    │
└────│ Nacos 3 │────┘
     └─────────┘

所有节点配置相同的数据库（MySQL），并在 cluster.conf 中列出彼此地址。启动后，Distro 和 Raft 会自动发现节点并运行。

---

二、跨机房部署与数据同步策略

当业务规模扩大，需要跨机房甚至跨地域部署时，网络延迟和分区问题成为最大挑战。Nacos 的两种一致性协议在不同场景下表现截然不同。

2.1 服务发现（AP）的跨机房同步

在 Distro 协议下，各节点独立存储全量服务数据。跨机房部署时，同城低延迟的机房（延迟 < 5ms）可以直接组成一个 Nacos 集群，节点间心跳和同步延迟极小，对业务影响可控。

但当机房跨越地域（如北京 → 上海），网络延迟达到几十毫秒甚至百毫秒时，将两地节点强行放入一个集群将导致 Distro 同步严重滞后，甚至心跳超时误判。此时推荐的做法是：

• 每个数据中心搭建独立 Nacos 集群。

• 通过 Nacos-Sync 工具 实现跨数据中心的服务同步。

2.2 Nacos-Sync：跨集群服务同步利器

Nacos-Sync 是 Nacos 生态里的多集群数据同步组件，支持从一个 Nacos 集群向另一个同步服务列表和实例信息。其原理是：

1. 部署一个独立的 Sync 服务（通常靠近目标集群）。

2. 配置源集群和目标集群的地址。

3. 监听源集群的服务变更事件（注册、摘除、心跳超时）。

4. 将变更事件转换成目标集群的 API 调用，写入目标集群。

这样，北京集群的服务变化会通过 Sync 工具同步到上海集群，上海的应用只需连接本地 Nacos 就能发现异地服务。同步有延迟（通常 1~3 秒），但能满足绝大多数异地容灾需求。

2.3 配置中心（CP）的跨机房挑战

配置中心依赖 Raft 达成强一致。Raft 的日志提交要求半数以上节点确认，如果集群节点跨越延迟较高的广域网，写入延迟将显著上升（每次写都要等待慢链路确认），吞吐量急剧下降。

因此，强烈不建议将 Raft 集群节点部署在异地机房。推荐实践：

• 配置中心集群与数据库部署在同一个数据中心（网络低延迟）。

• 其他数据中心的应用通过 配置中心域名 直接访问主数据中心（或通过 CDN、反向代理等加速读取）。

• 如果必须异地多活，可采用“一主多从”模式：主集群承担写请求，从集群通过同步订阅配置数据，只提供读取，但 Nacos 本身不内置此机制，需要业务二次开发或使用消息队列复制配置变更。

一个折衷方案是利用 Nacos 的 多租户 + 灰度 功能，将配置按地域隔离发布，减少跨地域的强一致性依赖。

---

三、客户端就近访问与路由策略

跨机房部署时，我们希望消费者优先调用同机房的提供者，降低调用延迟。Nacos 通过 集群标签（Cluster） 实现就近访问。

3.1 实例的集群属性

服务实例注册时可以携带一个 clusterName 字段，如 BJ-CLUSTER、SH-CLUSTER。Nacos 不会自动为实例分配地理位置，需要应用启动时从环境变量或配置中获取并设置。

3.2 消费者的路由策略

Nacos SDK 在获取服务实例列表时，支持指定集群。如果未指定，默认行为是：

1. 先获取服务下所有集群的实例列表。

2. 优先使用与调用方属于同一集群的实例。

3. 如果同集群无健康实例，则降级到其他集群。

这样天然实现了就近路由。客户端只需正确配置自己的 clusterName，无需额外路由规则。

3.3 权重与负载均衡

在就近访问的基础上，Nacos SDK 结合权重（weight）做负载均衡。权重可以在控制台动态调整，也可以结合 Sentinel 等组件做细粒度的流量控制。对运维来说，只需保证同机房实例的权重设置合理即可。

---

四、容量评估与扩缩容

4.1 容量评估关键指标

• 实例数量：临时实例会频繁心跳和 Distro 同步，每增加 1000 个实例，心跳请求约 200 QPS（按 5 秒间隔算）。服务端内存中注册表大小与实例数成正比。

• 配置数量：配置主要是存储和推送，数量不大时压力很小，但若存在大量监听长连接（特别是 HTTP 长轮询），需要关注连接数。

• 客户端连接数：Nacos 2.x 的 gRPC 模式下，每个客户端会与服务端建立一条双向流长连接。单节点 2~3 万连接是常见上限，可通过压测确定。

• 推送频率：配置变更频率不高时可以忽略；如果业务频繁做配置灰度发布，需要关注同时推送时的网络带宽和 CPU。

4.2 扩缩容操作

扩容：

1. 准备好新节点的安装包和数据库连接配置。

2. 在 cluster.conf 中添加新节点 IP，并将此配置同步到所有节点（包括新节点）。

3. 启动新节点，Nacos 会自动注册到集群。

4. Distro 一致性哈希环会重新计算，部分服务实例的责任节点将迁移到新节点。现有节点会向新节点同步这些数据，无需人工干预。

5. 更新 Nginx/SLB 的后端列表，将流量引入新节点。

缩容：

1. 从负载均衡中先摘除要下线的节点，停止新连接进入。

2. 等待该节点上的长连接自然断开（或主动通知客户端重连）。

3. 停止 Nacos 进程，然后从各节点的 cluster.conf 中移除该节点 IP。

4. 重新调整哈希环，被移除节点负责的数据会自动重新分配到其他节点。

4.3 注意事项

• 变更 cluster.conf 后需重启：cluster.conf 默认加载后就固定在内存，修改后一般需要滚动重启才能生效。2.x 版本支持动态加载，但谨慎期间仍建议重启。

• 避免同时下线多台：同时缩容多台可能导致数据不一致窗口扩大，应逐台操作。

• 数据库连接池：集群节点数增加，数据库连接池大小也需相应增加。

---

五、高可用部署架构推荐

综合以上，一个典型的生产环境 Nacos 部署架构如下：

text

            用户流量
               │
        ┌──────┴──────┐
        │  SLB/Nginx  │
        └──────┬──────┘
               │
   ┌───────────┼───────────┐
   │           │           │
┌──▼──┐   ┌───▼──┐   ┌───▼──┐
│Nacos│   │Nacos │   │Nacos │  ← 数据中心A，同机房3节点
│  1  │   │  2   │   │  3   │
└──┬──┘   └──┬───┘   └──┬───┘
   │         │         │
   └─────────┼─────────┘
             │
        ┌────▼────┐
        │  MySQL  │  (主库，跨机房备库)
        └─────────┘

        ─────────── 异地分割线 ───────────

   ┌───────────┐
   │ Nacos-Sync│  ← 同步服务列表到数据中心B
   └─────┬─────┘
         │
   ┌─────▼─────┐
   │ Nacos集群 │  ← 数据中心B，独立集群
   │  (3节点)  │
   └───────────┘

• 每个数据中心内部 Nacos 集群独立，保证低延迟写入。

• 配置中心统一走主数据中心，Raft 集群不跨地域。

• 服务数据通过 Nacos-Sync 跨中心同步，实现异地多活。

• DNS 或全局负载均衡根据用户所在区域将流量就近路由到对应集群。

---

六、总结与下篇预告

本篇核心要点回顾：

• Nacos 集群节点对等，通过 cluster.conf 互相发现，推荐 3 节点以上奇数部署。

• 服务发现跨机房可通过独立集群 + Nacos-Sync 实现最终一致性同步。

• 配置中心由于 CP 强一致限制，不建议跨地域部署 Raft 节点，应集中在同一数据中心。

• 客户端通过 clusterName 实现就近访问，降级机制保障高可用。

• 扩缩容依赖 Distro 哈希环自动调整，但需注意 cluster.conf 的更新和滚动重启。

学完了部署与高可用，你已经有了完整的理论储备。但从下一讲开始，我们要“不讲武德”了——直接打开源码，逐行剖析。第 7 篇《源码拆解：服务发现模块关键实现》将从代码层面看 Distro 如何实现注册、心跳和同步。准备好你的 IDE，我们一起来挖地三尺。

---

本系列持续更新，从原理走向源码。如果觉得有帮助，欢迎点赞、收藏，关注我第一时间获得更新。你的问题可以在评论区提出，我会尽量在后续文章中解答。