1. 为什么单机版Nacos依然是测试环境的刚需做过微服务架构的朋友都清楚服务注册与配置管理是整个体系的神经中枢。Nacos作为这个中枢的国产开源实现这几年在中小团队里的普及速度非常快。但很多人第一次在云服务器上装Nacos的时候会陷入一个误区觉得测试环境嘛随便搞搞就行结果配置中心的数据丢了、服务列表莫名其妙空了、启动报错排查半天。我自己前前后后在不同规格的云主机上部署过不下十次Nacos单机版踩过的坑足够写一本小册子。这篇文章要聊的就是怎么在一台云服务器上从零把Nacos单机版跑起来并且让它稳定地服务于你的测试环境。核心关键词就三个云服务器、测试环境、Nacos单机版。适合谁看如果你正在搭建微服务的测试环境或者你是个后端开发需要自己维护一套注册中心再或者你是个运维新手第一次接触Nacos这篇内容都能直接抄作业。先说清楚一个前提单机版Nacos和集群版Nacos在部署复杂度上差了不止一个量级。单机版用的是内嵌的Derby数据库数据存在本地文件里重启不丢但也没法横向扩展。测试环境用单机版完全够用因为测试环境的核心诉求是功能验证不是高可用。生产环境才需要考虑集群加外部数据库。这个定位想清楚了后面的操作才不会跑偏。我见过太多人把测试环境的Nacos当生产用配了一堆服务结果某天云主机磁盘满了Derby数据库文件损坏所有配置全丢。所以这篇文章除了安装步骤还会重点讲清楚单机版的边界在哪里哪些操作是安全的哪些操作是在给自己埋雷。2. 部署前的环境规划与依赖梳理2.1 云服务器规格怎么选才不浪费也不憋屈Nacos本身是个Java应用单机版对资源的要求其实不高但不高不等于随便。我实测下来的经验是最低2核4G这是能跑起来的底线。1核2G的机器我也试过启动能起来但稍微多注册几个服务控制台响应就明显变慢有时候还会因为内存不足被系统OOM Killer干掉。具体来说Nacos单机版默认的JVM参数是-Xms512m -Xmx512m加上操作系统本身的开销2G内存的机器跑起来会非常紧张。4G内存的话你可以把JVM堆适当调大一点比如-Xms1g -Xmx1g留2G给系统和其他进程这样比较从容。磁盘方面单机版Nacos的Derby数据库文件增长很慢测试环境一般10G系统盘就够用了。但要注意日志文件的增长Nacos的日志默认会保留30天如果测试环境服务注册频繁日志量也不小。建议单独挂一块数据盘放日志或者定期清理。网络方面云服务器的安全组规则一定要提前配好。Nacos需要开放的端口有三个端口用途是否必须对外开放8848主服务端口控制台和API都走这个是9848gRPC端口2.x版本新增是7848集群通信端口单机版可不开否这里有个大坑很多人装完Nacos发现控制台能打开但服务注册不上折腾半天才发现是9848端口没开。Nacos 2.0之后新增了gRPC通信客户端和服务端之间除了8848的HTTP通信还需要9848的gRPC通信。这个端口在安全组里必须放行否则服务注册会失败。2.2 JDK版本的选择与安装细节Nacos 2.x版本要求JDK 8以上但我不建议用JDK 8原因有两个一是JDK 8在高版本Nacos上偶尔会有兼容性问题二是JDK 11和JDK 17的GC性能更好对测试环境这种资源有限的场景更友好。我目前稳定用的是JDK 17配合Nacos 2.3.x版本跑了半年多没出过问题。安装JDK的方式有很多种在云服务器上我推荐用包管理器安装省事且不容易出错。以常见的Linux发行版为例# 更新包索引 sudo apt update # 安装OpenJDK 17 sudo apt install -y openjdk-17-jdk # 验证安装 java -version安装完成后需要确认JAVA_HOME环境变量是否正确设置。有些包管理器安装的JDK不会自动设置JAVA_HOME而Nacos的启动脚本依赖这个变量。你可以这样检查echo $JAVA_HOME如果输出为空需要手动配置。编辑/etc/profile文件在末尾添加export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH然后执行source /etc/profile让配置生效。注意JAVA_HOME的具体路径可能因发行版和版本不同而有差异用update-alternatives --list java可以查到实际路径。注意不要用yum install java或apt install default-jdk这种模糊的安装方式装出来的版本不可控后面排查问题时会很痛苦。明确指定版本号这是运维的基本素养。2.3 下载Nacos安装包的正确姿势Nacos的安装包从官方渠道获取我一般选择稳定版而不是最新版。测试环境追求的是稳定可复现不是尝鲜。目前我推荐用2.3.2这个版本经过大量实践验证bug比较少。下载和解压的命令如下# 创建安装目录 mkdir -p /opt/nacos cd /opt/nacos # 下载Nacos安装包以2.3.2版本为例 wget https://github.com/alibaba/nacos/releases/download/2.3.2/nacos-server-2.3.2.tar.gz # 解压 tar -zxvf nacos-server-2.3.2.tar.gz # 进入解压后的目录 cd nacos解压后的目录结构大概是这样的nacos/ ├── bin/ # 启动脚本目录 ├── conf/ # 配置文件目录 ├── data/ # 数据文件目录Derby数据库文件在这里 ├── logs/ # 日志目录 └── target/ # 应用jar包目录这里有个细节要注意data目录在刚解压时可能不存在第一次启动后才会自动创建。如果你需要迁移数据直接拷贝这个目录就行。实操心得下载速度慢的话可以先用浏览器下载到本地再用scp上传到服务器。不要用那些来路不明的镜像站安装包被篡改的风险是真实存在的。3. 核心配置调整与启动参数优化3.1 application.properties的关键改动Nacos的配置文件在conf/application.properties这个文件决定了Nacos的行为。默认配置能跑起来但有几个地方必须改否则测试环境用起来会很难受。第一个要改的是数据库配置。单机版默认用Derby不需要额外配置。但如果你希望数据更可靠一点可以换成MySQL。不过测试环境我建议就用Derby简单省事。Derby的数据文件在data/derby-data目录下备份的时候直接打包这个目录就行。第二个要改的是服务端口。默认8848一般不用改。但如果你的云服务器上已经有其他服务占用了这个端口就需要调整。改端口的同时记得同步修改安全组规则。第三个要改的是JVM参数。这个不在application.properties里而在bin/startup.sh脚本中。找到这一行JAVA_OPT${JAVA_OPT} -Xms512m -Xmx512m -Xmn256m根据你的服务器内存调整。4G内存的机器我建议改成JAVA_OPT${JAVA_OPT} -Xms1g -Xmx1g -Xmn512m-Xmn是新生代大小设置为堆内存的一半比较合理。这样GC频率会低一些控制台操作更流畅。还有一个容易被忽略的配置是鉴权开关。Nacos默认关闭鉴权任何人都能访问控制台和API。测试环境如果只在内网使用问题不大。但如果你的云服务器有公网IP强烈建议开启鉴权nacos.core.auth.enabledtrue nacos.core.auth.server.identity.keyyour_custom_key nacos.core.auth.server.identity.valueyour_custom_value开启鉴权后访问控制台需要登录默认用户名和密码都是nacos。第一次登录后记得改密码。3.2 启动脚本的定制与系统服务化直接用sh startup.sh -m standalone启动Nacos是可以的但这种方式有个问题终端关闭后进程就没了。测试环境虽然不要求7x24小时运行但每次重启服务器都要手动启动一遍也很烦。我的做法是把Nacos注册成系统服务用systemd管理。创建一个服务文件/etc/systemd/system/nacos.service[Unit] DescriptionNacos Server Afternetwork.target [Service] Typeforking ExecStart/opt/nacos/nacos/bin/startup.sh -m standalone ExecStop/opt/nacos/nacos/bin/shutdown.sh Restarton-failure RestartSec10 [Install] WantedBymulti-user.target然后执行# 重新加载systemd配置 sudo systemctl daemon-reload # 启动Nacos sudo systemctl start nacos # 设置开机自启 sudo systemctl enable nacos # 查看状态 sudo systemctl status nacos这样管理起来就方便多了systemctl start/stop/restart nacos三条命令搞定所有操作。注意startup.sh脚本在启动时会fork一个子进程所以systemd的Type要设置为forking否则systemd会认为服务启动失败。这个坑我踩过当时排查了半天才发现是服务类型配错了。3.3 启动日志的观察与启动成功的判断标准Nacos启动过程大概需要10到30秒取决于服务器性能。启动是否成功不能只看进程在不在要看日志。启动日志在logs/start.out文件里。启动成功的标志是看到这一行Nacos started successfully in stand alone mode. use embedded storage如果看到这行说明Nacos已经正常启动了。如果没看到就要检查logs/nacos.log里的错误信息。常见的启动失败原因有错误现象可能原因解决方法端口被占用8848端口已被其他进程使用用lsof -i:8848查找并杀掉占用进程或修改Nacos端口内存不足JVM无法分配足够内存调小-Xms和-Xmx参数JAVA_HOME未设置启动脚本找不到Java检查JAVA_HOME环境变量数据库文件损坏Derby数据库异常删除data/derby-data目录重新初始化启动成功后在浏览器访问http://你的服务器IP:8848/nacos应该能看到Nacos的登录页面。默认用户名和密码都是nacos。4. 测试环境下的实战操作与验证4.1 服务注册与发现的完整验证流程Nacos装好了怎么验证它真的能用最直接的方式是注册一个服务上去。我一般用一个简单的Spring Boot应用来测试但如果你手头没有现成的应用用curl命令也能完成验证。Nacos提供了OpenAPI可以直接通过HTTP请求注册服务。下面这个命令注册一个名为test-service的服务实例curl -X POST http://127.0.0.1:8848/nacos/v1/ns/instance \ -d serviceNametest-service \ -d ip192.168.1.100 \ -d port8080 \ -d namespaceIdpublic执行成功后在Nacos控制台的服务管理-服务列表中应该能看到test-service这个服务并且有一个实例。查询服务列表的APIcurl http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceNametest-service返回的JSON里会包含实例的详细信息。这个验证流程走一遍说明Nacos的服务注册功能是正常的。配置管理功能的验证也类似。发布一个配置curl -X POST http://127.0.0.1:8848/nacos/v1/cs/configs \ -d dataIdtest-config \ -d groupDEFAULT_GROUP \ -d contenthellonacos然后在控制台的配置管理中就能看到这条配置。获取配置的APIcurl http://127.0.0.1:8848/nacos/v1/cs/configs?dataIdtest-configgroupDEFAULT_GROUP返回的内容应该是hellonacos。4.2 命名空间与分组的最佳实践测试环境最容易犯的错误就是所有服务都堆在public命名空间里所有配置都用DEFAULT_GROUP。项目少的时候没问题项目一多就乱成一锅粥。我的建议是按项目或按环境划分命名空间。比如你有三个微服务项目就建三个命名空间project-a、project-b、project-c。每个项目的服务注册和配置管理都在自己的命名空间里互不干扰。创建命名空间的APIcurl -X POST http://127.0.0.1:8848/nacos/v1/console/namespaces \ -d customNamespaceIdproject-a \ -d namespaceNameproject-a \ -d namespaceDescProject A test environment然后在应用配置中指定命名空间spring: cloud: nacos: discovery: namespace: project-a config: namespace: project-a分组Group的使用也有讲究。我一般用Group来区分同一项目下的不同模块比如user-service、order-service。这样在控制台里看起来层次分明。实操心得命名空间一旦创建ID就不要改了。因为应用配置里写的是命名空间的ID改了ID所有应用都要跟着改。创建的时候想清楚命名规则后面省很多事。4.3 数据备份与恢复的实操方案单机版Nacos最大的风险就是数据丢失。Derby数据库虽然比内存存储可靠但也不是万无一失。磁盘故障、误删除、系统重装都可能导致数据丢失。备份策略很简单定期打包data目录。写个定时任务每天凌晨打包一次#!/bin/bash BACKUP_DIR/opt/backup/nacos DATE$(date %Y%m%d) mkdir -p $BACKUP_DIR tar -czf $BACKUP_DIR/nacos-data-$DATE.tar.gz -C /opt/nacos/nacos data/ # 保留最近7天的备份 find $BACKUP_DIR -name nacos-data-*.tar.gz -mtime 7 -delete恢复的时候先停止Nacos解压备份文件覆盖data目录再启动Nacos即可。这个备份方案虽然简单但非常有效。我经历过一次云主机系统盘故障就是因为有备份十分钟就恢复了所有配置数据。5. 常见故障排查与性能调优5.1 控制台能打开但服务注册失败的排查思路这是最高频的问题。控制台能打开说明8848端口的HTTP服务是正常的但服务注册走的是gRPC通道需要9848端口。排查步骤第一步检查9848端口是否在监听netstat -tlnp | grep 9848如果没有输出说明Nacos的gRPC服务没起来。这种情况通常是Nacos版本和客户端版本不匹配导致的。Nacos 2.x的服务端需要2.x的客户端1.x的客户端连不上2.x的服务端。第二步检查安全组规则。云服务器的安全组是独立于操作系统防火墙的即使系统防火墙放行了安全组没放行照样不通。登录云服务商的控制台确认8848和9848端口都对测试环境的IP段开放。第三步检查客户端的配置。客户端的server-addr配置是否正确有没有多写空格或者用了错误的协议前缀。正确的格式是ip:8848不要加http://。5.2 内存溢出与GC频繁的调优记录测试环境的服务器内存有限Nacos跑久了可能会出现GC频繁甚至OOM。我遇到过一种情况Nacos运行一周后控制台响应变得极慢查看日志发现Full GC每隔几分钟就触发一次。排查过程先用jstat -gc pid 1000观察GC情况发现老年代使用率一直在90%以上Full GC后也降不下来。这说明有内存泄漏或者堆内存设置得太小。解决办法分两步短期先把堆内存调大从512M调到1G长期来看需要检查是不是有大量服务实例注册后没有正常下线导致Nacos内部维护了太多无效的实例信息。Nacos有个配置可以自动清理不健康的实例nacos.naming.clean.expired.instancetrue nacos.naming.expireInstancetrue nacos.naming.clean.period300000nacos.naming.clean.period是清理周期单位毫秒默认300000也就是5分钟。测试环境可以调小一点比如60000一分钟清理一次。5.3 日志文件暴涨的清理策略Nacos的日志默认保留30天测试环境如果服务注册频繁日志文件一天就能涨到几百兆。磁盘满了之后Nacos会直接挂掉。我一般会做两件事一是调整日志级别把不必要的DEBUG日志关掉二是配置日志轮转策略。调整日志级别在conf/nacos-logback.xml文件中找到root levelINFO这一行确保级别是INFO而不是DEBUG。测试环境排查问题时可以临时开DEBUG但排查完一定要改回来。日志轮转的配置也在nacos-logback.xml里默认是按天轮转保留30天。可以改成保留7天maxHistory7/maxHistory另外logs/start.out这个文件不会自动轮转会一直增长。可以在systemd服务里配置日志重定向或者写个定时任务定期清空。注意清理日志之前一定要确认Nacos运行正常不要一边运行一边删日志文件可能会导致文件句柄异常。正确的做法是先停止Nacos清理日志再启动。6. 单机版Nacos的边界与后续演进方向单机版Nacos在测试环境用起来很舒服但有几个边界必须清楚。第一它不支持高可用服务器一挂服务注册和配置管理就全断了。第二Derby数据库的并发能力有限服务实例超过500个之后性能会明显下降。第三没有内置的监控和告警出问题了只能靠日志排查。如果你的测试环境规模在50个服务实例以内单机版完全够用。超过这个规模或者测试环境的重要性提升到接近生产级别就应该考虑迁移到集群版。集群版需要至少3个节点配合MySQL做外部存储部署复杂度会高不少但可靠性和性能都有质的提升。从单机版迁移到集群版数据迁移是个关键步骤。Derby的数据不能直接导入MySQL需要用Nacos提供的导出工具或者API把配置和服务数据导出来再导入到新的集群中。这个过程我建议在测试环境先演练一遍确认没问题再操作正式环境。我个人在实际操作中的体会是测试环境的Nacos单机版重点不是追求性能而是追求稳定和可恢复。把备份做好把日志清理好把端口和安全组配好这三件事做到位基本就不会出大问题。至于那些高级特性等真正需要的时候再折腾也不迟。