ARM架构aarch64服务器部署实战：从系统选型到Docker与性能优化

简介：本资源面向政府信息化项目实施人员、ARM平台系统集成工程师及国产化替代场景下的Java应用部署工程师，解决在aarch64架构内网环境中无法使用yum源时，Java Web项目（含GIS模块）所依赖的全套基础组件离线部署难题。资源包共828个文件，涵盖292个Java运行与业务jar包、214个配置及样式xml/properties文件、72个地理图层png/tif等栅格资源，以及MySQL、Redis、GeoServer、libstdc++等关键服务的aarch64原生tar/rpm安装包和配套shell脚本，整体容量697.3MB。已有1714人学习下载，内容包含作者实操整理的《资源整合说明》《分组件安装教程》及一个高效可用的aarch64专用RPM搜索地址，显著降低跨架构适配门槛；预览可见startup.bat、shutdown.bat、ol-demo.cfg等典型部署脚本与配置，体现完整服务启停、GIS样式定义与地理数据加载能力，具备即取即用的工程落地价值。 接手过几台ARM架构服务器的朋友，大概率都经历过这种场面：本地x86环境里跑得好好的项目，代码打包传到aarch64机器上，一条命令下去，直接甩给你一句“not this operating system platform”或者“cannot execute binary file”。哪怕装个Docker，也会栽在源不对、架构不匹配这些坑上。这篇文章我想把ARM架构（aarch64）操作系统上做项目部署这件事，从头到尾做一次资源整合和实战梳理，覆盖操作系统选型、软件源配置、Docker与SpringBoot项目落地、内存与性能优化、常用工具链适配，以及最后的验证清单。都是我在真实部署中踩过、填过、验证过的内容，按这条链路走，能帮你省下大量试错时间。

1. 为什么aarch64部署总在“最后一步”翻车：先看两个高频报错

先说个真实场景。同事把一套基于SpringBoot的后端服务打包成jar，在本地Windows的x86环境下测得好好的，部署到一台aarch64架构的服务器上，执行java -jar app.jar，报错内容是：

Exception in thread "main" java.lang.UnsatisfiedLinkError: /path/to/libnative.so: /path/to/libnative.so: cannot open shared object file: No such file or directory

跟进排查后确认，这个libnative.so是x86_64版本，在aarch64上根本无法加载。另一个经典报错来自Windows下尝试运行某个工具的时候：

程序“claude.exe”无法运行: 指定的可执行文件不是此操作系统平台的有效应用程序

这句话翻译过来就是：你手里拿的是x86或者别的架构编译的二进制，但当前系统架构是aarch64，操作系统无法识别、无法加载、无法执行。这两种报错，本质上是同一个问题的两种表现——架构不匹配。

1.1 报错的本质：ABI层面的不兼容

aarch64和x86_64之间的差异，不只是一个“位数”问题，而是整套ABI（应用二进制接口）层面的不兼容。包括：

• 指令集完全不同：x86_64是CISC（复杂指令集），aarch64是RISC（精简指令集），二进制文件里的机器码互相无法解析；
• 系统调用号不同：即使是最基础的read、write、mmap，在x86_64和aarch64内核里的编号都不一样；
• 动态链接器路径不同：aarch64 Linux下的动态链接器通常是/lib/ld-linux-aarch64.so.1，x86_64下是/lib64/ld-linux-x86-64.so.2，加载器都找不到，后面的动态库更无从谈起。

所以部署前的第一件事，永远不是急着敲命令，而是先确认目标机器的架构。

1.2 快速确认目标环境架构的几条命令

# 查看内核架构 uname -m # 输出 aarch64，就是ARM 64位架构 # 查看操作系统发行版信息 cat /etc/os-release # 查看CPU型号信息 lscpu | grep Architecture # 或者直接看完整信息 lscpu

部署镜像、安装包、二进制工具之前，先跑这三条命令。架构确认成aarch64，后面所有资源的选择都围绕这个核心展开。

2. 操作系统层：麒麟、openEuler与Ubuntu的选型与软件源配置清单

ARM服务器上可用的操作系统其实不少。常见的有：麒麟（Kylin）V10、openEuler（欧拉）、Ubuntu Server（aarch64版）、Debian（arm64版）、CentOS Stream（aarch64版）、Alpine Linux等。不同场景下选型逻辑不一样，这里给出一张我实际部署时常用的对比表。

2.1 麒麟V10更换yum源：最容易被忽略的架构匹配问题

麒麟V10系统默认的yum源里，很多包是x86_64架构的。直接在aarch64机器上执行yum install docker，很可能会报错“No match for argument”或者下载后安装失败。这时要手动更换为aarch64对应的软件源。

我实际使用过的一种稳定做法，是配置华为云或阿里云的麒麟V10 aarch64源。以华为云镜像源为例：

# 备份原repo文件 mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ # 新建麒麟V10 aarch64专用repo（以Kylin V10 SP1为例） cat > /etc/yum.repos.d/kylin_aarch64.repo << 'EOF' [ks10-adv-os] name=Kylin Linux Advanced Server 10 - Os baseurl=https://mirrors.huaweicloud.com/kylin/KylinV10SP1/aarch64/ gpgcheck=0 enabled=1 [ks10-adv-updates] name=Kylin Linux Advanced Server 10 - Updates baseurl=https://mirrors.huaweicloud.com/kylin/KylinV10SP1/aarch64/updates/ gpgcheck=0 enabled=1 EOF # 清理并重建缓存 yum clean all yum makecache

这里需要注意，不同版本麒麟V10的repo路径不一样，SP1、SP2、SP3各有独立目录，保险做法是先打开镜像站目录页确认实际路径。另外，gpgcheck=0在公网环境可以接受，内网或安全要求高时建议导入官方GPG密钥再开启校验。

2.2 openEuler安装后必做的NFS配置：一个真实的部署案例

openEuler在ARM服务器上表现不错，但它默认不启用NFS相关服务。一次部署中，我需要让三台aarch64节点挂载同一台NFS存储服务器。操作链路如下：

# 在openEuler节点上安装NFS客户端工具 dnf install -y nfs-utils # 启动相关服务 systemctl enable rpcbind systemctl enable nfs-client.target systemctl start rpcbind # 挂载远程NFS目录 mount -t nfs -o vers=4.0 192.168.10.20:/data/nfs /mnt/nfs

最坑的地方在于，openEuler默认防火墙是启用的，即使NFS服务端配置正确，客户端也经常挂载超时。排查命令：

# 查看防火墙状态 systemctl status firewalld # 临时放行NFS相关端口 firewall-cmd --add-service=nfs --permanent firewall-cmd --add-service=rpc-bind --permanent firewall-cmd --add-service=mountd --permanent firewall-cmd --reload

NFS挂载成功后，建议在/etc/fstab中追加自动挂载配置，否则重启后还得手动执行一次。

2.3 Ubuntu aarch64换清华源：注意是ports而非ubuntu目录

很多同事在Ubuntu aarch64上换源时，直接把x86那套清华源配置粘贴过来，然后apt update报404。原因很简单：x86_64的Ubuntu软件包在/ubuntu/目录下，而ARM64架构的包在/ubuntu-ports/目录下，二者路径体系不同。

修改/etc/apt/sources.list（以Ubuntu 22.04为例）：

# 备份原配置 cp /etc/apt/sources.list /etc/apt/sources.list.bak # 写入清华ubuntu-ports源 cat > /etc/apt/sources.list << 'EOF' deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ jammy main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ jammy-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ jammy-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu-ports/ jammy-security main restricted universe multiverse EOF # 更新索引 apt update apt upgrade -y

这里有个细节：如果安装的是Ubuntu Server官方aarch64版本，系统里可能还带了一个/etc/apt/sources.list.d/ubuntu.sources，新版本Ubuntu（22.04之后）默认使用deb822格式，直接改sources.list可能不生效，需要同步修改或者删除该文件。

3. 容器化主线：从Docker安装到SpringBoot镜像的多架构构建

在aarch64上部署项目，最省心的方案就是容器化。Docker镜像天然携带架构信息，只要选对架构标签，就能避免大量环境依赖问题。但Docker本身在ARM系统上的安装，也是一个容易踩坑的环节。

3.1 麒麟V10安装Docker：优先用二进制包而非yum源

麒麟V10的yum源里虽然有docker，但版本通常比较旧，而且依赖关系在aarch64上经常解析失败。我自己试过多次，最稳定的安装方式是直接使用官方Docker二进制包。

# 进入下载目录 cd /opt # 下载aarch64版docker二进制包 wget https://download.docker.com/linux/static/stable/aarch64/docker-24.0.7.tgz # 解压并安装到/usr/bin tar -zxvf docker-24.0.7.tgz cp docker/* /usr/bin/ # 创建systemd服务文件 cat > /etc/systemd/system/docker.service << 'EOF' [Unit] Description=Docker Daemon After=network-online.target [Service] Type=notify ExecStart=/usr/bin/dockerd ExecReload=/bin/kill -s HUP $MAINPID LimitNOFILE=1048576 LimitNPROC=infinity LimitCORE=infinity [Install] WantedBy=multi-user.target EOF # 启动并设置开机自启 systemctl daemon-reload systemctl enable docker systemctl start docker # 验证安装 docker info

docker info输出中需要重点检查一行：Architecture: aarch64。如果显示的是x86_64，说明dockerd本身运行异常，或者下载错了包。

3.2 Docker部署SpringBoot项目：从镜像构建到容器启动

SpringBoot项目在aarch64上部署，核心是把项目打成镜像。以常见的openjdk:17-jdk镜像和maven构建为例，这里给出一个在aarch64服务器上直接构建的Dockerfile：

# 第一阶段：构建 FROM maven:3.8-openjdk-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests # 第二阶段：运行 FROM openjdk:17-jdk-slim WORKDIR /app COPY --from=builder /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

构建命令：

docker build -t myapp:1.0 . # 运行容器 docker run -d --name myapp \ -p 8080:8080 \ --restart=always \ -e SPRING_PROFILES_ACTIVE=prod \ myapp:1.0

这里有一个很多人忽略的问题：基础镜像必须是aarch64版本。openjdk:17-jdk-slim官方镜像同时提供多架构，Docker在aarch64上执行docker pull时会自动拉取arm64变体，但如果你在Dockerfile里强制指定了平台，比如--platform=linux/amd64，那构建出来的镜像在aarch64上同样无法运行。

3.3 跨架构构建：用buildx构建同时适配x86和ARM的镜像

如果在开发机上想一次构建出多架构镜像，可以使用docker buildx。它的核心原理是：在x86主机上用QEMU模拟aarch64执行环境，让每个架构的构建过程在模拟器中跑一遍，最终生成带架构标签的多架构镜像。

# 启用buildx（新版Docker自带，无需单独安装） docker buildx version # 创建一个多架构构建器 docker buildx create --name multiarch --use # 构建并推送多架构镜像 docker buildx build \ --platform linux/amd64,linux/arm64 \ -t your-registry.com/myapp:1.0 \ --push .

执行完成后，在镜像仓库里可以看到myapp:1.0同时带linux/amd64和linux/arm64两个manifest。部署到aarch64服务器上执行docker pull时，Docker会自动选择arm64变体。

注意事项：

• --push是必须的，buildx默认不会把多架构镜像直接保存到本地镜像列表，不加--push本地只能看到构建结果缓存；
• 构建器第一次执行跨架构构建时，需要下载对应的QEMU模拟组件，时间较长；
• 某些原生扩展库（比如JNI）在模拟环境下编译经常失败，这种情况建议直接在aarch64原生机器上跑构建。

4. 硬核性能向：内存管理链路与Neon指令集的落地优化

部署只是第一步，真正跑起来之后，性能优化才是大头。aarch64架构下的内存管理链路和x86有不少差异，理解这条链路，能帮你在排查内存问题、性能瓶颈时少走很多弯路。

4.1 从memblock到buddy：内存管理的必经之路

在Linux内核中，aarch64架构下物理内存管理分为几个层级：

我在分析一次aarch64服务器内存不足问题时，用/proc/meminfo和/proc/buddyinfo对照排查，定位到是某个驱动反复申请大块连续物理内存，把buddy的连续块耗尽了。这时通过调整内核参数vm.min_free_kbytes预留一部分紧急内存，问题得到缓解：

# 查看当前预留内存阈值 cat /proc/sys/vm/min_free_kbytes # 调整预留内存（单位KB，根据物理内存大小按比例设置） sysctl -w vm.min_free_kbytes=131072 echo 'vm.min_free_kbytes=131072' >> /etc/sysctl.conf

4.2 kmalloc和vmalloc怎么选：一张表说清楚

很多人在写内核模块或者驱动时，对选择kmalloc还是vmalloc纠结。我根据实际经验整理如下：

实际经验是：内核模块优先用kmalloc，迫不得已再上vmalloc。一次驱动适配中，我临时改用vmalloc分配了一块2MB内存存数据，性能下降了将近20%，后来改成kmalloc配合内存池，才恢复预期。

4.3 用NEON指令优化memcpy：一个可复现的案例

aarch64对多媒体和SIMD有原生支持，这就是NEON指令集。很多高性能场景下，可以用NEON向量指令替代逐字节拷贝，显著提升效率。以一个常见的memcpy优化为例：

#include <arm_neon.h> void memcpy_neon(uint8_t *dst, const uint8_t *src, size_t len) { size_t i = 0; // 一次处理16字节，用NEON的128位寄存器 for (; i + 16 <= len; i += 16) { uint8x16_t data = vld1q_u8(src + i); vst1q_u8(dst + i, data); } // 剩余不足16字节的部分用普通字节拷贝 for (; i < len; i++) { dst[i] = src[i]; } }

用vld1q_u8一次性从内存加载16字节到NEON寄存器，再用vst1q_u8写回目标地址，相比逐字节循环减少了大量指令发射次数。做基准测试时，数据量在1KB以上时，NEON版本比逐字节memcpy快了约2-3倍（不同CPU主频和内存带宽下表现有差异）。

更进一步的优化，还可以同时用两个NEON寄存器做双发射，把拷贝吞吐再压一档：

void memcpy_neon_unrolled(uint8_t *dst, const uint8_t *src, size_t len) { size_t i = 0; for (; i + 32 <= len; i += 32) { uint8x16_t data0 = vld1q_u8(src + i); uint8x16_t data1 = vld1q_u8(src + i + 16); vst1q_u8(dst + i, data0); vst1q_u8(dst + i + 16, data1); } for (; i + 16 <= len; i += 16) { uint8x16_t data = vld1q_u8(src + i); vst1q_u8(dst + i, data); } for (; i < len; i++) { dst[i] = src[i]; } }

编译时记得加-march=armv8-a+simd或者直接默认开启NEON的选项，否则编译器可能不会生成NEON指令。实际项目中，如果需要处理大数据块拷贝，比如网络包转发、图像缓冲区复制，这类优化非常实用。

5. 工具链适配：Kettle、宝塔、Jenkins与前后端分离项目的ARM落地方案

除了项目和操作系统本身，部署中最耗时间的其实是各种周边工具的适配。这里挑几个高频场景详细说。

5.1 Kettle（Pentaho Data Integration）在aarch64上的报错与修复

Kettle（data-integration）是常用的ETL工具，但它对aarch64的支持比较差。直接执行./pan.sh经常会报：

I'm sorry, this linux platform [aarch64] is not supported

这个错误来自Kettle启动脚本里的平台检测逻辑，它在检测到非x86架构时直接拒绝运行。解决办法有两个方向。

方向一：修改启动脚本，强制跳过平台检测。找到pan.sh（或spoon.sh）中类似下面的内容：

if [ "$MODERN" = "true" ]; then ... fi

不同版本脚本结构不同，但基本思路是找到包含uname -m或者platform关键字的那段判断，把对应的exit 1注释掉。这种方式能启动，但后续如果Kettle依赖了x86原生的JNI库，仍然会崩溃。

方向二：换用纯Java驱动的方式。Kettle本身是Java写的，核心引擎并不依赖平台特定代码，报错只是启动脚本的“自以为是”。安装对应版本的JDK（需要aarch64版），然后直接通过Java命令启动Kettle核心类，绕过启动脚本：

# 先确认Kettle lib目录下有所有依赖 cd># 安装Node.js 18 LTS（宝塔软件商店里直接装即可） # 确认node是aarch64版本 node -p "process.arch" # 输出 arm64 即正常 # 全局安装pnpm npm install -g pnpm # 克隆项目代码 git clone https://github.com/your-repo/nestjs-app.git cd nestjs-app # 安装依赖 pnpm install # 构建生产包 pnpm run build # 启动（建议用pm2守护） npm install -g pm2 pm2 start dist/main.js --name nestjs-app pm2 save pm2 startup

注意几个细节：

• 如果node -p "process.arch"输出的是x64，说明你装错Node版本了，去宝塔软件商店换装ARM版；
• NestJS项目里依赖的原生模块（比如bcrypt、sharp）在aarch64上需要重新编译。如果pnpm install时报错找不到预编译二进制，先安装build-essential再执行npm rebuild；
• 部署后用pm2 logs检查启动日志，重点看是否有“invalid ELF header”之类的报错，这是原生模块架构不匹配的典型信号。

用宝塔部署前后端分离项目时，前端静态文件直接放Nginx站点目录，后端API走pm2守护的Node进程，Nginx里配置代理转发：

server { listen 80; server_name your-domain.com; # 前端静态文件 root /www/wwwroot/frontend/dist; index index.html; # API反向代理 location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

5.3 Jenkins自动部署Gitee项目：aarch64服务器上的流水线配置

Jenkins在aarch64上运行没问题，本身是Java应用。但需要注意两个点：一是Jenkins的插件生态里，少部分插件附带了原生二进制，可能没有aarch64版本；二是构建时用到的工具链（Maven、JDK、Node）都必须是arm64版本。

在Jenkins里配置Gitee项目的自动部署，我的通用流程是：

1. Gitee仓库配置WebHook，指向http://jenkins-server:8080/gitee-webhook/；
2. Jenkins安装Gitee插件，在任务配置里填入仓库地址、分支、账号凭据；
3. 构建触发器勾选“Gitee webhook触发构建”；
4. 构建步骤里执行Shell脚本，完成拉代码、编译、打镜像、推送、SSH远程部署：

#!/bin/bash # 构建SpringBoot项目 mvn clean package -DskipTests # 构建Docker镜像 docker build -t your-registry.com/myapp:${GIT_COMMIT} . # 推送镜像到私有仓库 docker push your-registry.com/myapp:${GIT_COMMIT} # SSH到目标服务器，拉镜像并重启容器 ssh deploy@target-server "docker pull your-registry.com/myapp:${GIT_COMMIT} && \ docker stop myapp || true && \ docker rm myapp || true && \ docker run -d --name myapp -p 8080:8080 your-registry.com/myapp:${GIT_COMMIT}"

这里有一个比较重要的经验：不要在Jenkins机器上直接保存镜像，而是统一推到私有镜像仓库，目标服务器再从仓库拉取。这样Jenkins服务器和目标服务器即使不是同一架构，也能分别拉取到对应架构的镜像。

6. 部署验证清单与常见坑位速查

项目部署完成只是开始，验证是否真正可用才是关键。下面是一套我在每次aarch64项目部署后都会过的验证清单。

6.1 基础环境验证

# 1. 确认系统架构 uname -m # 期望输出：aarch64 # 2. 确认Java版本与架构 java -version # 3. 确认Docker架构 docker info | grep Architecture # 期望输出：aarch64 # 4. 确认关键服务状态 systemctl status docker systemctl status nginx pm2 status

6.2 网络与端口验证

# 监听端口检查 ss -tlnp | grep 8080 # 从外部访问测试 curl -I http://target-server-ip:8080 # 如果访问不通，优先排查防火墙 firewall-cmd --list-all

6.3 性能与稳定性快速验证

# CPU信息确认 lscpu # 内存信息确认 free -h # 压测（如果有wrk或ab） ab -n 10000 -c 100 http://target-server-ip:8080/api/health

6.4 高频坑位速查表

6.5 一个容易被忽略的细节：glibc与musl libc

在aarch64上部署时，经常遇到静态编译的二进制在一个系统能跑，换一个系统就报错。这往往不是架构问题，而是C标准库实现不同。Ubuntu/Debian/麒麟/openEuler用的是glibc，Alpine Linux用的是musl libc。同一个aarch64二进制，在Ubuntu上编译的，放到Alpine容器里经常会提示找不到/lib/ld-linux-aarch64.so.1。

解决方案：

• 尽量用官方提供的多架构镜像，而不是自己在Apline里编译；
• 需要移植二进制时，优先选择glibc系系统作为运行环境；
• 用file 二进制名可以快速查看二进制依赖的动态链接器，比如输出dynamically linked, interpreter /lib/ld-linux-aarch64.so.1就说明是glibc环境。

7. 写在资源整合之后：我的一点实际体会

整理这份内容的过程中，我又从头回想了这几年在aarch64上部署项目的经历。最深的体会是：ARM架构本身并不比x86难用，难的是“惯性思维”。很多人踩坑，是因为默认把x86环境下的方案原样搬过来，忽略了源、二进制、镜像、工具链这些资源都需要重新适配。掌握了架构确认、软件源替换、镜像构建、工具链适配这条主线之后，aarch64就只是一个新的目标平台而已，不再是玄学问题。

最后分享一个小技巧：在部署目录里维护一份DEPLOY_NOTES.md，把每次遇到的架构坑和解决方案记录下来，格式就按本文的坑位速查表那样。下次换一台新机器，先看笔记再动手，能省掉一大半排查时间。

本文还有配套的精品资源，点击获取