简介面向Kylin V10信创环境下的arm64架构服务器Nacos 2.4.3 Docker镜像离线包提供了开箱即用的微服务基础设施。该镜像专为ARM处理器优化可直接通过docker load导入免去联网拉取或自行编译的适配过程适用于国产化环境中的服务注册、发现与配置管理场景。压缩包内共有23个文件包括9个json配置/清单文件、7个version版本信息文件以及7个layer.tar镜像分层文件整体大小约215.64MB文件布局与标准Docker镜像导出结构一致便于实现完整性校验与离线分发。目前已有266人学习下载适合在信创合规要求下从事Spring Cloud微服务开发或运维的工程师使用。借助该资源团队成员无需手动解决arm64平台兼容性问题即可快速启动Nacos服务将部署耗时从小时级压缩到分钟级同时获得稳定的命名空间隔离、动态配置更新等能力显著提升微服务架构的交付与维护效率。 这阵子折腾 Nacos 2.4.3 的 ARM64 架构 Docker 镜像包算是把从“直接拉镜像”到“自己动手构建”这条路完整踩了一遍。官方 nacos-server 镜像在 Docker Hub 上虽然热度很高但有不少版本只有 x86_64 的构建产物拿到 Apple Silicon、ARM 云主机或者是各种 ARM 开发板上一跑要么架构不匹配被 Docker 默不作声地模拟执行要么性能差到让人怀疑人生。如果你也正在给 ARM 环境找一个能直接用的 Nacos 2.4.3 镜像包或者想彻底搞清楚 arm64 和 amd64 那点区别那这篇实操记录应该能帮你省不少时间。1. 为什么非要 ARM64 版 Nacos1.1 amd64 和 arm64差的不只是几个字母很多同学第一次意识到架构问题是在 Windows 下载软件时看到 “download for windows amd64” 和 “download for windows arm64” 两个选项。这两个选项核心区别就是 CPU 指令集amd64 对应 Intel 和 AMD 的 x86 系处理器arm64 对应高通、苹果、飞腾、鲲鹏这类使用 ARM 指令集的芯片。程序在运行时最终都要变成 CPU 能识别的机器指令选错架构最直观的结果就是装不上或者装上后在兼容层里龟速运行。到了 Docker 世界里这个逻辑会被进一步放大。Docker 镜像里打包的不只是应用代码还包括底层基础系统、运行时环境每个镜像都有一个architecture标记。当你在 ARM 机器上执行docker run一个 amd64 镜像时Docker 不会直接报错说“不能跑”而是通过 QEMU 模拟层去执行表面看着容器起来了实际上每一条指令都在翻译一旦遇到 JNI、网络 IO 密集或者并发高的场景性能和稳定性都会出问题。所以在 ARM 环境部署服务最正确的做法就是找对应的 arm64 镜像包。1.2 官方 Nacos 2.4.3 镜像的坑Nacos 官方在 Docker Hub 上维护的nacos/nacos-server镜像热门版本很多但对于 ARM64 的支持一直不太稳定。我实际拉取nacos/nacos-server:2.4.3之后用docker manifest inspect看了一下镜像的架构层里边主要就是 amd64并没有完整提供 arm64 的构建产物。如果你直接在一台纯 ARM 机器上去拉Docker 能拉下来但跑起来其实是模拟执行内存占用会飙得离谱服务启动到一半就各种诡异报错。这里有个常见的误区在 Mac 的 Docker Desktop 上跑官方镜像看起来没问题不代表镜像兼容 ARM64。因为 Docker Desktop 默认会带一层轻量虚拟机底层帮你做了架构转换所以很多问题在 Mac 上被掩盖了。换到真正的 ARM Linux 实例上才会原形毕露。这也是为什么我们需要一个真正面向 Linux/arm64 的 Nacos 2.4.3 镜像包。2. 先判断架构再决定镜像获取方式2.1 如何确认当前环境的架构别凭感觉猜直接看命令输出最快。在 Linux 或者 macOS 上执行uname -m返回aarch64就是 ARM64返回x86_64就是 amd64在服务器上也可以用docker info --format {{.Architecture}}来确认 Docker 看到的宿主架构。命令输出架构说明x86_64amd64Intel/AMD 处理器aarch64arm64ARM 处理器含 Apple Silicon Macarmv7larm/v732 位 ARM不适合直接跑 Nacos有个小细节值得注意在 Apple Silicon Mac 上uname -m返回的是arm64但如果你是在 Rosetta 模拟的终端里执行可能返回x86_64。所以判断的依据要以目标部署机器的实际架构为准而不是构建机。2.2 镜像获取的三种路径拿到架构信息后获取 Nacos 2.4.3 ARM64 镜像包基本就三条路官方已经提供 arm64 版本直接docker pull nacos/nacos-server:2.4.3拉完用docker inspect确认架构。官方没有对应架构自己从源码构建这是本文重点。内部私有仓库已经有同事构建好的直接docker pull内网地址省去全部编译工作。判断一个远程镜像是否包含 arm64 层最简单的方式是执行docker manifest inspect nacos/nacos-server:2.4.3 --verbose输出里会有architecture字段。如果只有amd64那就老老实实进入下一步自己构建。这个方法对任何镜像都适用建议收藏。3. 手工构建 Nacos 2.4.3 ARM64 镜像包的完整流程3.1 构建环境准备Nacos 本身是 Java 项目Java 编译出来的 jar 包是跨架构的所以构建 ARM64 镜像没有想象中复杂核心是将编译好的 Nacos 服务打进一个 ARM64 基础镜像里。需要准备的环境如下Linux/ARM64 机器或者 x86 机器上装了 Docker BuildxJDK 17Maven 3.6 以上Gitjava -version mvn -version如果你的构建机就是目标 ARM 服务器那最省事。如果只有 x86 机器也可以用 Docker Buildx 的--platform linux/arm64来交叉构建代价是第一次构建要下载 ARM 模拟层编译耗时更长。3.2 源码拉取与 Maven 编译Nacos 的源码仓库结构很清晰直接切到 2.4.3 标签然后用官方的 release 配置编译。git clone -b 2.4.3 https://github.com/alibaba/nacos.git cd nacos mvn -Prelease-nacos -DskipTests -Drat.skiptrue clean install这里的-Prelease-nacos会激活完整的打包配置生成发布版目录-DskipTests跳过测试避免本地环境不一致导致测试失败-Drat.skiptrue跳过 Apache 的源码版权检查这个检查在部分环境下会误伤构建。编译完成后产物在distribution/target/目录下ls distribution/target/ # 输出里能看到 nacos-server-2.4.3.tar.gz解压出nacos目录后续 Docker 构建直接用这个目录cd distribution/target tar -xzf nacos-server-2.4.3.tar.gz mv nacos-server-2.4.3 nacos3.3 编写一份适配 ARM64 的 Dockerfile基础镜像我选的是eclipse-temurin:17-jre-jammy。这个镜像在 Docker Hub 上同时提供 amd64 和 arm64 多个架构的构建而且基于 Ubuntu JammyJava 17 的运行时对 Nacos 2.4.x 的兼容性很好。如果你对 JDK 8 有执念也可以换成arm64v8/openjdk:8-jre但建议优先用 17省得后续升级版本时踩坑。FROM eclipse-temurin:17-jre-jammy ENV NACOS_HOME/home/nacos ENV MODEstandalone WORKDIR ${NACOS_HOME} # 将上一步解压出来的 nacos 目录复制进镜像 COPY nacos/ ${NACOS_HOME}/ EXPOSE 8848 9848 9849 ENTRYPOINT [bash, bin/startup.sh, -m, standalone]这个 Dockerfile 看起来简单但有几个点值得展开。Nacos 的startup.sh脚本会根据环境变量JVM_XMS、JVM_XMX等来调整堆内存如果没有专门设置默认配置是 512m 起对于 ARM64 的小内存服务器可能会偏紧张。建议在运行时通过-e JVM_XMS256m -e JVM_XMX256m来控制而不是在镜像里写死。另一个点是端口Nacos 2.x 不止 8848 一个端口9848 和 9849 分别是客户端 gRPC 和集群通信端口Dockerfile 里必须一并暴露否则容器跨主机通信必出问题。3.4 构建镜像并导出在 ARM64 构建机上直接执行docker build -t nacos-server:2.4.3-arm64 .在 x86 机器上交叉构建则需要初始化 buildx 并指定平台docker buildx create --use docker buildx build --platform linux/arm64 -t nacos-server:2.4.3-arm64 --load .--load参数会把构建结果加载进本地镜像列表方便直接导出。如果你要把镜像包分发到离线环境用docker save导出并压缩这一步在镜像包交付时很常用docker save nacos-server:2.4.3-arm64 | gzip nacos-2.4.3-arm64.tar.gz目标机器上导入和解包一条命令搞定docker load nacos-2.4.3-arm64.tar.gz4. 部署实战从单机到 MySQL 持久化4.1 单机模式快速验证镜像构建好了先在单机模式跑起来验证一下。单机模式使用 Nacos 内置的 Derby 数据库不依赖外部存储适合先确认镜像本身没问题。docker run -d --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e NACOS_AUTH_ENABLEtrue \ nacos-server:2.4.3-arm64启动后稍等几秒访问控制台地址http://localhost:8848/nacos默认用户名密码是nacos/nacos。首次登录如果看到 403 或者账号无法认证多半是鉴权相关参数没有配全这种情况可以把NACOS_AUTH_ENABLE先关掉等确认功能正常后再逐步把鉴权、密钥这些安全性配置加上。这里强调一下用docker run部署时8848 是控制台和配置接口端口9848 是客户端 gRPC 主端口9849 是服务端通信端口。只映射 8848 的话服务注册和配置拉取都会超时这是新手最容易踩的坑。4.2 接入 MySQL 持久化单机模式的内置 Derby 存储只适合临时验证。生产环境哪怕只有单个节点也强烈建议接 MySQL。原因很简单Derby 的数据文件在容器里容器一删数据就没了而且 Nacos 集群模式下 Derby 的分布式协调能力并不适合实际生产。先在 MySQL 里建好库并导入 Nacos 的建表脚本CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建表脚本在刚才解压的nacos/conf/mysql-schema.sql里执行mysql -h 127.0.0.1 -u root -p nacos_config nacos/conf/mysql-schema.sql然后启动容器通过环境变量指定数据库连接信息docker run -d --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST127.0.0.1 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERroot \ -e MYSQL_SERVICE_PASSWORDyourpassword \ nacos-server:2.4.3-arm64接入 MySQL 后Nacos 启动时会自动检测数据源。如果库表结构不对或者连接信息有误日志里会明确报出Ensure that the current user has permissions to access the database之类的错误这时候回头检查建表脚本是否完整执行即可。4.3 端口、内存和鉴权参数说明生产部署时下面这几个参数需要单独确认。参数/端口默认值说明8848控制台 HTTP API必须暴露供浏览器和客户端访问9848客户端 gRPC 端口必须暴露服务注册发现主要走这个端口9849服务端通信端口集群模式下必须暴露JVM_XMS / JVM_XMX512m / 512m内存紧张时可以调成 256mNACOS_AUTH_TOKEN无开启鉴权后必须设置一个 32 位以上的密钥MODEcluster单机部署必须显式改为 standalone如果容器运行在 NAT 网络环境下服务注册到注册中心的 IP 可能会变成容器内网 IP导致其他机器访问不到。此时需要设置NACOS_SERVER_IP环境变量指定宿主机对外 IP这个问题在云服务器和虚拟机部署时特别常见。5. 常见问题和排查实录5.1 镜像拉下来一启动就崩溃这种情况十有八九是架构不匹配。ARM 机器上强行跑 amd64 镜像启动日志往往会出现Exec format error或者 JVM 无法加载的提示。排查方式很简单查看镜像架构确认自己的机器架构两者必须一致。docker inspect nacos-server:2.4.3-arm64 --format {{.Os}}/{{.Architecture}}如果你用的是docker-compose部署检查服务定义里有没有限制平台比如platform: linux/arm64如果写成linux/amd64即使本地有 arm64 镜像也会强制拉取 amd64 版本。5.2 控制台能打开但服务注册不上控制台能打开说明 8848 端口没问题服务注册不上问题基本出在 9848 端口上。Nacos 2.x 客户端和服务端之间的 gRPC 长连接默认用的是主端口加 1000 的偏移也就是 9848。如果云安全组、防火墙或者 docker 端口映射只开了 8848客户端连接会被断开报错信息里会出现Connection refused或者Client not connected字样。解决办法是把 9848 和 9849 都加入防火墙白名单并确保容器端口映射完整。还有一个小概率原因是服务端 IP 识别错误在NACOS_SERVER_IP没有设置的情况下Nacos 可能把注册地址识别成容器内网 IP客户端连不上这时候手动指定宿主机 IP 即可。5.3 Maven 编译时依赖下载太慢从源码构建 Nacos 2.4.3 时Maven 要拉取大量依赖。如果你的网络环境访问 Maven Central 速度不理想可以在~/.m2/settings.xml里配置阿里云镜像仓库这是国内开发者最常用的加速方式和 Docker 的镜像加速器是两回事但解决问题的思路一致。mirror idaliyunmaven/id mirrorOf*/mirrorOf nameAliyun Public Maven Repository/name urlhttps://maven.aliyun.com/repository/public/url /mirror注意配置之后如果构建报证书或者仓库访问失败把mirrorOf从*改成central只代理 Maven Central避免影响其他插件仓库的解析。5.4 Docker 拉取基础镜像速度慢Dockerfile 里用的eclipse-temurin:17-jre-jammy体积不小拉取慢会影响整体构建效率。可以给 Docker daemon 配置加速器在/etc/docker/daemon.json里添加 registry-mirrors 配置重启 Docker 后生效。这块属于基础设施常规优化实际操作时注意把你自己的镜像源放在最前面加速效果会更明显。最后再分享一个实际操作中的小习惯镜像构建成功后我会在镜像的 tag 里明确标注架构比如nacos-server:2.4.3-arm64而不是只写2.4.3。因为在团队协作时x86 的同事很可能把你导出的 arm64 包直接拉去跑然后反馈“你的镜像怎么起不来”。标注清楚架构再配合docker save打成 tar 包分发能省掉很多无意义的沟通成本。另外如果你打算长期在不同架构之间切换部署建议学会用docker manifest工具检查远程仓库的架构支持情况这个技能在维护内部镜像仓库时非常实用。本文还有配套的精品资源点击获取 
长河君 · 2026/9/3 18:27:37 · 阅读 1.2k Nacos 2.4.3 ARM64 Docker镜像构建与部署实战指南
简介面向Kylin V10信创环境下的arm64架构服务器Nacos 2.4.3 Docker镜像离线包提供了开箱即用的微服务基础设施。该镜像专为ARM处理器优化可直接通过docker load导入免去联网拉取或自行编译的适配过程适用于国产化环境中的服务注册、发现与配置管理场景。压缩包内共有23个文件包括9个json配置/清单文件、7个version版本信息文件以及7个layer.tar镜像分层文件整体大小约215.64MB文件布局与标准Docker镜像导出结构一致便于实现完整性校验与离线分发。目前已有266人学习下载适合在信创合规要求下从事Spring Cloud微服务开发或运维的工程师使用。借助该资源团队成员无需手动解决arm64平台兼容性问题即可快速启动Nacos服务将部署耗时从小时级压缩到分钟级同时获得稳定的命名空间隔离、动态配置更新等能力显著提升微服务架构的交付与维护效率。 这阵子折腾 Nacos 2.4.3 的 ARM64 架构 Docker 镜像包算是把从“直接拉镜像”到“自己动手构建”这条路完整踩了一遍。官方 nacos-server 镜像在 Docker Hub 上虽然热度很高但有不少版本只有 x86_64 的构建产物拿到 Apple Silicon、ARM 云主机或者是各种 ARM 开发板上一跑要么架构不匹配被 Docker 默不作声地模拟执行要么性能差到让人怀疑人生。如果你也正在给 ARM 环境找一个能直接用的 Nacos 2.4.3 镜像包或者想彻底搞清楚 arm64 和 amd64 那点区别那这篇实操记录应该能帮你省不少时间。1. 为什么非要 ARM64 版 Nacos1.1 amd64 和 arm64差的不只是几个字母很多同学第一次意识到架构问题是在 Windows 下载软件时看到 “download for windows amd64” 和 “download for windows arm64” 两个选项。这两个选项核心区别就是 CPU 指令集amd64 对应 Intel 和 AMD 的 x86 系处理器arm64 对应高通、苹果、飞腾、鲲鹏这类使用 ARM 指令集的芯片。程序在运行时最终都要变成 CPU 能识别的机器指令选错架构最直观的结果就是装不上或者装上后在兼容层里龟速运行。到了 Docker 世界里这个逻辑会被进一步放大。Docker 镜像里打包的不只是应用代码还包括底层基础系统、运行时环境每个镜像都有一个architecture标记。当你在 ARM 机器上执行docker run一个 amd64 镜像时Docker 不会直接报错说“不能跑”而是通过 QEMU 模拟层去执行表面看着容器起来了实际上每一条指令都在翻译一旦遇到 JNI、网络 IO 密集或者并发高的场景性能和稳定性都会出问题。所以在 ARM 环境部署服务最正确的做法就是找对应的 arm64 镜像包。1.2 官方 Nacos 2.4.3 镜像的坑Nacos 官方在 Docker Hub 上维护的nacos/nacos-server镜像热门版本很多但对于 ARM64 的支持一直不太稳定。我实际拉取nacos/nacos-server:2.4.3之后用docker manifest inspect看了一下镜像的架构层里边主要就是 amd64并没有完整提供 arm64 的构建产物。如果你直接在一台纯 ARM 机器上去拉Docker 能拉下来但跑起来其实是模拟执行内存占用会飙得离谱服务启动到一半就各种诡异报错。这里有个常见的误区在 Mac 的 Docker Desktop 上跑官方镜像看起来没问题不代表镜像兼容 ARM64。因为 Docker Desktop 默认会带一层轻量虚拟机底层帮你做了架构转换所以很多问题在 Mac 上被掩盖了。换到真正的 ARM Linux 实例上才会原形毕露。这也是为什么我们需要一个真正面向 Linux/arm64 的 Nacos 2.4.3 镜像包。2. 先判断架构再决定镜像获取方式2.1 如何确认当前环境的架构别凭感觉猜直接看命令输出最快。在 Linux 或者 macOS 上执行uname -m返回aarch64就是 ARM64返回x86_64就是 amd64在服务器上也可以用docker info --format {{.Architecture}}来确认 Docker 看到的宿主架构。命令输出架构说明x86_64amd64Intel/AMD 处理器aarch64arm64ARM 处理器含 Apple Silicon Macarmv7larm/v732 位 ARM不适合直接跑 Nacos有个小细节值得注意在 Apple Silicon Mac 上uname -m返回的是arm64但如果你是在 Rosetta 模拟的终端里执行可能返回x86_64。所以判断的依据要以目标部署机器的实际架构为准而不是构建机。2.2 镜像获取的三种路径拿到架构信息后获取 Nacos 2.4.3 ARM64 镜像包基本就三条路官方已经提供 arm64 版本直接docker pull nacos/nacos-server:2.4.3拉完用docker inspect确认架构。官方没有对应架构自己从源码构建这是本文重点。内部私有仓库已经有同事构建好的直接docker pull内网地址省去全部编译工作。判断一个远程镜像是否包含 arm64 层最简单的方式是执行docker manifest inspect nacos/nacos-server:2.4.3 --verbose输出里会有architecture字段。如果只有amd64那就老老实实进入下一步自己构建。这个方法对任何镜像都适用建议收藏。3. 手工构建 Nacos 2.4.3 ARM64 镜像包的完整流程3.1 构建环境准备Nacos 本身是 Java 项目Java 编译出来的 jar 包是跨架构的所以构建 ARM64 镜像没有想象中复杂核心是将编译好的 Nacos 服务打进一个 ARM64 基础镜像里。需要准备的环境如下Linux/ARM64 机器或者 x86 机器上装了 Docker BuildxJDK 17Maven 3.6 以上Gitjava -version mvn -version如果你的构建机就是目标 ARM 服务器那最省事。如果只有 x86 机器也可以用 Docker Buildx 的--platform linux/arm64来交叉构建代价是第一次构建要下载 ARM 模拟层编译耗时更长。3.2 源码拉取与 Maven 编译Nacos 的源码仓库结构很清晰直接切到 2.4.3 标签然后用官方的 release 配置编译。git clone -b 2.4.3 https://github.com/alibaba/nacos.git cd nacos mvn -Prelease-nacos -DskipTests -Drat.skiptrue clean install这里的-Prelease-nacos会激活完整的打包配置生成发布版目录-DskipTests跳过测试避免本地环境不一致导致测试失败-Drat.skiptrue跳过 Apache 的源码版权检查这个检查在部分环境下会误伤构建。编译完成后产物在distribution/target/目录下ls distribution/target/ # 输出里能看到 nacos-server-2.4.3.tar.gz解压出nacos目录后续 Docker 构建直接用这个目录cd distribution/target tar -xzf nacos-server-2.4.3.tar.gz mv nacos-server-2.4.3 nacos3.3 编写一份适配 ARM64 的 Dockerfile基础镜像我选的是eclipse-temurin:17-jre-jammy。这个镜像在 Docker Hub 上同时提供 amd64 和 arm64 多个架构的构建而且基于 Ubuntu JammyJava 17 的运行时对 Nacos 2.4.x 的兼容性很好。如果你对 JDK 8 有执念也可以换成arm64v8/openjdk:8-jre但建议优先用 17省得后续升级版本时踩坑。FROM eclipse-temurin:17-jre-jammy ENV NACOS_HOME/home/nacos ENV MODEstandalone WORKDIR ${NACOS_HOME} # 将上一步解压出来的 nacos 目录复制进镜像 COPY nacos/ ${NACOS_HOME}/ EXPOSE 8848 9848 9849 ENTRYPOINT [bash, bin/startup.sh, -m, standalone]这个 Dockerfile 看起来简单但有几个点值得展开。Nacos 的startup.sh脚本会根据环境变量JVM_XMS、JVM_XMX等来调整堆内存如果没有专门设置默认配置是 512m 起对于 ARM64 的小内存服务器可能会偏紧张。建议在运行时通过-e JVM_XMS256m -e JVM_XMX256m来控制而不是在镜像里写死。另一个点是端口Nacos 2.x 不止 8848 一个端口9848 和 9849 分别是客户端 gRPC 和集群通信端口Dockerfile 里必须一并暴露否则容器跨主机通信必出问题。3.4 构建镜像并导出在 ARM64 构建机上直接执行docker build -t nacos-server:2.4.3-arm64 .在 x86 机器上交叉构建则需要初始化 buildx 并指定平台docker buildx create --use docker buildx build --platform linux/arm64 -t nacos-server:2.4.3-arm64 --load .--load参数会把构建结果加载进本地镜像列表方便直接导出。如果你要把镜像包分发到离线环境用docker save导出并压缩这一步在镜像包交付时很常用docker save nacos-server:2.4.3-arm64 | gzip nacos-2.4.3-arm64.tar.gz目标机器上导入和解包一条命令搞定docker load nacos-2.4.3-arm64.tar.gz4. 部署实战从单机到 MySQL 持久化4.1 单机模式快速验证镜像构建好了先在单机模式跑起来验证一下。单机模式使用 Nacos 内置的 Derby 数据库不依赖外部存储适合先确认镜像本身没问题。docker run -d --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e NACOS_AUTH_ENABLEtrue \ nacos-server:2.4.3-arm64启动后稍等几秒访问控制台地址http://localhost:8848/nacos默认用户名密码是nacos/nacos。首次登录如果看到 403 或者账号无法认证多半是鉴权相关参数没有配全这种情况可以把NACOS_AUTH_ENABLE先关掉等确认功能正常后再逐步把鉴权、密钥这些安全性配置加上。这里强调一下用docker run部署时8848 是控制台和配置接口端口9848 是客户端 gRPC 主端口9849 是服务端通信端口。只映射 8848 的话服务注册和配置拉取都会超时这是新手最容易踩的坑。4.2 接入 MySQL 持久化单机模式的内置 Derby 存储只适合临时验证。生产环境哪怕只有单个节点也强烈建议接 MySQL。原因很简单Derby 的数据文件在容器里容器一删数据就没了而且 Nacos 集群模式下 Derby 的分布式协调能力并不适合实际生产。先在 MySQL 里建好库并导入 Nacos 的建表脚本CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建表脚本在刚才解压的nacos/conf/mysql-schema.sql里执行mysql -h 127.0.0.1 -u root -p nacos_config nacos/conf/mysql-schema.sql然后启动容器通过环境变量指定数据库连接信息docker run -d --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST127.0.0.1 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERroot \ -e MYSQL_SERVICE_PASSWORDyourpassword \ nacos-server:2.4.3-arm64接入 MySQL 后Nacos 启动时会自动检测数据源。如果库表结构不对或者连接信息有误日志里会明确报出Ensure that the current user has permissions to access the database之类的错误这时候回头检查建表脚本是否完整执行即可。4.3 端口、内存和鉴权参数说明生产部署时下面这几个参数需要单独确认。参数/端口默认值说明8848控制台 HTTP API必须暴露供浏览器和客户端访问9848客户端 gRPC 端口必须暴露服务注册发现主要走这个端口9849服务端通信端口集群模式下必须暴露JVM_XMS / JVM_XMX512m / 512m内存紧张时可以调成 256mNACOS_AUTH_TOKEN无开启鉴权后必须设置一个 32 位以上的密钥MODEcluster单机部署必须显式改为 standalone如果容器运行在 NAT 网络环境下服务注册到注册中心的 IP 可能会变成容器内网 IP导致其他机器访问不到。此时需要设置NACOS_SERVER_IP环境变量指定宿主机对外 IP这个问题在云服务器和虚拟机部署时特别常见。5. 常见问题和排查实录5.1 镜像拉下来一启动就崩溃这种情况十有八九是架构不匹配。ARM 机器上强行跑 amd64 镜像启动日志往往会出现Exec format error或者 JVM 无法加载的提示。排查方式很简单查看镜像架构确认自己的机器架构两者必须一致。docker inspect nacos-server:2.4.3-arm64 --format {{.Os}}/{{.Architecture}}如果你用的是docker-compose部署检查服务定义里有没有限制平台比如platform: linux/arm64如果写成linux/amd64即使本地有 arm64 镜像也会强制拉取 amd64 版本。5.2 控制台能打开但服务注册不上控制台能打开说明 8848 端口没问题服务注册不上问题基本出在 9848 端口上。Nacos 2.x 客户端和服务端之间的 gRPC 长连接默认用的是主端口加 1000 的偏移也就是 9848。如果云安全组、防火墙或者 docker 端口映射只开了 8848客户端连接会被断开报错信息里会出现Connection refused或者Client not connected字样。解决办法是把 9848 和 9849 都加入防火墙白名单并确保容器端口映射完整。还有一个小概率原因是服务端 IP 识别错误在NACOS_SERVER_IP没有设置的情况下Nacos 可能把注册地址识别成容器内网 IP客户端连不上这时候手动指定宿主机 IP 即可。5.3 Maven 编译时依赖下载太慢从源码构建 Nacos 2.4.3 时Maven 要拉取大量依赖。如果你的网络环境访问 Maven Central 速度不理想可以在~/.m2/settings.xml里配置阿里云镜像仓库这是国内开发者最常用的加速方式和 Docker 的镜像加速器是两回事但解决问题的思路一致。mirror idaliyunmaven/id mirrorOf*/mirrorOf nameAliyun Public Maven Repository/name urlhttps://maven.aliyun.com/repository/public/url /mirror注意配置之后如果构建报证书或者仓库访问失败把mirrorOf从*改成central只代理 Maven Central避免影响其他插件仓库的解析。5.4 Docker 拉取基础镜像速度慢Dockerfile 里用的eclipse-temurin:17-jre-jammy体积不小拉取慢会影响整体构建效率。可以给 Docker daemon 配置加速器在/etc/docker/daemon.json里添加 registry-mirrors 配置重启 Docker 后生效。这块属于基础设施常规优化实际操作时注意把你自己的镜像源放在最前面加速效果会更明显。最后再分享一个实际操作中的小习惯镜像构建成功后我会在镜像的 tag 里明确标注架构比如nacos-server:2.4.3-arm64而不是只写2.4.3。因为在团队协作时x86 的同事很可能把你导出的 arm64 包直接拉去跑然后反馈“你的镜像怎么起不来”。标注清楚架构再配合docker save打成 tar 包分发能省掉很多无意义的沟通成本。另外如果你打算长期在不同架构之间切换部署建议学会用docker manifest工具检查远程仓库的架构支持情况这个技能在维护内部镜像仓库时非常实用。本文还有配套的精品资源点击获取