x86 到 ARM64 迁移：依赖检查、镜像构建和分阶段验证
x86 与 ARM64 使用不同指令集，现有镜像和二进制不能默认跨架构运行。Rainbond 可以在目标架构上构建源码、部署多架构镜像，并管理 x86_64 与 ARM64 节点或集群；业务依赖、闭源 SDK、数据库兼容和性能验证仍由应用团队负责。
最近更新时间：2026-10-25。
迁移前先做依赖盘点
逐个组件记录以下信息：
| 检查项 | 要确认的内容 |
|---|---|
| 基础镜像 | 镜像 manifest 是否包含 linux/arm64 |
| 编译产物 | Go、C/C++、Rust 等二进制是否需要重新构建 |
| 本地扩展 | Node.js、Python、Java JNI 等扩展是否提供 ARM64 版本 |
| 系统依赖 | apt/yum 包、字体、浏览器、驱动和动态链接库 |
| 闭源软件 | SDK、许可证服务和厂商中间件是否明确支持 ARM64 |
| 数据服务 | 数据库版本、驱动、备份和回切路径 |
没有源码且厂商不提供 ARM64 版本的组件，不能通过平台配置解决。平台识别节点架构，但不会把 x86 二进制自动转换为 ARM64 二进制。这类组件应继续运行在 x86 节点，或更换依赖后再迁移。
Rainbond 可以提供什么
在目标架构上构建源码
源码组件由目标集群中的构建节点完成构建。ARM64 集群需要可用的 ARM64 构建节点，依赖仓库和基础镜像也要支持该架构。平台会执行构建流程，但不会自动修改不兼容的业务代码和第三方依赖。
部署多架构镜像
同一镜像标签可以包含 amd64 和 arm64 manifest。Kubernetes 根据节点架构拉取相应镜像。迁移前可使用以下命令检查：
docker buildx imagetools inspect registry.example.com/team/app:v1.0.0
如果输出中没有 linux/arm64，需要重新构建镜像，或为 ARM64 使用单独的镜像标签。
管理混合节点或独立集群
多架构文档提供两种方式：
- 在同一 Kubernetes 集群中管理 x86_64 和 ARM64 节点。
- 分别接入 x86_64 与 ARM64 集群，通过团队和应用管理不同环境。
跨集群网络、数据同步和容灾不会自动完成，需要独立方案。
保留应用关系和版本
应用模型可以记录组件、依赖、配置和版本，便于在测试环境复现迁移后的拓扑。应用模板跨架构安装时，所有组件仍必须具备目标架构制品。
推荐迁移顺序
- 先选择一个依赖清晰、可以回切的非核心应用。
- 在 ARM64 环境验证 Rainbond、网络、存储和镜像仓库。
- 构建或准备 ARM64 镜像，检查每个组件的运行日志和健康检查。
- 验证接口、文件处理、字符集、时区和外部系统连接。
- 对相同请求和数据量做性能测试，不直接套用 x86 资源规格。
- 备份数据并演练回切，再安排生产流量迁移。
Rainbond 不能替代的工作
- 修改不兼容的业务代码或闭源二进制。
- 为缺少 ARM64 版本的系统包、驱动和 SDK 生成兼容版本。
- 自动完成数据库 schema、业务数据和跨集群网络迁移。
- 保证迁移后的性能与 x86 环境相同。
公开证据
多架构应用部署
核对源码构建、多架构镜像和依赖条件。
异构集群部署
查看 x86_64 和 ARM64 节点或集群的管理方式。
鲲鹏与飞腾适配记录
历史材料证明已有实践，但当前硬件和软件版本仍要重新验收。
常见问题
Java 应用是不是不需要适配？
Java 字节码本身可以跨架构，但 JDK、JNI、本地库、字体和外部命令仍可能依赖架构。需要在目标环境完整构建和测试。
多架构镜像会自动生成吗？
不会。应用团队需要在 CI 或构建环境中生成 amd64/arm64 镜像，或分别维护两个架构的镜像。
可以一次迁移所有组件吗？
技术上取决于依赖是否都支持 ARM64。实施时通常先迁移无状态、依赖清晰的组件，再处理数据库和外部设备相关服务。
平台能自动选择正确镜像吗？
镜像标签包含多架构 manifest 时，Kubernetes 会按节点架构拉取对应镜像。只有单架构 manifest 时，调度到错误架构会启动失败。
继续验证
先核对多架构文档，再选一套可回切的应用做测试。