线上服务从十几个拆到四十多个之后最难受的不是联调而是改一个数据库地址要挨个翻配置文件、挨个重启。更致命的是注册中心和配置中心这类基础组件一旦挂掉业务方连启动都起不来只能干等。Nacos 干的就是这件事——服务注册发现、动态配置管理一套系统两个能力。这篇内容把我用 Docker 搭 Nacos 集群的完整过程摊开写从单机验证到三节点集群、从数据库初始化到 Nginx 四层接入、从启动参数到实际踩过的坑全部是可复现的命令和配置。适合已经会用 Docker、但被 Nacos 的 cluster.conf、端口偏移、节点发现折腾过的人。如果只是想本地跑个 Nacos 玩一玩看完第 3 节就够要做生产环境第 4 到第 7 节才是重点。1. 先定方案三节点集群到底该怎么摆动手敲命令之前有几个决策必须先定下来集群规模、网络模式、数据落盘方式。这几个决策定错了后面所有配置都是白费功夫排查起来还特别费劲。我在第一次搭的时候图省事用了默认 bridge 网络结果集群节点互相找不到日志里全是重连折腾了一整天才定位到是容器 IP 不通。1.1 单机模式藏着三个隐患大部分人是先用单机模式跑通然后一直没换。单机模式在开发环境没问题放到线上就有三个硬伤。第一个是单点故障。Nacos 挂了已经跑着的服务还能撑一阵但新实例无法注册、配置无法拉取滚动发布直接失败。第二个是数据不可迁移。单机模式默认用内嵌的 Derby 数据库数据写在容器内的本地文件里换台机器就得把整个数据目录搬走而且没法多节点共享。第三个是配置无兜底。单机没有节点间同步误改一个配置、误删一个服务没有别的节点可以做对比恢复。一个很常见的误操作以为把MODE改成cluster再加几台机器就是集群了但数据库还是 Derby。这种假集群每个节点的数据都是独立的客户端打到哪台就看到哪份数据比单机还危险。1.2 选 Docker 而不是裸机部署的取舍裸机部署 Nacos 要自己装 JDK、配环境变量、写 systemd 服务、管日志轮转一套下来半小时起步换版本还得重来一遍。Docker 方式把这堆事情压成了一个镜像JDK 版本随镜像走配置文件用挂载覆盖日志用 volume 落到宿主机升级就是换 tag 重启。资源也能限制--memory和--cpus直接卡住避免某个节点把宿主机内存吃干。代价也有。容器网络需要额外理解尤其是集群节点之间的互访地址日志在容器里排查时得多敲一条docker logs镜像内的默认 JVM 参数是 2G 堆小机器上不加限制会直接把容器撑爆。这些代价我觉得完全值得因为换来的是可重复——一台机器上的配置能原封不动复制到另外两台。1.3 端口与拓扑规划Nacos 2.x 的端口比 1.x 复杂很多人只映射了 8848结果客户端连得上控制台、注册却一直超时。关键是要理解端口的偏移规则主端口 N客户端 gRPC 端口是 N1000服务端 gRPC 端口是 N1001。端口用途说明8848HTTP / 控制台 / OpenAPI主端口可改9848客户端 gRPC固定为 88481000客户端长连接走这里9849服务端 gRPC固定为 88481001集群节点间同步走这里7848集群内部通信旧版 Raft 端口2.x 仍保留3306外部 MySQL三节点共用一份数据如果要把主端口改成 8858那么 9848 变 9858、9849 变 9859、7848 变 7858三个都得跟着改客户端配置也要同步。所以我一般不建议改端口省得后面自己都记不清。拓扑上我推荐三节点因为 Nacos 集群是多数派可用的模型两个节点挂一个就不可用三个节点挂一个还能正常服务。机器规格上4 核 8G 跑一个节点绰绰有余5000 个服务实例以下的规模单节点堆内存给 1G 就够。下面统一用10.0.0.11、10.0.0.12、10.0.0.13三台机器举例MySQL 放在10.0.0.20。2. 动手前的准备镜像、数据库、网络准备工作是最容易被跳过、也最容易出问题的环节。我见过太多次启动失败最后发现是表结构没导、或者账号权限没给全。这一节把三件事做完主机调优、MySQL 初始化、镜像和网络模式选定。2.1 主机基础调优与目录规划三台机器上都要做同样的操作。先调文件句柄数Nacos 2.x 每个客户端维持一条 gRPC 长连接几千个实例就是几千个连接默认的 1024 根本不够用。在/etc/security/limits.conf里加上* soft nofile 65535 * hard nofile 65535改完重新登录生效用ulimit -n确认。时间同步也必须做集群节点间时间差超过一定范围Raft 的心跳和选举会出问题日志里会看到莫名其妙的 leader 切换。容器内时区默认是 UTC如果不处理日志时间和业务时间对不上排查问题时特别痛苦启动时加上-e TZAsia/Shanghai就能解决。目录规划上我习惯在宿主机建/data/nacos/{logs,data}两个目录logs 挂日志、data 挂持久化数据权限给 1000镜像内 nacos 用户的 uid。这么做的好处是容器删了数据还在换镜像重启时直接把目录挂回去配置历史一条不少。2.2 外置 MySQL 的初始化集群模式必须用外置数据库这条没有商量余地。先在 MySQL 上建库建账号CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER nacos% IDENTIFIED BY 换成你的强密码; GRANT ALL PRIVILEGES ON nacos_config.* TO nacos%; FLUSH PRIVILEGES;字符集必须是utf8mb4用utf8存中文配置项会有截断风险。然后导入表结构SQL 文件在镜像里的/home/nacos/conf/mysql-schema.sql可以先起一个临时容器拷出来或者直接从发行包拿。导入后确认关键表都在mysql -h10.0.0.20 -unacos -p nacos_config -e show tables;正常应该看到config_info、his_config_info、config_tags_relation、tenant_info、users、roles、permissions等表。这里有个细节2.x 版本多了灰度相关表如果只导了 1.x 的旧 SQL启动时不会报错但用灰度发布功能时才暴露问题所以务必用当前版本自带的脚本。2.3 镜像版本与网络模式选择镜像我一般锁在nacos/nacos-server:v2.3.2这种明确的小版本上不用latest。原因很实际latest可能在某次拉取后变成大版本而 2.2.0 之后对鉴权的要求变严了没配 token 直接启动失败半夜拉个镜像重启就出事。锁版本之后升级是一次有计划的动作不是意外。docker pull nacos/nacos-server:v2.3.2 docker images | grep nacos网络模式是个关键选择。跨宿主机的集群我强烈建议用--network host理由有三第一端口不用映射9848、9849、7848 全部自然暴露不会漏第二容器内看到的 IP 就是宿主机真实 IPcluster.conf里写什么就是什么不用纠结内外网映射第三gRPC 长连接经过 NAT 映射容易出现连接被回收的问题host 模式绕开了这层。如果环境不允许用 host 模式退而求其次是用自定义 bridge 加固定 IP但必须把PREFER_HOST_MODE设成hostname并且保证容器名可解析配置复杂度直接翻倍。我个人的经验是能用 host 就用 host别给自己找麻烦。3. 三种部署模式递进实操我推荐的路径是先单机验证镜像能不能跑起来再单机连 MySQL 验证配置正确最后上三节点。一步到位直接搭集群出问题时根本分不清是镜像问题、配置问题还是数据库问题。3.1 模式一Derby 单机只用来验镜像这一步纯粹是验证镜像完整性别拿它当开发环境用。docker run -d --name nacos-probe \ -e MODEstandalone \ -e TZAsia/Shanghai \ -p 8848:8848 -p 9848:9848 \ nacos/nacos-server:v2.3.2 docker logs -f nacos-probe看到Nacos started successfully in stand alone mode就说明镜像没问题。浏览器打开http://宿主机IP:8848/nacos2.2.0 之后的版本首次登录会强制要求设置新密码默认账号nacos初始密码也是nacos。这一步验证完就可以把容器删掉docker rm -f nacos-probe。这里有个新手常犯的错只映射了 8848 就以为完事。本地用 curl 调 OpenAPI 确实能通但一旦换成 2.x 的客户端 SDK注册就卡住因为客户端走的是 9848 的 gRPC。记住一句话8848 给了人看9848 给了客户端用。3.2 模式二单机连 MySQL把配置跑通这一步的目的是把数据库连接、鉴权参数、挂载路径全部验一遍成本最低。docker run -d --name nacos-single \ --network host \ --restart always \ -e MODEstandalone \ -e TZAsia/Shanghai \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST10.0.0.20 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORD你的密码 \ -e MYSQL_SERVICE_DB_PARAMcharacterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue \ -e NACOS_AUTH_ENABLEtrue \ -e NACOS_AUTH_TOKEN你的base64密钥 \ -e NACOS_AUTH_IDENTITY_KEYserverIdentity \ -e NACOS_AUTH_IDENTITY_VALUEsecurity \ -e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -v /data/nacos/logs:/home/nacos/logs \ nacos/nacos-server:v2.3.2NACOS_AUTH_TOKEN不是随便写一串字符就行。它的要求是base64 编码后解密长度不少于 32 字节否则启动直接抛The specified key byte array is 0 bits which is not secure enough。生成方式openssl rand -base64 32把输出原样贴进环境变量。这个值三个节点必须完全一致否则节点间鉴权会失败日志里表现为 403。NACOS_AUTH_IDENTITY_KEY和VALUE同理全网统一。启动后用docker logs nacos-single确认没有No DataSource set这类报错再登录控制台新建一个配置项然后去 MySQL 里select * from config_info;看有没有落库。这一步通了说明数据链路是完整的。3.3 模式三三节点集群正式形态三台机器上分别起容器唯一的区别是NACOS_SERVERS里各节点地址相同、nacos.inetutils.ip-address指向本机。先准备cluster.conf三台内容完全一样cat /data/nacos/cluster.conf EOF 10.0.0.11:8848 10.0.0.12:8848 10.0.0.13:8848 EOF然后在每台机器上执行把本机IP换成对应地址docker run -d --name nacos-cluster \ --network host \ --restart always \ -e MODEcluster \ -e TZAsia/Shanghai \ -e PREFER_HOST_MODEip \ -e NACOS_SERVERS10.0.0.11:8848 10.0.0.12:8848 10.0.0.13:8848 \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST10.0.0.20 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORD你的密码 \ -e MYSQL_SERVICE_DB_PARAMcharacterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue \ -e NACOS_AUTH_ENABLEtrue \ -e NACOS_AUTH_TOKEN你的base64密钥 \ -e NACOS_AUTH_IDENTITY_KEYserverIdentity \ -e NACOS_AUTH_IDENTITY_VALUEsecurity \ -e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -v /data/nacos/logs:/home/nacos/logs \ -v /data/nacos/cluster.conf:/home/nacos/conf/cluster.conf \ nacos/nacos-server:v2.3.2挂载cluster.conf和环境变量NACOS_SERVERS是两条并行的路径同时用不冲突但内容必须一致。我见过有人只改了一台机器的cluster.conf另外两台还是旧地址结果集群能起来但总有一个节点显示 DOWN。三台机器上的启动命令可以写成一个脚本用参数传 IP避免手抖改错。启动顺序上我是串行来一台起来看到日志Nacos started successfully in cluster mode再去起下一台中间隔十几秒。虽然同时起也能成但初期节点间互相注册会打一堆重连日志看着心慌串行起来干净。4. 配置文件逐项拆解环境变量方式很方便但一旦参数多了就看不清全貌而且有些配置项没有对应的环境变量。我习惯在集群稳定后把配置抽成挂载的application.properties一眼能看到所有关键项。4.1 application.properties 里必须改的几项把文件放到/data/nacos/application.properties挂载到容器内的/home/nacos/conf/application.properties。核心内容server.port8848 server.servlet.contextPath/nacos server.error.include-messageALWAYS spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://10.0.0.20:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue db.user.0nacos db.password.0你的密码 nacos.core.auth.enabledtrue nacos.core.auth.caching.enabledtrue nacos.core.auth.plugin.nacos.token.secret.key你的base64密钥 nacos.core.auth.server.identity.keyserverIdentity nacos.core.auth.server.identity.valuesecurity nacos.inetutils.ip-address10.0.0.11db.num值得说一句。设成 1 就是所有配置写同一个库设成 3 配db.url.0/1/2就是分库方案Nacos 会按配置的 dataId 做哈希分散到不同库。分库听起来能扛更大压力但运维复杂度翻倍备份恢复也麻烦十万级配置项以内单库加索引完全够用别过早给自己加戏。nacos.inetutils.ip-address在多网卡的机器上很重要。机器上同时有内网网卡和业务网卡时Nacos 可能选错 IP导致cluster.conf里的地址和实际监听的地址对不上节点永远互相看不见。指定死了最省心。4.2 cluster.conf 的写法与三个禁忌这个文件的格式非常简单一行一个ip:port但它是最容易出错的地方。三个禁忌第一不要写127.0.0.1或localhost。每个节点都往自己身上连集群退化成单机。第二不要写容器内的网卡 IPbridge 网络下通常是 172.17.x.x宿主机之间根本不可达。第三端口必须写容器内服务的真实端口不是-p映射出去的那个。用 host 网络时两者相同用 bridge 时就容易搞混。另外这个文件末尾最好别留空行某些版本解析时对空行处理不一致会报格式错误。文件改完之后不需要重启整个容器但要生效最稳妥的办法还是重启或者调/nacos/v1/ns/operator/servers接口触发重新读取。4.3 JVM 参数与内存的账要算清镜像默认的 JVM 参数是-Xms2g -Xmx2g -Xmn1g在 4G 内存的机器上直接跑容器会被撑爆然后 OOMKilled日志里只有一行Killed什么都不告诉你。参数要通过环境变量覆盖环境变量含义建议值4C8G 机器JVM_XMS初始堆1gJVM_XMX最大堆1gJVM_XMN新生代512mJVM_MS初始 Metaspace128mJVM_MMS最大 Metaspace320m算法很简单Xmn取Xmx的 1/3 到 1/2避免大对象直接进老年代引发频繁 Full GC。堆外还要算上 Metaspace、直接内存Netty 的 DirectByteBuffer、线程栈。所以如果给容器加--memory2g限制堆最多给 1.2g剩下 800m 留给堆外和系统否则一定 OOMKilled。想更精细一点可以把 GC 日志打开排查问题时不用猜-e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -e JAVA_OPT-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/nacos/logs/gc.log5. 启动验证与接入层三个容器都起来不代表集群就正常了。必须逐项验证节点状态、数据一致性、客户端可用性最后才是接入层的代理配置。5.1 启动顺序与日志观察我的习惯是 MySQL 先确认连通再起第一个节点看到成功日志后间隔 15 到 20 秒起第二个同样看日志再起第三个。日志里的成功标志是这一行docker logs -f nacos-cluster | grep started successfully # Nacos started successfully in cluster mode. use external storageuse external storage这个后缀很关键说明用的是外置数据库。如果显示的是stand alone mode说明MODEcluster没生效检查环境变量拼写。如果启动过程中反复刷failed to connect to server基本可以确定是cluster.conf地址写错了或者端口不通。启动完成后确认端口监听情况ss -lntp | grep -E 8848|9848|9849|7848四个端口都应该在缺任何一个都说明有问题最常见的是 9848、9849 缺失原因通常是容器网络模式不对或者端口冲突。5.2 集群状态验证先调健康接口返回UP说明节点自身正常curl http://10.0.0.11:8848/nacos/v1/console/health/readiness curl http://10.0.0.11:8848/nacos/v1/console/health/liveness再查节点列表确认三个节点都在且状态是UPcurl http://10.0.0.11:8848/nacos/v1/ns/operator/servers?healthyOnlyfalse返回的 JSON 里看servers数组三个ip:port都要出现state为UP。更直观的方式是登录控制台进集群管理→节点列表三个节点一行一个lastRefreshTime应该是持续更新的时间戳。如果某个节点时间戳停在几分钟前说明它掉线了。配置一致性也要验在节点 1 的控制台建一个配置然后分别去节点 2、节点 3 的控制台看能不能查到。三个都能看到才是真集群。这一步不做等到线上出问题才发现数据不同步就晚了。5.3 Nginx 四层代理接入客户端直接配三个地址是最稳的但有些团队习惯走一个统一入口。这时要注意Nacos 2.x 的 gRPC 必须用四层代理七层 HTTP 代理对 9848 无效。原因是 gRPC 是长连接加 HTTP/2 多路复用七层代理会把连接拆开重建客户端直接报错。Nginx 配置要放在stream块里不是http块nginx.conf顶层直接加stream { upstream nacos_http { server 10.0.0.11:8848; server 10.0.0.12:8848; server 10.0.0.13:8848; } upstream nacos_grpc_client { server 10.0.0.11:9848; server 10.0.0.12:9848; server 10.0.0.13:9848; } upstream nacos_grpc_server { server 10.0.0.11:9849; server 10.0.0.12:9849; server 10.0.0.13:9849; } server { listen 8848; proxy_pass nacos_http; proxy_timeout 30s; proxy_connect_timeout 3s; } server { listen 9848; proxy_pass nacos_grpc_client; proxy_timeout 3000s; } server { listen 9849; proxy_pass nacos_grpc_server; proxy_timeout 3000s; } }两个细节gRPC 的proxy_timeout要给大因为客户端是长连接超时设置太短会周期性断开重连日志里一段时间就刷一次重连HTTP 的proxy_timeout给 30 秒就够。另外这种代理方式下代理层本身成了新的单点要么做双机加 keepalived 之类的高可用要么干脆让客户端直连三个地址我倾向于后者少一层就少一个故障点。5.4 客户端接入配置Spring Cloud 项目的配置长这样spring: cloud: nacos: discovery: server-addr: 10.0.0.11:8848,10.0.0.12:8848,10.0.0.13:8848 namespace: prod group: DEFAULT_GROUP username: nacos password: 你的密码 config: server-addr: 10.0.0.11:8848,10.0.0.12:8848,10.0.0.13:8848 namespace: prod file-extension: yaml多个地址用逗号分隔客户端自己会轮询和故障转移比走单个代理地址稳定得多。namespace一定要设用不同 namespace 隔离开发、测试、生产三套环境比用 group 隔离更彻底而且控制台可以按 namespace 切换查看。账号密码这里吐槽一句明文写在配置文件里很不优雅至少要通过配置中心的加密功能或者环境变量注入别直接推到代码仓库。6. 踩坑排查实录环境和配置这两块问题翻来覆去就那么几个。我把实际遇到过的、以及帮别人看日志时高频出现的问题整理成速查表出问题时对着找比翻日志快得多。6.1 启动阶段报错速查表报错信息原因处理方式The specified key byte array is 0 bits...鉴权 token 未配置或长度不足用openssl rand -base64 32生成三节点统一No DataSource set数据源配置没生效检查SPRING_DATASOURCE_PLATFORMmysql和MYSQL_SERVICE_*变量Table nacos_config.config_info doesnt exist表结构未导入用当前版本自带的mysql-schema.sql导入Access denied for user nacosx.x.x.x账号未授权或密码错检查GRANT和密码里的特殊字符转义进程启动后立刻退出日志只有Killed容器内存不足被 OOMKilled调小JVM_XMX或加大--memoryAddress already in use: bind端口被占用ss -lntp查占用多半是旧容器没删干净Public Key Retrieval is not allowedMySQL 8 认证方式连接串加allowPublicKeyRetrievaltrue密码里带、#、这类字符时通过环境变量传入容易被截断导致认证失败。我一般要求数据库密码只用大小写字母加数字长度够就行避免这类无谓的排查成本。6.2 集群节点不互相发现这是最高频的问题排查路径固定按顺序走一遍基本能定位。先确认网络通不通。在第一个节点的机器上直接 telnet 另两个节点nc -zv 10.0.0.12 7848 nc -zv 10.0.0.12 9848 nc -zv 10.0.0.12 9849三个端口都通才有戏。如果 7848 不通大概率是防火墙没放行云主机还要额外检查安全组。如果 8848 通但 9848 不通那就是端口偏移问题——配置文件或者映射里只处理了 8848。网络通了还不行就看cluster.conf的内容和节点的nacos.inetutils.ip-address是否匹配。有个很隐蔽的情况机器上装了 Docker 之后多了一个docker0网卡172.17.0.1Nacos 自动选 IP 时可能选中这个地址注册上去的 IP 外部根本不可达。日志里搜address to server能看到它实际用了哪个 IP发现不对就在配置里显式指定。还有一种情况是时间不同步导致节点被判定为失联。三台机器的date输出应该基本一致差几秒以内。用chronyd或ntpd同步一下重启容器即可。6.3 配置丢失与数据不一致配置莫名消失通常有三类原因。第一类集群里混入了使用 Derby 的节点。这种节点的数据是完全独立的客户端打到它上面新建配置其他节点看不到。检查方式很简单看启动日志有没有use external storage。第二类中途扩节点时cluster.conf没同步。加了第四个节点但老的三台配置里还是三个地址新节点自己认得四个、别人只认三个状态就会很乱。扩节点的顺序应该是先在所有老节点上更新cluster.conf并重启最后再起新节点。第三类误删。这个没办法防只能靠备份。Nacos 的配置历史保留了变更记录his_config_info表误改可以回滚到上一个版本但误删整个配置项的话历史表里还能找到内容手动恢复即可。所以his_config_info这张表千万别清理。7. 生产加固与日常运维集群跑起来只是开始后面要考虑的是升级、备份、监控这几件长期的事。这几件事不做集群迟早会在某个不加班的晚上教做人。7.1 备份先保 MySQL再保日志整个 Nacos 集群里真正不可再生的是 MySQL 里的配置数据和服务列表服务列表是实例运行时注册的重启会自动重建配置数据丢了就是丢了。备份策略很简单每天定时全量导出mysqldump -h10.0.0.20 -unacos -p密码 \ --single-transaction --routines --triggers \ nacos_config /backup/nacos_config_$(date %Y%m%d).sql--single-transaction保证导出时不影响线上读写。保留最近 30 天的备份压缩后单个文件通常只有几 MB 到几十 MB成本可以忽略。恢复演练至少做一次别等到真出事才发现备份文件是空的——这种事故我见过不止一次。/data/nacos/logs目录也值得备份主要是naming-server.log和config-server.log出问题时这是唯一的一手证据。日志本身的轮转交给镜像内置的 logback 配置或者用--log-opt max-size100m --log-opt max-file3限制容器 stdout 的大小防止把磁盘写满。7.2 滚动升级的做法升级版本时绝对不要三个节点一起停。正确姿势是一次动一个停掉节点 1换新镜像起来等它在控制台显示UP、并且集群状态稳定几分钟再动节点 2。docker stop nacos-cluster docker rm nacos-cluster # 用新 tag 重新 run 同一套参数停一个节点期间另外两个节点构成多数派服务不中断。但要注意如果客户端的服务地址列表里只有被停的那个节点客户端会短暂连不上所以客户端侧一定要配全三个地址。跨大版本升级比如 2.2 到 2.3前先在一套独立环境里跑一遍重点验证鉴权配置和表结构变化。有的版本会新增表或者新增必填配置项直接在生产上升大概率起不来。7.3 监控要看哪几个指标最少要盯住这四个指标获取方式异常判断节点存活/nacos/v1/console/health/readiness连续 3 次非 UP 告警集群节点数/nacos/v1/ns/operator/servers少于预期节点数JVM 堆使用率GC 日志或 actuator老年代持续高于 80%配置项与实例总数控制台概览页突增突降都值得查/nacos/v1/ns/operator/metrics这个接口返回的指标更细包括服务数、实例数、健康实例数、长连接数。写个定时脚本每 30 秒拉一次落到监控系统里画个趋势图比出事之后再登录控制台翻要靠谱得多。尤其是长连接数2.x 下每个客户端实例维持一条 gRPC 连接这个数字突然翻倍往往意味着客户端在疯狂重连通常是服务端某个节点出了问题。我个人的体会是搭集群本身的复杂度其实不高真正花时间的是那些看起来配了但没生效的地方——环境变量名拼错一个字母、cluster.conf里多打一个空格、端口偏移忘了算、镜像默认的 2G 堆把内存吃光。这些问题的共同点是启动不报错、或者报错信息藏在一大堆日志里。我现在的做法是每搭完一套就写一个自检脚本拉健康接口、查节点列表、比对三节点数据、验证 9848 端口可达。下次换环境直接跑一遍五分钟就能确认状态比人眼盯日志快多了。
线上服务从十几个拆到四十多个之后最难受的不是联调而是改一个数据库地址要挨个翻配置文件、挨个重启。更致命的是注册中心和配置中心这类基础组件一旦挂掉业务方连启动都起不来只能干等。Nacos 干的就是这件事——服务注册发现、动态配置管理一套系统两个能力。这篇内容把我用 Docker 搭 Nacos 集群的完整过程摊开写从单机验证到三节点集群、从数据库初始化到 Nginx 四层接入、从启动参数到实际踩过的坑全部是可复现的命令和配置。适合已经会用 Docker、但被 Nacos 的 cluster.conf、端口偏移、节点发现折腾过的人。如果只是想本地跑个 Nacos 玩一玩看完第 3 节就够要做生产环境第 4 到第 7 节才是重点。1. 先定方案三节点集群到底该怎么摆动手敲命令之前有几个决策必须先定下来集群规模、网络模式、数据落盘方式。这几个决策定错了后面所有配置都是白费功夫排查起来还特别费劲。我在第一次搭的时候图省事用了默认 bridge 网络结果集群节点互相找不到日志里全是重连折腾了一整天才定位到是容器 IP 不通。1.1 单机模式藏着三个隐患大部分人是先用单机模式跑通然后一直没换。单机模式在开发环境没问题放到线上就有三个硬伤。第一个是单点故障。Nacos 挂了已经跑着的服务还能撑一阵但新实例无法注册、配置无法拉取滚动发布直接失败。第二个是数据不可迁移。单机模式默认用内嵌的 Derby 数据库数据写在容器内的本地文件里换台机器就得把整个数据目录搬走而且没法多节点共享。第三个是配置无兜底。单机没有节点间同步误改一个配置、误删一个服务没有别的节点可以做对比恢复。一个很常见的误操作以为把MODE改成cluster再加几台机器就是集群了但数据库还是 Derby。这种假集群每个节点的数据都是独立的客户端打到哪台就看到哪份数据比单机还危险。1.2 选 Docker 而不是裸机部署的取舍裸机部署 Nacos 要自己装 JDK、配环境变量、写 systemd 服务、管日志轮转一套下来半小时起步换版本还得重来一遍。Docker 方式把这堆事情压成了一个镜像JDK 版本随镜像走配置文件用挂载覆盖日志用 volume 落到宿主机升级就是换 tag 重启。资源也能限制--memory和--cpus直接卡住避免某个节点把宿主机内存吃干。代价也有。容器网络需要额外理解尤其是集群节点之间的互访地址日志在容器里排查时得多敲一条docker logs镜像内的默认 JVM 参数是 2G 堆小机器上不加限制会直接把容器撑爆。这些代价我觉得完全值得因为换来的是可重复——一台机器上的配置能原封不动复制到另外两台。1.3 端口与拓扑规划Nacos 2.x 的端口比 1.x 复杂很多人只映射了 8848结果客户端连得上控制台、注册却一直超时。关键是要理解端口的偏移规则主端口 N客户端 gRPC 端口是 N1000服务端 gRPC 端口是 N1001。端口用途说明8848HTTP / 控制台 / OpenAPI主端口可改9848客户端 gRPC固定为 88481000客户端长连接走这里9849服务端 gRPC固定为 88481001集群节点间同步走这里7848集群内部通信旧版 Raft 端口2.x 仍保留3306外部 MySQL三节点共用一份数据如果要把主端口改成 8858那么 9848 变 9858、9849 变 9859、7848 变 7858三个都得跟着改客户端配置也要同步。所以我一般不建议改端口省得后面自己都记不清。拓扑上我推荐三节点因为 Nacos 集群是多数派可用的模型两个节点挂一个就不可用三个节点挂一个还能正常服务。机器规格上4 核 8G 跑一个节点绰绰有余5000 个服务实例以下的规模单节点堆内存给 1G 就够。下面统一用10.0.0.11、10.0.0.12、10.0.0.13三台机器举例MySQL 放在10.0.0.20。2. 动手前的准备镜像、数据库、网络准备工作是最容易被跳过、也最容易出问题的环节。我见过太多次启动失败最后发现是表结构没导、或者账号权限没给全。这一节把三件事做完主机调优、MySQL 初始化、镜像和网络模式选定。2.1 主机基础调优与目录规划三台机器上都要做同样的操作。先调文件句柄数Nacos 2.x 每个客户端维持一条 gRPC 长连接几千个实例就是几千个连接默认的 1024 根本不够用。在/etc/security/limits.conf里加上* soft nofile 65535 * hard nofile 65535改完重新登录生效用ulimit -n确认。时间同步也必须做集群节点间时间差超过一定范围Raft 的心跳和选举会出问题日志里会看到莫名其妙的 leader 切换。容器内时区默认是 UTC如果不处理日志时间和业务时间对不上排查问题时特别痛苦启动时加上-e TZAsia/Shanghai就能解决。目录规划上我习惯在宿主机建/data/nacos/{logs,data}两个目录logs 挂日志、data 挂持久化数据权限给 1000镜像内 nacos 用户的 uid。这么做的好处是容器删了数据还在换镜像重启时直接把目录挂回去配置历史一条不少。2.2 外置 MySQL 的初始化集群模式必须用外置数据库这条没有商量余地。先在 MySQL 上建库建账号CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER nacos% IDENTIFIED BY 换成你的强密码; GRANT ALL PRIVILEGES ON nacos_config.* TO nacos%; FLUSH PRIVILEGES;字符集必须是utf8mb4用utf8存中文配置项会有截断风险。然后导入表结构SQL 文件在镜像里的/home/nacos/conf/mysql-schema.sql可以先起一个临时容器拷出来或者直接从发行包拿。导入后确认关键表都在mysql -h10.0.0.20 -unacos -p nacos_config -e show tables;正常应该看到config_info、his_config_info、config_tags_relation、tenant_info、users、roles、permissions等表。这里有个细节2.x 版本多了灰度相关表如果只导了 1.x 的旧 SQL启动时不会报错但用灰度发布功能时才暴露问题所以务必用当前版本自带的脚本。2.3 镜像版本与网络模式选择镜像我一般锁在nacos/nacos-server:v2.3.2这种明确的小版本上不用latest。原因很实际latest可能在某次拉取后变成大版本而 2.2.0 之后对鉴权的要求变严了没配 token 直接启动失败半夜拉个镜像重启就出事。锁版本之后升级是一次有计划的动作不是意外。docker pull nacos/nacos-server:v2.3.2 docker images | grep nacos网络模式是个关键选择。跨宿主机的集群我强烈建议用--network host理由有三第一端口不用映射9848、9849、7848 全部自然暴露不会漏第二容器内看到的 IP 就是宿主机真实 IPcluster.conf里写什么就是什么不用纠结内外网映射第三gRPC 长连接经过 NAT 映射容易出现连接被回收的问题host 模式绕开了这层。如果环境不允许用 host 模式退而求其次是用自定义 bridge 加固定 IP但必须把PREFER_HOST_MODE设成hostname并且保证容器名可解析配置复杂度直接翻倍。我个人的经验是能用 host 就用 host别给自己找麻烦。3. 三种部署模式递进实操我推荐的路径是先单机验证镜像能不能跑起来再单机连 MySQL 验证配置正确最后上三节点。一步到位直接搭集群出问题时根本分不清是镜像问题、配置问题还是数据库问题。3.1 模式一Derby 单机只用来验镜像这一步纯粹是验证镜像完整性别拿它当开发环境用。docker run -d --name nacos-probe \ -e MODEstandalone \ -e TZAsia/Shanghai \ -p 8848:8848 -p 9848:9848 \ nacos/nacos-server:v2.3.2 docker logs -f nacos-probe看到Nacos started successfully in stand alone mode就说明镜像没问题。浏览器打开http://宿主机IP:8848/nacos2.2.0 之后的版本首次登录会强制要求设置新密码默认账号nacos初始密码也是nacos。这一步验证完就可以把容器删掉docker rm -f nacos-probe。这里有个新手常犯的错只映射了 8848 就以为完事。本地用 curl 调 OpenAPI 确实能通但一旦换成 2.x 的客户端 SDK注册就卡住因为客户端走的是 9848 的 gRPC。记住一句话8848 给了人看9848 给了客户端用。3.2 模式二单机连 MySQL把配置跑通这一步的目的是把数据库连接、鉴权参数、挂载路径全部验一遍成本最低。docker run -d --name nacos-single \ --network host \ --restart always \ -e MODEstandalone \ -e TZAsia/Shanghai \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST10.0.0.20 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORD你的密码 \ -e MYSQL_SERVICE_DB_PARAMcharacterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue \ -e NACOS_AUTH_ENABLEtrue \ -e NACOS_AUTH_TOKEN你的base64密钥 \ -e NACOS_AUTH_IDENTITY_KEYserverIdentity \ -e NACOS_AUTH_IDENTITY_VALUEsecurity \ -e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -v /data/nacos/logs:/home/nacos/logs \ nacos/nacos-server:v2.3.2NACOS_AUTH_TOKEN不是随便写一串字符就行。它的要求是base64 编码后解密长度不少于 32 字节否则启动直接抛The specified key byte array is 0 bits which is not secure enough。生成方式openssl rand -base64 32把输出原样贴进环境变量。这个值三个节点必须完全一致否则节点间鉴权会失败日志里表现为 403。NACOS_AUTH_IDENTITY_KEY和VALUE同理全网统一。启动后用docker logs nacos-single确认没有No DataSource set这类报错再登录控制台新建一个配置项然后去 MySQL 里select * from config_info;看有没有落库。这一步通了说明数据链路是完整的。3.3 模式三三节点集群正式形态三台机器上分别起容器唯一的区别是NACOS_SERVERS里各节点地址相同、nacos.inetutils.ip-address指向本机。先准备cluster.conf三台内容完全一样cat /data/nacos/cluster.conf EOF 10.0.0.11:8848 10.0.0.12:8848 10.0.0.13:8848 EOF然后在每台机器上执行把本机IP换成对应地址docker run -d --name nacos-cluster \ --network host \ --restart always \ -e MODEcluster \ -e TZAsia/Shanghai \ -e PREFER_HOST_MODEip \ -e NACOS_SERVERS10.0.0.11:8848 10.0.0.12:8848 10.0.0.13:8848 \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST10.0.0.20 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORD你的密码 \ -e MYSQL_SERVICE_DB_PARAMcharacterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue \ -e NACOS_AUTH_ENABLEtrue \ -e NACOS_AUTH_TOKEN你的base64密钥 \ -e NACOS_AUTH_IDENTITY_KEYserverIdentity \ -e NACOS_AUTH_IDENTITY_VALUEsecurity \ -e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -v /data/nacos/logs:/home/nacos/logs \ -v /data/nacos/cluster.conf:/home/nacos/conf/cluster.conf \ nacos/nacos-server:v2.3.2挂载cluster.conf和环境变量NACOS_SERVERS是两条并行的路径同时用不冲突但内容必须一致。我见过有人只改了一台机器的cluster.conf另外两台还是旧地址结果集群能起来但总有一个节点显示 DOWN。三台机器上的启动命令可以写成一个脚本用参数传 IP避免手抖改错。启动顺序上我是串行来一台起来看到日志Nacos started successfully in cluster mode再去起下一台中间隔十几秒。虽然同时起也能成但初期节点间互相注册会打一堆重连日志看着心慌串行起来干净。4. 配置文件逐项拆解环境变量方式很方便但一旦参数多了就看不清全貌而且有些配置项没有对应的环境变量。我习惯在集群稳定后把配置抽成挂载的application.properties一眼能看到所有关键项。4.1 application.properties 里必须改的几项把文件放到/data/nacos/application.properties挂载到容器内的/home/nacos/conf/application.properties。核心内容server.port8848 server.servlet.contextPath/nacos server.error.include-messageALWAYS spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://10.0.0.20:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue db.user.0nacos db.password.0你的密码 nacos.core.auth.enabledtrue nacos.core.auth.caching.enabledtrue nacos.core.auth.plugin.nacos.token.secret.key你的base64密钥 nacos.core.auth.server.identity.keyserverIdentity nacos.core.auth.server.identity.valuesecurity nacos.inetutils.ip-address10.0.0.11db.num值得说一句。设成 1 就是所有配置写同一个库设成 3 配db.url.0/1/2就是分库方案Nacos 会按配置的 dataId 做哈希分散到不同库。分库听起来能扛更大压力但运维复杂度翻倍备份恢复也麻烦十万级配置项以内单库加索引完全够用别过早给自己加戏。nacos.inetutils.ip-address在多网卡的机器上很重要。机器上同时有内网网卡和业务网卡时Nacos 可能选错 IP导致cluster.conf里的地址和实际监听的地址对不上节点永远互相看不见。指定死了最省心。4.2 cluster.conf 的写法与三个禁忌这个文件的格式非常简单一行一个ip:port但它是最容易出错的地方。三个禁忌第一不要写127.0.0.1或localhost。每个节点都往自己身上连集群退化成单机。第二不要写容器内的网卡 IPbridge 网络下通常是 172.17.x.x宿主机之间根本不可达。第三端口必须写容器内服务的真实端口不是-p映射出去的那个。用 host 网络时两者相同用 bridge 时就容易搞混。另外这个文件末尾最好别留空行某些版本解析时对空行处理不一致会报格式错误。文件改完之后不需要重启整个容器但要生效最稳妥的办法还是重启或者调/nacos/v1/ns/operator/servers接口触发重新读取。4.3 JVM 参数与内存的账要算清镜像默认的 JVM 参数是-Xms2g -Xmx2g -Xmn1g在 4G 内存的机器上直接跑容器会被撑爆然后 OOMKilled日志里只有一行Killed什么都不告诉你。参数要通过环境变量覆盖环境变量含义建议值4C8G 机器JVM_XMS初始堆1gJVM_XMX最大堆1gJVM_XMN新生代512mJVM_MS初始 Metaspace128mJVM_MMS最大 Metaspace320m算法很简单Xmn取Xmx的 1/3 到 1/2避免大对象直接进老年代引发频繁 Full GC。堆外还要算上 Metaspace、直接内存Netty 的 DirectByteBuffer、线程栈。所以如果给容器加--memory2g限制堆最多给 1.2g剩下 800m 留给堆外和系统否则一定 OOMKilled。想更精细一点可以把 GC 日志打开排查问题时不用猜-e JVM_XMS1g -e JVM_XMX1g -e JVM_XMN512m \ -e JAVA_OPT-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/home/nacos/logs/gc.log5. 启动验证与接入层三个容器都起来不代表集群就正常了。必须逐项验证节点状态、数据一致性、客户端可用性最后才是接入层的代理配置。5.1 启动顺序与日志观察我的习惯是 MySQL 先确认连通再起第一个节点看到成功日志后间隔 15 到 20 秒起第二个同样看日志再起第三个。日志里的成功标志是这一行docker logs -f nacos-cluster | grep started successfully # Nacos started successfully in cluster mode. use external storageuse external storage这个后缀很关键说明用的是外置数据库。如果显示的是stand alone mode说明MODEcluster没生效检查环境变量拼写。如果启动过程中反复刷failed to connect to server基本可以确定是cluster.conf地址写错了或者端口不通。启动完成后确认端口监听情况ss -lntp | grep -E 8848|9848|9849|7848四个端口都应该在缺任何一个都说明有问题最常见的是 9848、9849 缺失原因通常是容器网络模式不对或者端口冲突。5.2 集群状态验证先调健康接口返回UP说明节点自身正常curl http://10.0.0.11:8848/nacos/v1/console/health/readiness curl http://10.0.0.11:8848/nacos/v1/console/health/liveness再查节点列表确认三个节点都在且状态是UPcurl http://10.0.0.11:8848/nacos/v1/ns/operator/servers?healthyOnlyfalse返回的 JSON 里看servers数组三个ip:port都要出现state为UP。更直观的方式是登录控制台进集群管理→节点列表三个节点一行一个lastRefreshTime应该是持续更新的时间戳。如果某个节点时间戳停在几分钟前说明它掉线了。配置一致性也要验在节点 1 的控制台建一个配置然后分别去节点 2、节点 3 的控制台看能不能查到。三个都能看到才是真集群。这一步不做等到线上出问题才发现数据不同步就晚了。5.3 Nginx 四层代理接入客户端直接配三个地址是最稳的但有些团队习惯走一个统一入口。这时要注意Nacos 2.x 的 gRPC 必须用四层代理七层 HTTP 代理对 9848 无效。原因是 gRPC 是长连接加 HTTP/2 多路复用七层代理会把连接拆开重建客户端直接报错。Nginx 配置要放在stream块里不是http块nginx.conf顶层直接加stream { upstream nacos_http { server 10.0.0.11:8848; server 10.0.0.12:8848; server 10.0.0.13:8848; } upstream nacos_grpc_client { server 10.0.0.11:9848; server 10.0.0.12:9848; server 10.0.0.13:9848; } upstream nacos_grpc_server { server 10.0.0.11:9849; server 10.0.0.12:9849; server 10.0.0.13:9849; } server { listen 8848; proxy_pass nacos_http; proxy_timeout 30s; proxy_connect_timeout 3s; } server { listen 9848; proxy_pass nacos_grpc_client; proxy_timeout 3000s; } server { listen 9849; proxy_pass nacos_grpc_server; proxy_timeout 3000s; } }两个细节gRPC 的proxy_timeout要给大因为客户端是长连接超时设置太短会周期性断开重连日志里一段时间就刷一次重连HTTP 的proxy_timeout给 30 秒就够。另外这种代理方式下代理层本身成了新的单点要么做双机加 keepalived 之类的高可用要么干脆让客户端直连三个地址我倾向于后者少一层就少一个故障点。5.4 客户端接入配置Spring Cloud 项目的配置长这样spring: cloud: nacos: discovery: server-addr: 10.0.0.11:8848,10.0.0.12:8848,10.0.0.13:8848 namespace: prod group: DEFAULT_GROUP username: nacos password: 你的密码 config: server-addr: 10.0.0.11:8848,10.0.0.12:8848,10.0.0.13:8848 namespace: prod file-extension: yaml多个地址用逗号分隔客户端自己会轮询和故障转移比走单个代理地址稳定得多。namespace一定要设用不同 namespace 隔离开发、测试、生产三套环境比用 group 隔离更彻底而且控制台可以按 namespace 切换查看。账号密码这里吐槽一句明文写在配置文件里很不优雅至少要通过配置中心的加密功能或者环境变量注入别直接推到代码仓库。6. 踩坑排查实录环境和配置这两块问题翻来覆去就那么几个。我把实际遇到过的、以及帮别人看日志时高频出现的问题整理成速查表出问题时对着找比翻日志快得多。6.1 启动阶段报错速查表报错信息原因处理方式The specified key byte array is 0 bits...鉴权 token 未配置或长度不足用openssl rand -base64 32生成三节点统一No DataSource set数据源配置没生效检查SPRING_DATASOURCE_PLATFORMmysql和MYSQL_SERVICE_*变量Table nacos_config.config_info doesnt exist表结构未导入用当前版本自带的mysql-schema.sql导入Access denied for user nacosx.x.x.x账号未授权或密码错检查GRANT和密码里的特殊字符转义进程启动后立刻退出日志只有Killed容器内存不足被 OOMKilled调小JVM_XMX或加大--memoryAddress already in use: bind端口被占用ss -lntp查占用多半是旧容器没删干净Public Key Retrieval is not allowedMySQL 8 认证方式连接串加allowPublicKeyRetrievaltrue密码里带、#、这类字符时通过环境变量传入容易被截断导致认证失败。我一般要求数据库密码只用大小写字母加数字长度够就行避免这类无谓的排查成本。6.2 集群节点不互相发现这是最高频的问题排查路径固定按顺序走一遍基本能定位。先确认网络通不通。在第一个节点的机器上直接 telnet 另两个节点nc -zv 10.0.0.12 7848 nc -zv 10.0.0.12 9848 nc -zv 10.0.0.12 9849三个端口都通才有戏。如果 7848 不通大概率是防火墙没放行云主机还要额外检查安全组。如果 8848 通但 9848 不通那就是端口偏移问题——配置文件或者映射里只处理了 8848。网络通了还不行就看cluster.conf的内容和节点的nacos.inetutils.ip-address是否匹配。有个很隐蔽的情况机器上装了 Docker 之后多了一个docker0网卡172.17.0.1Nacos 自动选 IP 时可能选中这个地址注册上去的 IP 外部根本不可达。日志里搜address to server能看到它实际用了哪个 IP发现不对就在配置里显式指定。还有一种情况是时间不同步导致节点被判定为失联。三台机器的date输出应该基本一致差几秒以内。用chronyd或ntpd同步一下重启容器即可。6.3 配置丢失与数据不一致配置莫名消失通常有三类原因。第一类集群里混入了使用 Derby 的节点。这种节点的数据是完全独立的客户端打到它上面新建配置其他节点看不到。检查方式很简单看启动日志有没有use external storage。第二类中途扩节点时cluster.conf没同步。加了第四个节点但老的三台配置里还是三个地址新节点自己认得四个、别人只认三个状态就会很乱。扩节点的顺序应该是先在所有老节点上更新cluster.conf并重启最后再起新节点。第三类误删。这个没办法防只能靠备份。Nacos 的配置历史保留了变更记录his_config_info表误改可以回滚到上一个版本但误删整个配置项的话历史表里还能找到内容手动恢复即可。所以his_config_info这张表千万别清理。7. 生产加固与日常运维集群跑起来只是开始后面要考虑的是升级、备份、监控这几件长期的事。这几件事不做集群迟早会在某个不加班的晚上教做人。7.1 备份先保 MySQL再保日志整个 Nacos 集群里真正不可再生的是 MySQL 里的配置数据和服务列表服务列表是实例运行时注册的重启会自动重建配置数据丢了就是丢了。备份策略很简单每天定时全量导出mysqldump -h10.0.0.20 -unacos -p密码 \ --single-transaction --routines --triggers \ nacos_config /backup/nacos_config_$(date %Y%m%d).sql--single-transaction保证导出时不影响线上读写。保留最近 30 天的备份压缩后单个文件通常只有几 MB 到几十 MB成本可以忽略。恢复演练至少做一次别等到真出事才发现备份文件是空的——这种事故我见过不止一次。/data/nacos/logs目录也值得备份主要是naming-server.log和config-server.log出问题时这是唯一的一手证据。日志本身的轮转交给镜像内置的 logback 配置或者用--log-opt max-size100m --log-opt max-file3限制容器 stdout 的大小防止把磁盘写满。7.2 滚动升级的做法升级版本时绝对不要三个节点一起停。正确姿势是一次动一个停掉节点 1换新镜像起来等它在控制台显示UP、并且集群状态稳定几分钟再动节点 2。docker stop nacos-cluster docker rm nacos-cluster # 用新 tag 重新 run 同一套参数停一个节点期间另外两个节点构成多数派服务不中断。但要注意如果客户端的服务地址列表里只有被停的那个节点客户端会短暂连不上所以客户端侧一定要配全三个地址。跨大版本升级比如 2.2 到 2.3前先在一套独立环境里跑一遍重点验证鉴权配置和表结构变化。有的版本会新增表或者新增必填配置项直接在生产上升大概率起不来。7.3 监控要看哪几个指标最少要盯住这四个指标获取方式异常判断节点存活/nacos/v1/console/health/readiness连续 3 次非 UP 告警集群节点数/nacos/v1/ns/operator/servers少于预期节点数JVM 堆使用率GC 日志或 actuator老年代持续高于 80%配置项与实例总数控制台概览页突增突降都值得查/nacos/v1/ns/operator/metrics这个接口返回的指标更细包括服务数、实例数、健康实例数、长连接数。写个定时脚本每 30 秒拉一次落到监控系统里画个趋势图比出事之后再登录控制台翻要靠谱得多。尤其是长连接数2.x 下每个客户端实例维持一条 gRPC 连接这个数字突然翻倍往往意味着客户端在疯狂重连通常是服务端某个节点出了问题。我个人的体会是搭集群本身的复杂度其实不高真正花时间的是那些看起来配了但没生效的地方——环境变量名拼错一个字母、cluster.conf里多打一个空格、端口偏移忘了算、镜像默认的 2G 堆把内存吃光。这些问题的共同点是启动不报错、或者报错信息藏在一大堆日志里。我现在的做法是每搭完一套就写一个自检脚本拉健康接口、查节点列表、比对三节点数据、验证 9848 端口可达。下次换环境直接跑一遍五分钟就能确认状态比人眼盯日志快多了。
