Appearance
Nacos 集群
单节点 Nacos 只适合本地开发验证。真正给一组应用使用时需要集群——目的不是多开几个控制台页面,而是让配置读取、服务注册和客户端连接不因为一个 Nacos 进程挂掉就整体不可用。
一、集群结构
三节点 Nacos + 一套 MySQL 是最小的集群形态:
三个节点是比较常见的起点:两个节点出现网络分区时无法区分"对方挂了"和"网络断了",三个节点用奇数投票不会出现平局。节点过多则通信和维护成本变高。实验里 MySQL 还是单点,所以这只是 Nacos 服务层的集群验证——生产环境中 MySQL 也要做高可用。
二、集群文件 cluster.conf
cluster.conf 是节点互相识别的入口:
text
192.168.10.11:8848
192.168.10.12:8848
192.168.10.13:8848三台机器内容必须完全一致。写的是 8848(服务端 API 端口),不是控制台 8080。如果某台节点没写进 cluster.conf,它可能自己启动但不加入集群——进程在跑,端口在监听,但集群管理页面看不到它。
三、集群通信端口
节点之间需要互通的端口不止 HTTP:
| 端口 | 用途 | 互访要求 |
|---|---|---|
8848 | HTTP API | 节点间需要互通 |
9848 | 客户端 gRPC | 业务应用到 Nacos |
9849 | 服务端 gRPC | 节点之间必须互通 |
7848 | 集群一致性(Raft)通信 | 节点之间必须互通 |
bash
# 每台节点确认端口监听
ss -lntp | egrep ':(8848|9848|9849|7848)\b'
# 从一台测试到另一台的连通性
nc -vz 192.168.10.12 8848
nc -vz 192.168.10.12 9848
nc -vz 192.168.10.12 9849
nc -vz 192.168.10.12 7848本机监听正常只说明进程启动成功。防火墙、安全组、路由问题仍然可能让节点间看不见彼此。排查一个集群中"只有本机"的问题时,先从端口连通性查起。
四、外部 MySQL 的共享角色
三台 Nacos 指向同一个 MySQL 数据库,目的是看到同一套配置、用户和权限数据:
properties
spring.sql.init.platform=mysql
db.num=1
db.url.0=jdbc:mysql://192.168.10.11:3306/nacos_config?characterEncoding=utf8&connectTimeout=10000&socketTimeout=30000&autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai
db.user.0=nacos
db.password.0=Nacos@123456Nacos 里不同类型数据的一致性机制不同:
| 数据类型 | 一致性依赖 |
|---|---|
| 配置数据 | 依赖 MySQL 保证持久化和多节点读一致 |
| 服务实例(临时) | 依赖心跳 + 节点间 gRPC 同步 + 客户端缓存 |
| 权限和用户 | 存储在 MySQL,三节点共享同一份 |
验证配置数据一致性的直接方式——分别从三节点读同一配置,返回一致才算通过。
五、集群管理页面怎么看
控制台集群管理页面能看到节点列表,核心关注:
| 字段 | 正常值 |
|---|---|
| 节点数量 | 等于 cluster.conf 里配置的数量 |
| 节点状态 | 全部为 UP |
| 版本 | 三台一致 |
| Raft 端口 | 正确 |
节点状态 UP 表示集群视角下该节点可用。如果节点数量少了一台:先看那台的 Nacos 进程是否在跑 → cluster.conf 内容是否一致 → 通信端口是否互通。
六、节点故障时的影响
单个 Nacos 节点故障后,客户端能否自动切换取决于接入方式:
| 接入方式 | 行为 |
|---|---|
| 客户端写多个 Nacos 地址 | 依赖客户端 SDK 重试其他地址 |
| 前面放负载均衡(VIP/域名) | 应用只连一个入口,负载均衡需对 Nacos 做健康检查 |
| K8s 内部 Service | 集群内应用通过 Service 访问,K8s 负责转发 |
负载均衡的健康检查不能只看端口通不通——端口通但 Nacos 内部接口异常时,负载均衡仍会把流量打下发到故障节点。健康检查应该访问 Nacos 的实际接口,比如登录 API 或配置读取 API。
七、升级和维护顺序
滚动操作方式:
text
1. 停止一个节点(或从负载均衡摘除)
2. 确认业务客户端仍在连接其他节点(看其他节点的连接和日志)
3. 升级或修改该节点的配置
4. 启动,确认控制台状态回到 UP
5. 观察一段时间(配置读写、服务注册恢复正常)
6. 再操作下一台升级前备份:MySQL 数据库、application.properties、cluster.conf、systemd unit。Nacos 版本升级可能涉及配置项改名、数据库 schema 变更、API 路径变化——不能只替换二进制包。
八、常见集群异常
| 现象 | 排查方向 |
|---|---|
| 节点启动但不入集群 | cluster.conf 内容不一致、节点间端口不通 |
| 控制台只看到一个节点 | 其他节点的进程、端口、cluster.conf |
| 配置发布失败 | MySQL 连接、鉴权配置、数据库 schema 版本 |
| 某节点读到配置异常 | 该节点的 MySQL 连接或鉴权参数与其他节点不一致 |
| 服务实例频繁掉线 | 客户端心跳间隔、网络抖动、gRPC 端口不通 |
| 版本显示不一致 | 软链接指向不同版本目录,升级不完整 |
集群排查的效率取决于是否三台一起对比——配置文件、进程参数、端口监听、日志时间点、控制台节点列表。单独看一台,很容易漏掉"只有这一台配得不一样"的问题。