1. 先把nacos跑起来本地启动的完整过程我最早接触nacos是在做Spring Cloud微服务改造那会儿。当时团队里注册中心选型摆在面前的有Eureka、Consul、Zookeeper最后选了nacos理由很简单既能当注册中心又能当配置中心一套中间件管两件事省得维护两套系统。但真正上手之后才发现光是把nacos快速启动起来并跑通里面就有不少版本和环境的坑。1.1 版本选择为什么我建议从2.x开始nacos目前分两个大系1.x和2.x3.x已经在路上了。如果你是刚接触我建议直接下载2.x版本别碰1.x。原因主要有三个第一1.x的注册心跳机制是UDP推送给客户端长连接管理比较弱在高并发下会出现服务列表不一致的问题。2.x引入了gRPC长连接服务端主动推送配置变更实时性和稳定性都强了一个量级。第二1.x的控制台和2.x的控制台体验差距不小。2.x的配置管理界面支持了配置的导入导出、灰度发布、命名空间权限管理这些在1.x时代都比较弱。第三2.x的鉴权体系更完整。1.x的鉴权基本是摆设2.2.0之后把用户、角色、权限模型补齐了后面可以真正用于生产环境。下载地址就直接去GitHub的releases页面找nacos-server-2.x.x.zip或者.tar.gz包。Windows就下载zipLinux/Mac就下载tar.gz。1.2 Windows下的解压启动步骤Windows下启动nacos最简单的方式是直接解压后双击脚本运行。但很多人会在这一步卡住就是因为没搞懂nacos默认是集群模式启动的而本地开发通常只需要单机模式。步骤很简单解压到某个目录比如D:\nacos-server-2.4.3版本号按实际下载的来。进入bin目录。打开命令行执行startup.cmd -m standalone这里-m standalone参数就是指定单机模式启动。如果不带这个参数Windows下会默认尝试集群模式启动然后因为找不到集群配置文件直接报错。启动完成之后控制台会打印出nacos的启动日志路径然后你就可以访问http://localhost:8848/nacos默认账号密码是nacos/nacos。如果你看到的是8848端口被占用或者页面打不开那一般是下面几种情况。1.3 启动失败排查端口、JDK和内存端口占用是最常见的问题。查看8848端口有没有被别的进程占掉netstat -ano | findstr 8848如果被占据了两个选择杀掉占用进程或者改nacos的端口。改端口的话打开conf\application.properties找到server.port改成别的比如8849。JDK版本问题也经常遇到。nacos 2.x要求JDK 8以上但我实测在JDK 17下启动会有一些日志告警虽然不致命但会干扰排查。建议用JDK 8或者JDK 11跑nacos最稳跟Spring Boot 2.x的兼容性也最好。内存问题nacos默认JVM参数给得比较大。如果你本机内存比较紧张启动会很慢甚至直接起不来。可以改bin\startup.cmd里的JVM参数把-Xms和-Xmx调小一点比如-Xms256m -Xmx512m这样本地开发和测试完全够用。这里还有个经验nacos启动后如果看不到Nacos started successfully的日志基本就是启动失败。把日志文件打开看一下直接搜ERROR大多数问题都能一眼定位到。2. 把数据存进MySQL默认数据库换掉才能安心nacos默认自带的是内嵌的Derby数据库这个设计主要是为了让用户下载下来就能快速启动跑起来零配置、零依赖。但Derby只适合本地尝鲜生产环境必须换成MySQL否则你会遇到两个致命问题第一Derby的存储能力撑不住集群模式。集群模式下每个nacos节点都用自己的Derby数据根本不一致服务列表和配置会乱套。第二数据无法持久化备份。一旦容器或者节点挂了Derby里的数据跟着就没了。所以把数据源换成MySQL是nacos从“能跑”到“能生产用”的第一步。2.1 建库建表一条命令搞定nacos官方给了一份建表脚本路径在conf\mysql-schema.sql不同版本可能叫nacos-mysql.sql。你需要先建一个数据库比如就叫nacos_config然后执行这个脚本CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE nacos_config; SOURCE /path/to/mysql-schema.sql;注意字符集一定要用utf8mb4因为配置数据里可能包含表情符号或者其他多字节字符用utf8会报错或者数据丢失。执行完之后数据库里会出现几十张表包括config_info、service_info、user这些核心表。看到这些表出现了说明建库成功。2.2 MySQL 8.4.11版本的连接配置现在的热词里提到了MySQL 8.4.11这个版本比较新。换成MySQL数据源时除了改nacos配置还要注意数据库驱动。打开conf\application.properties找到这几行并修改spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneUTC db.user.0root db.password.0你的数据库密码这里有几个坑要重点说MySQL 8.x的驱动类名变了。8.x的驱动类名是com.mysql.cj.jdbc.Driver不再是老的com.mysql.jdbc.Driver。nacos的lib目录里自带的驱动如果是老版本连不上8.x的数据库。最简单的解决办法是下载最新的MySQL Connector/J替换掉nacoslib目录下的旧驱动jar包。serverTimezone必须配正确。8.x的JDBC驱动强制要求设置时区否则启动报错。国内的服务器建议用Asia/Shanghai不要直接写UTC否则配置里的时间会比北京时间早8个小时虽然大部分业务感知不到但排日志的时候会非常难受。useSSLfalse建议加上。本地开发连MySQL没必要开SSL开了反而增加握手延迟。生产环境如果走的是内网也可以关掉除非你的安全团队强制要求。2.3 替换Derby数据目录一个容易忽略的坑换完MySQL配置后重新启动nacos你会发现控制台还是能访问但数据已经落到MySQL里了。这里有个细节老版本的nacos如果已经在Derby里执行过建表或者存过数据换MySQL时可能会遇到表冲突。最好的做法是先把nacos停掉删掉data目录Derby的数据存储目录再启动。不然你可能会收到一堆关于重复键值或者表已存在的报错。还有个更隐蔽的问题如果你连着启动了好几次而data目录里已经有旧数据即使你配置了MySQLnacos 1.x在特定场景下还是可能去查Derby。这个在2.x版本里基本不存在了但为了干净我每次切换数据源都会顺手把data目录清掉。3. 生产部署别再用双击启动了Docker Compose部署nacos 3.x本地用脚本启动没问题但到了生产环境如果你还在用startup.sh裸奔那就是给自己找麻烦。生产环境要管的是怎么快速拉起、怎么配置环境变量、怎么跟其他服务编排一起启动、日志怎么持久化。这些Docker Compose都能给你安排得明明白白。3.1 Docker Compose部署的核心思路Docker Compose部署nacos只需要定义一个docker-compose.yml文件然后一条命令就能拉起来。但有几个点需要先搞清楚nacos镜像的版本要跟客户端匹配。现在热词里提到了nacos 3.x3.x在镜像仓库里已经能拉了。如果你用的是Spring Cloud Alibaba的客户端版本上要确认一下是否支持3.x服务端。目前生产环境2.x还是绝对主流3.x可以尝鲜但别急着上生产。单机模式和集群模式在容器里是通过环境变量切的。数据卷要挂出来。日志和配置必须挂到宿主机不然容器一重建日志全没了排障都没法排。3.2 一份可以直接复制的docker-compose.yml下面这份是我常用的单机模式配置对接MySQL数据源version: 3.8 services: nacos: image: nacos/nacos-server:v2.4.3 container_name: nacos environment: - MODEstandalone - SPRING_DATASOURCE_PLATFORMmysql - MYSQL_SERVICE_HOST你的数据库IP - MYSQL_SERVICE_DB_NAMEnacos_config - MYSQL_SERVICE_PORT3306 - MYSQL_SERVICE_USERroot - MYSQL_SERVICE_PASSWORD你的密码 - NACOS_AUTH_ENABLEtrue ports: - 8848:8848 - 9848:9848 - 9849:9849 volumes: - ./logs:/home/nacos/logs restart: always启动命令就两条docker-compose up -d docker-compose logs -f nacos看日志里出现Nacos started successfully就可以访问了。3.3 端口映射8848只是冰山一角很多人docker跑nacos只映射了8848端口然后客户端注册就疯狂失败。因为nacos 2.x默认还开了两个gRPC端口9848客户端gRPC端口用于注册、心跳、配置推送。9849服务端gRPC通信端口集群节点间同步用。这两个端口必须映射出去否则客户端能连上8848但连不上gRPC端口服务注册和配置订阅都会失败。它们的计算规则是主端口8848偏移量1000和1001。如果你把8848改成了8888那gRPC端口就是98481000偏移对应的逻辑即对应的端口会变成9849和9850。这个一定要记住改端口的时候gRPC端口也得跟着开放。docker方式跑nacos还有个好处就是环境变量配置比改application.properties更直观而且配置可以沉淀在docker-compose文件里换环境部署直接复用。4. 启动只是开始服务注册和配置集成的关键配置nacos跑起来了数据源也换成MySQL了这时候才真正开始干正事把你的应用接进nacos。4.1 Spring Boot应用注册进nacosSpring Boot接入nacos注册中心常用的方式是Spring Cloud Alibaba。在pom.xml里加依赖dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId version对应Spring Cloud Alibaba版本/version /dependency然后在application.yml里配nacos地址spring: application: name: user-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848这样启动你的Spring Boot应用在nacos控制台的“服务管理”页面就能看到user-service已经注册上来了。这里要特别注意版本对应关系。Spring Cloud Alibaba的版本和Spring Boot版本、nacos客户端版本是严格绑定的。版本不匹配时最常见的现象是应用日志里提示连接nacos失败但8848端口明明能通。我汇总了一下目前常用的对应关系Spring Cloud AlibabaSpring BootNacos客户端2021.0.5.02.6.x2.2.02022.0.0.03.0.x2.2.12023.0.1.03.2.x2.3.0踩过几次坑之后我的习惯是先确认Spring Boot版本再选Spring Cloud Alibaba版本最后由框架统一管理nacos客户端版本不自己手动指定。4.2 Dubbo接入nacos注册中心换一下就行如果你用的是Dubbo接入nacos也简单。Dubbo 3.x内置了nacos作为注册中心的支持配置方式dubbo: registry: address: nacos://127.0.0.1:8848就这么一行。其他Dubbo的配置不用动nacos会自动识别服务接口和协议信息。这里有个容易忽略的点Dubbo 3.x的接口级注册和服务级注册在nacos上有不同的元数据表现。如果你在nacos控制台的服务列表里看不到Dubbo接口先看一下是不是注册级别的问题在dubbo配置里加一行dubbo: application: register-mode: instance强制走实例级注册服务列表里就能看到了。4.3 Ribbon和nacos的关系负载均衡到底谁说了算热词里提到了Ribbon和nacos的关系这是很多做Spring Cloud的老玩家关心的问题。简单来说Ribbon是客户端负载均衡组件nacos注册中心负责提供服务实例列表两者是配合关系nacos动态感知服务上下线、维护实例列表Ribbon拿到这个列表之后按负载均衡策略选一个实例发起调用。Spring Cloud Alibaba的nacos-discovery依赖里已经内置了Ribbon的整合不需要额外引入。你只需要在LoadBalanced注解的RestTemplate上正常使用Bean LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); }Ribbon会通过nacos拿到实例列表然后默认使用轮询策略发起调用。如果你用的是Spring Cloud LoadBalancer新版本的默认组件原理也是一样的只是实现换了。4.4 配置中心与热更新动态刷新算是最实用的功能之一nacos作为配置中心比Spring Cloud Config好用太多因为它自带控制台改配置不用走Git仓库、不用重启应用、不用等刷新Job。先把配置中心的依赖加上dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency然后配置bootstrap.ymlSpring Boot 2.4之后也可以用spring.config.import的方式spring: config: import: nacos:user-service.yaml在nacos控制台建一个Data ID为user-service.yaml的配置文件写上配置项。要实现配置修改后不需要重启就生效关键有三点配置类上加RefreshScope注解配置中心的配置优先级要搞清楚别跟本地配置文件冲突实际生产环境建议用ConfigurationProperties配合RefreshScope比散落的Value好管理我实际用下来nacos的配置热更新推送非常快基本1秒内就能通知到所有订阅的客户端。这在灰度发布、动态开关、紧急降级这些场景里价值极其大。5. 启动完先别急着上线这些安全加固必须做nacos裸奔在公网或者内网风险比你想的大得多。热词里提到了好几个安全漏洞这些不是危言耸听都是真实存在并被扫描工具验证过的。我把最常见的几个问题整理一遍修复方案也直接给出来。5.1 namespaces未授权访问漏洞为什么被扫出来就该马上处理这个漏洞在nacos 2.2.0之前的版本非常典型。攻击者不需要登录直接调用特定接口就能获取、操作命名空间列表甚至能增删改命名空间。而命名空间是nacos隔离环境的重要机制被攻击者改掉会直接影响整个微服务的调用链。漏洞根源鉴权开关没打开且部分老版本接口压根没做权限校验。修复方案分两步第一步升级版本到2.2.0.1或以上。这个漏洞在新版本里做了修复未鉴权的请求会被拒绝。第二步开启鉴权。在nacos的application.properties或环境变量里设置nacos.core.auth.enabledtrue nacos.core.auth.plugin.nacos.token.secret.key自定义的Base64密钥注意nacos.core.auth.enabledtrue是硬开关。只升级不开鉴权等于门锁换了个新的但门没关。开启鉴权之后所有客户端接入nacos都需要配置用户名密码spring: cloud: nacos: discovery: username: nacos password: 你自己改的密码5.2 默认JWT密钥绕过漏洞CNVD-2023-17316的修复这个漏洞影响面极大原理是nacos的用户认证用的是JWT Token而旧版本内置了一组固定的、公开的默认密钥。攻击者直接用这组公开的密钥伪造管理员Token就可以绕过登录以管理员身份调用所有接口。修复办法很简单第一升级nacos版本到2.2.0.1及以上。新版本里默认密钥的生成方式变了不再是写死的。第二如果是2.2.0.1以上但还用着默认密钥那也一样危险。必须手动设置一个独立的密钥nacos.core.auth.plugin.nacos.token.secret.key至少32字节的Base64编码字符串生成方式可以用OpenSSLopenssl rand -base64 32把这串输出配置到上面那个参数里就行。我自己处理这种漏洞的次数已经不少了经验是修完之后一定要重新验证不仅要在控制台登录测试还要用客户端注册服务测试。因为有时候你改了密钥但客户端还在用旧Token连服务会注册不上这种“修好了但是服务挂了”的情况比漏洞本身还让人头大。5.3 配置SSL证书nacos做成HTTPS访问nacos控制台默认走HTTP如果部署在公网登录密码和Token都是明文传输的跟裸奔没区别。给nacos配置SSL证书是公网部署的必选项。nacos支持在application.properties里配置SSLserver.ssl.enabledtrue server.ssl.certificate-chain-fileclasspath:cert/你的证书.pem server.ssl.private-key-fileclasspath:cert/你的私钥.key证书可以从云服务商申请免费的单域名或通配符证书。注意证书格式必须是PEM如果是其他格式需要用OpenSSL转一下。配好之后nacos的访问地址就变成https://localhost:8848/nacos同时客户端的注册地址server-addr也要同步改成HTTPS协议spring: cloud: nacos: discovery: server-addr: https://你的域名:8848这个改动很关键改完客户端会报证书信任错误。解决方式是在应用的JVM参数里把nacos服务器的证书加入信任库或者让客户端跳过证书校验内网环境可以用这个方案公网不建议。5.4 其他容易被忽略的安全细节除了上面三个大漏洞还有几个细节我建议你顺手一起做了修改默认账号密码。默认的nacos/nacos是人尽皆知的不改成强密码即使开了鉴权也等于白搭。排除非必要端口。nacos 2.x的gRPC端口9848和主端口8848建议都只对应用所在网段开放不要对全公网暴露。如果必须公网访问配置安全组白名单。配置命名空间隔离。把不同环境dev、test、prod用命名空间隔开即使某个环境的配置泄露了攻击者也不能直接拿到生产环境的配置中心权限。nacos告警监控。生产环境的nacos最好配置健康检查和告警nacos挂掉不会让已经注册过的服务不可用客户端有缓存但新服务的注册和配置的动态刷新会断掉这种“半死不活”的状态最难排查。6. 几个提升使用体验的小技巧最后分享几个我自己用得比较多的小技巧都是实际踩坑踩出来的经验。技巧一本地开发用-m standalone别用IDE直接跑源码。有些人为了调试方便直接从GitHub拉源码在IDE里启动nacos这样也能跑但版本难控制而且依赖下起来特别慢。直接下载release包简单又干净。技巧二nacos的日志要定期清理。默认日志是按天滚动的但如果你在一个高并发的服务上用了nacos配置推送多了日志量会超出你的想象。建议在logback配置里调整保留策略或者直接写个定时任务清理超过7天的日志。技巧三配置中心只放需要动态变的内容。不要把所有配置都丢到nacos里静态配置和本地敏感配置留在本地文件更安全。nacos配置中心最好的使用方式是放需要动态调整的开关注、放跨服务共享的公共配置、放非敏感的业务参数。技巧四稳妥起见线上nacos集群至少三节点。单机部署的nacos如果挂掉配置中心是彻底不可用的。微服务的老实例还能撑着调用但发布新服务或者扩缩容就会出问题。三节点集群配合MySQL扛住生产环境的日常故障基本够了。nacos这个中间件用起来不难但想用得顺手关键在于把版本、数据源、鉴权、端口这些基础环节一次理顺。我见过太多团队在nacos上栽跟头最后排查下来都是很基础的问题版本不匹配、鉴权没开、端口没放全。希望这篇能帮你少走一些弯路。
