第9课：Nacos集群高可用部署 生产级故障容灾方案

适配版本：Nacos Server 3.1.1、Nacos Client 3.1.1、Spring Cloud Alibaba 2025.1.0.0、Spring Boot 4.0.8、MySQL 8.0+、JDK 21
课程定位：注册中心阶段收官，从单机到生产集群，构建高可用、可容灾的Nacos服务体系

一、开篇：单机版Nacos的生产“死穴”

第6-8课我们完成了Nacos注册中心从环境搭建到高级治理的完整能力建设。但到目前为止，所有实验都基于单机版Nacos。单机版存在两个致命问题：

问题一：单点故障。Nacos Server一旦宕机，所有服务的注册、发现、配置读取全部中断。虽然客户端有本地缓存可以短暂支撑，但新服务无法注册、配置无法更新，整个微服务系统处于“半瘫痪”状态。

问题二：数据丢失风险。单机模式默认使用内置Derby数据库，数据存储在本地文件中。磁盘损坏或误操作会导致所有服务注册信息和配置数据永久丢失。

生产环境必须部署Nacos集群。但集群部署远不止“多启动几个节点”那么简单——需要解决数据持久化（MySQL）、一致性协调（Raft）、脑裂预防、客户端容灾等多个工程问题。本课将从架构设计讲到部署实战，从Raft协议讲到脑裂预防，从监控告警讲到服务雪崩预防，完整覆盖Nacos从单机到生产集群的全部关键点。

二、集群架构设计

2.1 官方推荐架构

Nacos官方推荐的集群部署架构是：多个Nacos节点 + 共享MySQL + 内网SLB/VIP。

┌─────────────────────────┐ │ Client (Spring Cloud) │ │ server-addr: nacos.com │ └────────────┬────────────┘ │ ┌────────────┴────────────┐ │ SLB / VIP / Nginx │ │ (内网负载均衡，不暴露公网)│ └────────────┬────────────┘ │ ┌──────────────────────┼──────────────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Nacos-1 │ │ Nacos-2 │ │ Nacos-3 │ │ :8848 │ │ :8848 │ │ :8848 │ │ :9848 │ │ :9848 │ │ :9848 │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────────────┼─────────────────────┘ │ ┌──────────┴──────────┐ │ MySQL 主从集群 │ │ (存储配置和注册数据) │ └─────────────────────┘

核心设计要点：

• 节点数量：生产环境至少3个节点，推荐使用奇数节点（3、5、7），避免偶数节点在网络分区时两边均无多数派。
• SLB/VIP：客户端通过统一的域名或VIP访问集群，不直连具体节点。推荐使用“域名 + SLB”模式，可读性好且换IP方便。
• MySQL共享存储：所有Nacos节点共享同一个MySQL数据库，配置和服务元数据统一持久化，避免Derby数据库的集群同步复杂性。生产环境强烈推荐使用MySQL，而非内置Derby。
• 网络要求：Nacos节点应部署在同一局域网、同一网段，减少跨机房网络延迟和中断风险。

2.2 端口规划

Nacos 3.x的端口体系与2.x不同，需要特别注意：

在使用SLB/VIP时，需要开放8848、9848两个端口的映射，如果修改了主端口，需要相应调整映射配置。

三、MySQL数据源配置与初始化

3.1 初始化数据库

Nacos集群必须使用外部MySQL数据库（推荐MySQL 5.6.5+，生产建议8.0+）。首先创建数据库和用户：

CREATEDATABASEnacos_configCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ci;CREATEUSER'nacos'@'%'IDENTIFIEDBY'Nacos@2026!';GRANTALLPRIVILEGESONnacos_config.*TO'nacos'@'%';FLUSHPRIVILEGES;

然后执行Nacos提供的初始化脚本mysql-schema.sql（位于nacos/conf/目录下），创建所有必要的表结构。

3.2 配置application.properties

在每个Nacos节点的conf/application.properties中配置MySQL数据源：

# ===== 数据源配置 ===== spring.sql.init.platform=mysql db.num=1 db.url.0=jdbc:mysql://192.168.1.100:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true db.user=nacos db.password=Nacos@2026!

关键参数说明：

• connectTimeout=1000：连接超时1秒，快速判定数据库不可用
• autoReconnect=true：MySQL连接断开后自动重连，避免Nacos因数据库闪断而崩溃
• allowPublicKeyRetrieval=true：MySQL 8.0+的RSA公钥认证需要此参数

3.3 集群配置文件cluster.conf

在nacos/conf/cluster.conf中配置集群所有节点的IP和端口，每行一个节点，必须配置3个或以上：

192.168.1.101:8848 192.168.1.102:8848 192.168.1.103:8848

踩坑提示：cluster.conf的所有节点配置必须完全一致。如果某个节点的配置缺少其他节点，会导致该节点被排除在集群之外，Raft无法形成多数派。

3.4 鉴权配置（3.x必配）

自Nacos 3.0.0起，控制台鉴权默认开启，必须配置鉴权相关参数：

# 开启客户端访问鉴权（3.x中默认关闭，生产推荐开启） nacos.core.auth.enabled=true # 开启控制台访问鉴权（3.x中默认开启） nacos.core.auth.console.enabled=true nacos.core.auth.system.type=nacos # Token密钥（所有节点必须一致，生产环境务必替换默认值） nacos.core.auth.plugin.nacos.token.secret.key=${自定义长密钥，至少32位} # 服务端身份标识（所有节点必须一致） nacos.core.auth.server.identity.key=${自定义key} nacos.core.auth.server.identity.value=${自定义value}

⚠️安全警告：文档中的默认SecretKey是公开值，仅用于临时测试。生产环境必须替换为自定义的有效值，且所有节点保持一致。

3.5 JVM参数优化

生产环境的Nacos需要调整JVM参数。在conf/jvm.options中设置：

-Xms4g-Xmx4g-XX:MetaspaceSize=256m-XX:MaxDirectMemorySize=2g

堆内存建议不低于4G，直接内存不足会导致Raft日志持久化失败。

四、启动集群与验证

4.1 逐台启动节点

在每个节点上执行：

cd/opt/nacos/binshstartup.sh

注意：集群模式下不加-m standalone参数。

4.2 验证集群状态

启动完成后，通过API查看集群节点状态：

curl-XGET'http://192.168.1.101:8848/nacos/v1/core/cluster/nodes'

预期返回所有节点状态为UP：

{"nodes":[{"ip":"192.168.1.101","state":"UP"},{"ip":"192.168.1.102","state":"UP"},{"ip":"192.168.1.103","state":"UP"}]}

4.3 客户端配置

在微服务的application.yml中，将server-addr配置为SLB/VIP地址或所有节点地址：

spring:cloud:nacos:discovery:server-addr:nacos.example.com:8848# 或：192.168.1.101:8848,192.168.1.102:8848,192.168.1.103:8848

使用多个IP时，Nacos客户端会维护一个“无序列表”，自动感知节点故障并切换到健康节点。

五、Raft一致性协议与脑裂预防

5.1 Raft在Nacos中的角色

Nacos的配置管理使用CP模型，底层基于SOFAJRaft实现强一致性。Raft通过三个角色协同工作：

• Leader：集群唯一，处理所有写请求，定期发送心跳维持权威
• Follower：被动接收Leader的心跳和日志复制
• Candidate：Follower到Leader的竞选状态，发起投票争取成为Leader

Raft的多数派原则是防止脑裂的核心：选举Leader时必须获得超过半数节点（(n/2)+1）的投票；日志提交必须同步到超过半数节点才能生效。

5.2 Leader宕机的自动恢复

假设3节点集群A（Leader）、B、C中A宕机：

1. A停止心跳后，B和C的随机选举超时（150ms~300ms）触发
2. 先超时的节点（假设B）变为Candidate，term加1，向C发送投票请求
3. B获得自己+C的2票，超过半数，成为新Leader
4. A恢复后，发现B的term更高，自动降级为Follower

整个过程通常在1秒以内完成。

5.3 脑裂的产生与预防

什么是脑裂：网络分区导致集群被分割为多个独立子集群，每个子集群各自选举Leader并独立处理请求，最终引发数据不一致。

脑裂产生的原因：

• 网络分区：交换机故障、防火墙隔离导致节点间通信中断
• 节点误判：GC卡顿导致心跳延迟，被误判为下线
• 集群配置不合理：偶数节点在网络分区时两边均无法形成多数派

预防措施：

措施一：使用奇数节点。3节点最多容忍1个故障，5节点最多容忍2个故障。

措施二：优化网络稳定性。节点部署在同一局域网，增加网络冗余（双交换机），调整Raft超时参数：

# Raft选举超时（默认5秒，网络差时可增大到10秒） nacos.core.protocol.raft.election-timeout-ms=10000 # 心跳间隔（默认500ms，避免过短导致网络风暴） nacos.core.protocol.raft.beat-interval-ms=1000

措施三：统一cluster.conf配置。所有节点的cluster.conf必须包含全部节点，避免配置不一致导致节点被排除。

措施四：使用外部数据库。将数据持久化到MySQL，即使集群短暂脑裂，恢复后数据仍可从数据库同步。

六、生产级容灾方案

6.1 客户端本地容灾

Nacos客户端内置了本地容灾能力。当Nacos Server不可用时，客户端自动使用本地缓存的实例列表继续提供服务发现。还可以开启本地文件缓存持久化，使应用重启后仍能复用缓存：

spring:cloud:nacos:discovery:naming-cache-persist:true# 开启本地缓存持久化

在Nacos运行期间，如果突现接口不可用或数据异常，可以快速开启容灾模式，让客户端使用容灾数据，等Nacos服务端恢复后再关闭。

6.2 集群 + 共库 vs 单节点 + 共库

两种容灾方案的对比：

单节点+共库的“多IP隔离”方案在故障时会导致客户端反复重试、重复清理临时实例、配置推送重复等问题。集群+共库方案通过Raft保证集群行为统一，是生产环境的首选。

6.3 服务雪崩预防

Nacos集群不可用可能引发服务雪崩。预防措施包括：

第一层：Nacos集群高可用。3节点集群 + MySQL主从，容忍单节点故障。

第二层：客户端本地缓存。开启naming-cache-persist，Nacos不可用时仍能调用已知服务。

第三层：Sentinel熔断降级。当调用失败率超过阈值时自动熔断，返回降级响应（第21-24课详解）。

第四层：服务调用重试。在Feign客户端配置合理的重试策略，避免因Nacos短暂抖动导致调用失败（第15课详解）。

七、生产监控配置

7.1 核心监控指标

Nacos集群需要监控的关键指标：

7.2 Prometheus + Grafana方案

Prometheus配置：

scrape_configs:-job_name:'nacos'metrics_path:'/nacos/v1/ns/operator/metrics'static_configs:-targets:['192.168.1.101:8848','192.168.1.102:8848','192.168.1.103:8848']

Grafana仪表盘应包含：集群概览（节点状态矩阵）、服务注册趋势、JVM健康度（堆内存使用率）、告警中心。

7.3 容灾验证实战

定期模拟节点故障，验证集群自动恢复能力：

# 手动停止Node2（模拟宕机）# 观察服务发现请求自动路由到Node1/Node3# 验证结果：故障后20秒内，节点列表仅包含Node1和Node3

八、踩坑指南

坑一：cluster.conf配置不一致

现象：集群启动后部分节点状态异常，或客户端报错。

原因：不同节点的cluster.conf内容不一致，导致Raft无法形成多数派。

解决：确保所有节点的cluster.conf完全一致，包含全部集群节点。

坑二：使用偶数节点

现象：网络分区时集群完全不可用。

原因：偶数节点在网络分区时两边均无法形成多数派。

解决：使用奇数节点（3、5、7），3节点集群最多容忍1个故障。

坑三：鉴权密钥使用默认值

现象：集群可被外部恶意访问。

原因：nacos.core.auth.plugin.nacos.token.secret.key未修改，使用了文档中的公开默认值。

解决：替换为自定义的至少32位长密钥，且所有节点一致。

坑四：MySQL连接闪断导致Nacos崩溃

现象：MySQL短暂不可用后，Nacos节点无法恢复。

原因：数据库连接配置缺少autoReconnect=true。

解决：在db.url.0中添加autoReconnect=true参数。

坑五：JVM直接内存不足

现象：Raft日志持久化失败，集群状态异常。

原因：JVM的MaxDirectMemorySize设置过小。

解决：在jvm.options中设置-XX:MaxDirectMemorySize=2g，堆内存建议不低于4G。

九、课后作业

作业一：使用3台虚拟机（或Docker容器）搭建Nacos 3.1.1集群，配置MySQL共享数据源，验证3个节点状态均为UP。记录cluster.conf和application.properties的完整配置。

作业二：将第5课的microservice-platform中的service-user和service-order的server-addr改为集群地址，验证服务在集群环境下正常注册与发现。

作业三：模拟一个Nacos节点宕机，验证：1）集群中其他节点是否正常工作；2）客户端调用是否中断；3）宕机节点恢复后是否自动重新加入集群。

作业四（进阶）：配置Prometheus采集Nacos集群指标，在Grafana中搭建仪表盘，至少包含JVM内存使用率和服务注册实例数两个面板。

十、下节预告

第10课将进入配置中心核心阶段——Nacos配置中心核心原理 & 动态配置实战。我们将从分布式配置的痛点出发，深入Nacos配置中心的架构模型、配置推送原理（长轮询机制）、基础配置加载、动态刷新配置和注解使用。注册中心阶段的Nacos Discovery至此收官，配置中心阶段的Nacos Config即将开启。

🔗《最新版 SpringCloud 2025 从入门到实战》系列课程导航

去订阅

第一部分：微服务前置基础 & 新版环境搭建（第1-5课）
第二部分：注册中心核心（Nacos 最新版）（第6-9课）
第三部分：配置中心核心（Nacos配置中心）（第10-12课）
第四部分：服务通信核心（OpenFeign + LoadBalancer）（第13-16课）
第五部分：网关核心（SpringCloud Gateway 新版）（第17-20课）
第六部分：熔断、限流、降级（Sentinel 新版）（第21-24课）
第七部分：微服务监控、链路追踪、日志体系（第25-28课）
第八部分：微服务高阶特性 & 分布式核心能力（第29-31课）
第九部分：企业级完整项目实战 & 架构复盘（第32-35课）