迁 ARM 服务器卡住的地方不在算力：先把依赖清单拉出来逐项过一遍

迁移第一步就卡住，通常不是因为跑不动

迁 ARM 的第一步往往就卡住了——不是跑不动，是镜像拉起来直接报格式不对。ARM 迁移的门槛基本都在依赖链上，算力反而很少是问题。

现场长这样：ARM 机器到手，操作系统装好，容器运行时装好，docker pull 一个跑了三年的内部服务镜像，pull 成功，run 起来一行 exec format error，然后就没有然后了。命令没错，权限没错，仓库地址没错——错的是这个镜像里那个 ELF 二进制是 x86_64 指令集的，内核在 execve 阶段就把它拒了。这是一道"能不能启动"的门槛，跟"跑得快不快"差着几个数量级的严重程度。

不少团队把顺序搞反了：先挑机型、先做一轮性能对比、先算能省多少钱，最后才发现监控 agent 只有 x86 版本，或者某个核心服务依赖的闭源 SDK 根本没有 ARM 构建。机器已经下单、预算已经批了，这时候再掉头，返工成本远大于省下来的那点钱。

正确的顺序是反过来的：先把依赖清单拉出来，逐项确认能不能过，过完了再谈机型、谈性能、谈成本。依赖清单干净，迁移就是体力活；清单里藏着两三个硬钉子，这件事可能压根就不该启动。

假设一个典型的中台集群：三四十个服务，Java 和 Go 混着，两个 Python 数据处理服务，一个 Node 网关，外加商业监控 agent、主机安全 agent、APM 探针、一套自建日志链路，数据库用的是商业发行版。以下为典型部署思路，并非特指某一真实客户。这么一堆东西，最后真正卡住迁移的通常不超过五个点，但每一个都能让整个计划停摆。

下面按"卡点出现频率 × 卡住之后的解数"排一遍序。经验上，能迁的那部分高度重合：无状态、横向扩展、轻量高并发的服务，迁移收益最明显；有状态、单请求重、绑死在闭源组件上的那部分，几乎必然留下来。

第一道卡：容器镜像有没有多架构构建

为什么单架构镜像在另一种指令集上跑不起来？因为容器不是虚拟机，它不做指令翻译。容器里的进程就是宿主机内核上的一个普通进程，内核按 ELF 头里的 machine 字段装载执行，指令集对不上就直接在装载阶段失败。所以"镜像能不能跑"只取决于镜像里所有二进制的指令集，跟宿主机有多少核、主频多高毫无关系。

多架构镜像（manifest list，OCI 规范里叫 image index）解决的就是这件事：一个 tag 下面不再是单个镜像，而是一份索引，索引按 platform（os + architecture + variant，例如 linux/arm64/v8）列出若干条 manifest，每条 manifest 指向各自架构的 layer 集合与 config。客户端 pull 时带上自己的平台信息，仓库返回匹配的那一条。上层看还是同一个 registry/app:1.2.3，底下其实是两套甚至三套 layer，digest 各不相同。

拉取之前怎么确认？几个层次，从浅到深：

• 查索引：docker buildx imagetools inspect <镜像> 会直接列出这个 tag 支持的 platforms 列表；老一些的 docker manifest inspect 也能看。私有仓库记得带认证，部分仓库需要 --raw 才返回完整 index 而不是被折叠的单个 manifest。
• 查 config：镜像 config 里的 architecture / variant 字段写死了这一个镜像的架构。如果拿回来的不是 index 而是单条 manifest，那它就是单架构镜像，不用再查了。
• 工具族：skopeo inspect --raw、crane manifest、oras manifest fetch 都能把这份索引取出来解析，适合塞进 CI 里做批量检查，输出成 JSON 再统计。
• 批量扫一遍：把集群里所有在跑的镜像列出来，逐个查 platforms，输出成表，标出哪些只有 amd64。这个动作半天就能做完，是整个迁移评估里性价比最高的一步。
• 最后一关是真机冒烟：manifest 说支持不代表里面的二进制都干净。Dockerfile 里 curl 下一个 release 包、COPY 进去一个预编译工具、安装脚本里写死 x86_64 判断，都可能埋雷。在 ARM 机器上真跑一遍启动加健康检查，才是收尾动作。

还有个常被忽略的上游问题：父镜像。你自己的服务是解释型语言写的，怎么 build 都能出 arm64，但 FROM 的基础镜像只有 amd64，整条链就断了。排查顺序应该是先查 base image，再查中间层，最后查应用产物——反过来查容易白费功夫。

确认完之后，产出物应该是一张表：镜像名 → 有没有 arm64 → 谁维护 → 没有的话能不能自己构建。有 Dockerfile、依赖全开源的，基本都能自己解决，用 buildx 指定 --platform linux/amd64,linux/arm64 一次构建并 push，索引会自动生成。要注意的是，多架构构建等于构建量翻倍，构建时长、缓存占用、制品仓库容量都要预留，这一点在 CI 那一节展开讲。

第二道卡：闭源和商业组件有没有 ARM 版本

这一类最没商量余地。开源组件没有 ARM 版本，你还能自己编译；闭源组件没有 ARM 版本，你只有三条路：换掉它、绕开它、或者留一小批 x86 机器专门伺候它。

典型名单：主机监控 agent、主机安全与入侵检测 agent、APM 探针、商业中间件、商业数据库企业版、商业备份客户端、某些负载均衡或 WAF 的旁路组件、硬件厂商自带的管理工具。它们的共同特征很好认——官网下载页只有 x86_64 的 rpm/deb，容器形态只有 amd64 tag，release notes 里从头到尾没出现过 arm64 或 aarch64 字样。

商业数据库要单独拿出来说。有些厂商确实提供 ARM 版本，但会限定操作系统版本、限定运行平台（只支持某几家云或者某个 OS 大版本），而且授权条款可能按物理核心或 socket 计价，换架构意味着 license 要重新谈。"有 ARM 版"和"你手上这份 license 允许你在 ARM 上跑"是两件事，签合同之前都要落到白纸黑字上。

卡住之后的出路，大致四条：

• 换同类产品。前提是替代品本身有 arm64 构建，别换完发现还是一样，白折腾一轮 POC。
• 保留一小批 x86 节点专门跑这些组件。监控采集类 agent 通常只要能采集、能上报就行，它部署在哪台机器上不是关键，这类最好绕，代价最小。
• 外置成独立服务。把采集、代理、转换这类能力拆出去放在 x86 节点上，ARM 侧通过接口调用，等于把不可迁移的部分隔离成一个远程依赖。
• 让厂商给明确时间点。给不出版本号和大致日期的，一律按"没有"处理，别把整个迁移计划押在一个口头承诺上。

这类组件在依赖清单里数量通常只有个位数，但杀伤力最大。服务全都迁完了、唯独 agent 装不上、agent 不上线就不给上线的剧情，在行业里并不少见。所以这一项必须和镜像检查同步启动，甚至排在它前面——它有可能直接否决整件事，早知道一周就能省下一轮预算评审。

第三道卡：原生扩展和预编译的 .so，有源码和没源码是两回事

这一道的判断标准极其简单：有源码就能重编，没源码就只能放弃或找替代。中间没有模糊地带，也没有什么神奇配置能绕过。

按语言栈拆开看：

JNI 本地库。Java 应用本身是跨平台的，字节码在 ARM 的 JVM 上照跑，但 JNI 加载的 .so 不是。这些库必须针对目标架构重新编译，而且往往同时绑死 JDK 版本和 glibc 版本——在 x86 上用 JDK 8 编出来的库，迁到 ARM 上如果 JDK 升到 17，等于要重编两次。老项目里那种十年前的 JNI 加密库，源码找不着的，就是典型死结。

Python 的 C 扩展。看 wheel 有没有 aarch64 的 manylinux 构建。主流的科学计算类库现在基本都发了 aarch64 wheel，装上就完事；麻烦的是小众包和内部自研包，pip 找不到对应 wheel 就会回退到源码构建，这时构建环境里缺一个 gcc、缺一个 python-dev、缺一个底层 C 库的头文件就直接失败。更麻烦的是把这种构建放进生产镜像里，镜像体积和构建时长都上去了。

Node 原生模块。node-gyp 现场编译需要完整的 toolchain；用 node-pre-gyp 提供预编译二进制的包，如果没有 arm64 的预编译产物，同样回退到源码编译，失败概率不低。老项目里那些只维护到几年前的原生模块，是最容易在这里翻车的。

Go 的 cgo 依赖。纯 Go 交叉编译非常顺，改 GOOS/GOARCH 就出产物；一旦开了 cgo，就需要目标架构的 C 交叉编译器和对应的库。工程上通常二选一：要么 CGO_ENABLED=0 静态编译（前提是不依赖必须走 cgo 的东西，比如某些 DNS 解析和系统库调用），要么直接用 arm64 的构建机原生编译，别去折腾交叉工具链。

预编译的 .so / .a。只有二进制、没有源码、没有厂商 ARM 版的，直接判死。要么找开源替代品重写这一块，要么把这部分功能拆成独立服务留在 x86 上，ARM 侧走 RPC 调它。为了一个 .so 把整个迁移搁置，不值得；但为了赶进度假装它不存在，上线就要出事。

验证手段不复杂：readelf -h 看 Machine 字段、file 命令看 ELF 类型、ldd 看动态库依赖链，镜像里再 find 一遍 *.so 全部过一遍。这一步能提前抓出九成问题，比等它在线上报一个莫名其妙的加载失败强得多。

第四道卡：构建与 CI 工具链，产物怎么出得来

就算所有依赖都有 ARM 版本，还有一个前置问题：你的 ARM 产物是怎么生产出来的。很多团队的 CI 跑在清一色的 x86 runner 上，从来没出过第二种架构的产物，这一关得从头搭。

三条路线，各有适用场景：

• QEMU 模拟（binfmt_misc + qemu-user-static）：在 x86 机器上注册 ARM 的二进制处理程序，构建时由 QEMU 翻译执行。好处是不用加机器，坏处是慢，编译型语言的构建时长会显著拉长，跑测试也一样慢。适合镜像小、构建步骤少的脚本类服务，或者用来做过渡验证。
• 原生 arm64 builder：直接准备 ARM 架构的构建节点，速度最快，行为也最接近生产环境。推荐路线，尤其是编译型语言。要注意 runner 池得按架构打标签，流水线里显式指定跑哪一类 runner。
• 交叉编译：在 x86 上直接出 ARM 二进制，再各自打包成镜像。省时间，但工具链和 sysroot 要自己维护，升级时的琐碎事不少，适合 Go、Rust 这类交叉编译友好的栈。

多架构镜像怎么合？两种做法：一是 buildx 一把梭，docker buildx build --platform linux/amd64,linux/arm64 --push，构建完自动创建并推送 manifest list；二是先分别打两个带架构后缀的 tag 推上去，再用 docker manifest create / annotate / push 手动合并。前者省事，后者在需要给不同架构配不同构建参数时更灵活。

几个容易踩的坑，列出来省得回头查：

• 制品仓库要支持 manifest list。老版本的镜像仓库对 OCI index 的支持不完整，推送成功但拉取时取不到正确架构，升级仓库版本这件事要提前排期。
• 非容器产物按架构分目录。jar、wheel、deb、静态二进制，别混在同一个路径下，否则部署脚本取错文件还查不出来。
• 缓存体积翻倍。多架构构建各自有独立的 layer cache 和依赖缓存，CI 的缓存存储要预留，不然会出现"缓存被挤掉导致每次全量构建"的隐形拖累。
• 标签策略要覆盖全。只在 latest 上做多架构是远远不够的，版本 tag 同样要做。否则某次回滚拉到一个单架构的旧 tag，故障现场会非常难看。
• 测试本身也要能在 ARM 上跑。单测依赖的浏览器驱动、测试用数据库容器、mock 服务，全都要有 arm64 版本。这一项经常被漏掉，等到流水线卡在测试阶段才发现。

一句话总结这一道：CI 的产出能力决定了迁移能不能持续。手工在 ARM 机器上 build 一次不难，难的是把它变成一条稳定、可重复、能回滚的流水线。

第五道卡：第三方 SDK、驱动和硬件加速依赖

前四道卡完，剩下的通常是些零散但致命的东西——厂商提供的二进制 SDK、硬件驱动、依赖特定指令集的加速库。

厂商二进制 SDK是重灾区：只给一个 .so 且只有 x86_64 构建的，硬件加密狗与证书类 SDK、部分支付与身份认证 SDK、早年版本的图像处理与 OCR SDK，都属于这一类。它们的特点是业务上不可替换，技术上不可重编，卡住就是卡死。判断方法很直接——找厂商要 release notes，搜 arm64 / aarch64 字样；要不到文档就直接在 ARM 机器上做最小冒烟，跑一次初始化加一次真实调用，别只看销售口头说"支持"。

硬件加速依赖：加解密、视频编解码这类负载，往往会走专用指令或专用硬件单元。OpenSSL 在 ARM 平台上有对应的加速路径，问题不大；但厂商 SDK 里如果内嵌了针对 x86 指令集手写优化的实现，就必须找厂商要 ARM 版，或者退回到通用实现（性能会掉，需要重新评估容量）。

驱动层：加密卡、采集卡、特定网卡的 offload 功能，需要对应的内核模块，且内核版本要对得上；用户态的 DPDK、RDMA 类驱动也要确认有没有 arm64 的发布。这一项在有特殊硬件的场景里往往是决定性的——没有驱动，机器等于少了一块关键部件。

兜底思路和闭源组件一样：把这类能力做成独立服务留在 x86 节点上，ARM 侧通过网络调用。代价是多一跳网络开销和一份额外的运维负担，但至少不阻塞迁移。

把前五道卡压成一张检查表，逐项打勾，是我在架构评估时最先要求交付的东西：

性能层面别急着比：先分清你的负载是"并发高单请求轻"还是"单请求重"

依赖清单过完之前，任何性能讨论都是空转。过完之后，第一件事也不是跑对比，而是把你自己的负载形状摸清楚。

分两类看：一类是"并发高、单请求轻"——API 网关、鉴权、消息转发、Web 渲染、轻量微服务，每个请求消耗的 CPU 时间不多，吞吐靠核数堆。另一类是"单请求重"——大批量数据处理、复杂报表生成、单线程的计算密集任务，单个请求就要吃掉一整核好几秒。前者和 ARM 平台常见的高核心密度是匹配的，后者则完全相反。

适合迁的典型负载：

• 高并发、单请求轻的无状态服务。网关、鉴权、配置中心、消息转发、日志采集与转发，这类服务本来就是靠横向扩展顶吞吐，核心数多就是实打实的收益。
• 可水平扩展、没有本地状态的服务。实例随便加减，迁起来也容易回滚，试错成本最低。
• 编解码类负载，前提是目标平台有对应的专用指令或硬件加速单元，并且你的代码路径真的能走到它。如果之前的实现里写死了 x86 的 intrinsics，得先改代码再谈迁移。

不适合迁的典型负载：

• 单线程重任务。加核帮不上忙，单核能力是硬约束，这类负载迁过去大概率变慢。
• 依赖 x86 特定指令集扩展的科学计算与向量化代码。比如重写了 AVX-512 intrinsics 的矩阵运算、某些手写汇编的加密与压缩实现，要么重写，要么别动。
• 强依赖大内存单机、靠纵向扩展的有状态服务。大内存实例在 ARM 平台上的可选档位通常没那么丰富，且单机故障的爆炸半径更大。

还有个容易被忽略的点：GC 行为。堆大、单线程停顿敏感的 JVM 服务，对单核性能和内存带宽都敏感，迁移前最好先在 ARM 上用真实流量灰度观察一段时间停顿分布，而不是只看平均响应时间——平均值会把长尾停顿藏得很好。线程数、连接池、GC 线程数这些参数往往是照着 x86 机器的核数调的，核数一变就得重新调一遍，别直接复制配置。

核心密度、内存带宽与 IO 扩展，这几项怎么影响你的机型选择

ARM 服务器平台常见的形态是核心数更多、单核性能与 x86 高端型号存在差距。这不是缺点也不是优点，它只说明一件事："并发高、单请求轻"划算，"单请求重、靠单核"不划算。选型时把这个结论套到自己的负载上，比看任何排行榜都管用。

核心密度带来的第二个问题是内存带宽。核数上去了，每核能分到的内存带宽不一定跟着线性增长，内存密集型的负载（大缓存、大堆、频繁随机访问）要特别留意这一点。落地做法是按内存通道数去估算每核带宽，再结合自己业务的访存强度判断够不够，最后用真实流量灰度验证，而不是靠纸面参数下结论。

NUMA 拓扑也要看。部分 ARM 平台的多芯片封装方式会带来更多的 NUMA 节点，进程跨节点访问内存的代价不小。对延迟敏感的服务，建议把实例绑在单个 NUMA 节点内、控制单个实例的内存 footprint 不要跨节点，或者直接在 BIOS 与内核层面把 NUMA 均衡策略调好。

IO 扩展能力是第三项。PCIe 通道数决定了你能插多少块 NVMe、能上几张网卡、能不能加装加速卡，而且通道的拓扑分配（哪个槽位直连 CPU、哪个走的桥片）会影响实际带宽。存储密集型的服务不能只看"能插几块盘"，得看通道总数和拓扑；高性能网络场景要确认网卡驱动有没有 arm64 版本、内核模块是否随发行版提供，走 DPDK 或 RDMA 的还要确认用户态驱动的架构支持。

从服务器架构选型的配置参考角度看，一万网络深耕 IDC 19 年（成立于 2007 年），做这类评估时的做法是先把手上 x86 档位的规格与价格摆出来当对照基线——比如裸金属 E5-2698v4×2 / 32G / 1T 这一档，官网月付 ¥3999 起（以官网实时价为准），用它去对比候选平台在核数、内存通道、盘位上的差异，才知道换架构到底换来了什么。ARM 机型目前官网没有列明明示档位，这部分只能按行业部署角度去评估、以咨询为准，不要拿一个不存在的报价去说服自己。一万网络在华南、华东、华北以及中国香港等节点都有资源，做混合架构试点时，先把一小批机器放在离现有集群最近的节点，网络与运维成本都更好控制。

容量换算也是选型时容易算错的一环。核数变了之后，单实例该部署多少副本、每个副本给多少 CPU limit，不能按核数比例线性折算——并发能力受内存带宽、锁竞争、外部依赖连接池的共同约束，简单按核数翻倍去砍副本数，很容易在高峰期把延迟打爆。稳妥做法是按单副本能扛多少并发这个口径重新定副本数，而不是按一台机器有多少核去反推。

还有一项经常被漏算：混合架构之后的长期运维成本。两套架构意味着两套基础镜像、两条构建流水线、两份依赖升级排期，还有排障时要先判断这是架构问题还是业务问题的额外心智负担。这笔账要算进总拥有成本里，别只盯着单台机器的费用差。

迁移顺序建议：先无状态后状态，先边缘后核心

顺序比技术细节更重要。顺序错了，一个可解的问题会变成一场事故。经验排序是这样的：

• 先无状态，后有状态。无状态服务迁错了一次，改个调度就能回来；有状态服务迁错一次，数据可能就回不去了。
• 先边缘，后核心。内部管理后台、静态资源、离线的日志处理，先拿它们练手，把流水线和运维手册跑熟。
• 先新业务，后老业务。新业务本来就要写新的 Dockerfile 和 CI，顺手做成多架构，边际成本几乎为零；老业务的依赖盘不清楚，放最后。
• 先读多写少，后写多。读路径出问题时影响面小，回滚也快。
• 先能一键回滚的，后不好回滚的。这一条应该是硬约束：不具备一键切回 x86 能力的服务，不进第一批。

比较合适的首批候选：内部管理后台、静态资源服务、API 网关、日志采集与转发、CI 构建机本身（反正要出 ARM 产物，先让构建机跑在 ARM 上，等于顺带验证了工具链）。不建议首批动：核心交易库、消息中间件、有本地磁盘状态的服务、依赖特定指令集的计算模块。

混合架构集群的调度，几个必须做对的动作：

• 架构标签：Kubernetes 的 kubelet 会自动上报 kubernetes.io/arch（arm64 / amd64），调度时靠 nodeSelector 或 nodeAffinity 显式指定。凡是只在一侧验证过的服务，都必须写死 nodeSelector，不要让它飘。
• 污点与容忍：给 ARM 节点池打上专属 taint，只有验证通过的服务才配 toleration。这样即使有人忘了写 nodeSelector，默认调度也不会把老服务扔到 ARM 上——这是防止误调度最有效的一道保险。
• 镜像 tag 策略：如果镜像本身是多架构 manifest，同一个 tag 调度到哪边都能跑；如果是架构专属镜像，建议用 -arm64 这类后缀区分，配合 nodeSelector 使用，避免拉错。
• 节点池分开扩：HPA 和集群扩容要按架构分池，别让 ARM 池被一个不可迁移的服务触发扩容，也别让 ARM 池的扩容影响到 x86 侧的容量规划。
• 监控告警加架构维度：指标、日志、链路追踪都要带上 arch 标签，否则线上报错时你根本分不清是哪一侧在出问题，排查时间会成倍拉长。
• 灰度节奏：先在 ARM 上放一个副本，观察错误率、延迟分布和资源水位，确认没有架构相关的异常，再逐步放大比例。放大过程中保留随时切回的能力。

最后说否决条件。出现下面任何一种情况，就别迁了，把精力放在别处：存在无法替换的闭源 x86 组件且厂商没有 ARM 计划；业务强依赖 x86 特定指令集扩展且代码不可重写；只有单机构型、无法水平扩展的老系统；依赖的硬件（加速卡、采集卡、特殊网卡）没有 arm64 驱动；团队没有能力维护两套架构的镜像与流水线。最后一条最容易被忽略——混合架构意味着长期的双份构建、双份测试、双份排障，运维负担是实打实的。

迁 ARM 之前要逐项确认的几件事

1. x86 上构建的容器镜像能不能直接在 ARM 机器上跑？

不能。容器不做指令翻译，镜像里的二进制是什么指令集就得跑在什么机器上，对不上就在启动阶段报 exec format error，跟性能无关。唯一的例外是镜像本身已经是多架构的 manifest list，同一个 tag 下既有 amd64 也有 arm64 的 layer，这时候 pull 会自动取到匹配的那一份，看起来就像"同一个镜像两边都能跑"。所以判断标准不是"这个镜像存不存在"，而是"这个 tag 下面有没有 arm64 这一条 manifest"。

2. 靠模拟层硬跑，代价有多大，适合什么场景？

QEMU 这类用户态模拟能把 x86 二进制翻译执行，功能上跑得起来，代价是性能损耗明显、部分系统调用和指令覆盖不全，稳定性也不适合长时间承载生产流量。它适合三类场景：CI 里做多架构构建（尤其是脚本类、解释型的小镜像）、迁移前的可行性验证、以及临时把某个没有 ARM 版的边角工具跑起来救急。拿它去跑核心业务是另一回事——那等于用一层翻译换掉了架构迁移本来的收益，不如直接留在 x86 上。

3. Java 应用迁到 ARM 要额外注意什么？

字节码本身没问题，注意三件事：一是 JNI 本地库要重编，且要和目标 JDK 版本、glibc 版本对齐；二是 JDK 发行版必须是 aarch64 构建，别把 x86 的 JDK 打进镜像；三是 GC 与线程相关的参数要重新调，堆大小、GC 线程数、连接池大小这些往往是照着 x86 机器的核数配的，核数变了不能照抄。JVM 在 ARM 上的默认参数与 x86 不完全一致，启动后要确认关键参数是否如预期生效。

4. 数据库这类有状态服务能不能一起迁？

技术上很多开源数据库都有 aarch64 构建，但"能跑"和"该一起迁"是两回事。有状态服务的迁移成本在数据不在算力：备份与恢复策略、主从复制的跨架构兼容性、故障切换演练、性能基线的重新建立，每一项都比无状态服务重得多。稳妥做法是数据库最后迁，且单独做一轮完整的故障演练；如果用的是商业发行版，还要先确认 license 允许在 ARM 上运行。核心交易库这类，除非有明确的收益测算和充分的演练窗口，否则留在 x86 上更省心。

5. 混合架构的集群，调度层面怎么保证不跑错？

三道保险：一是给 ARM 节点池打专属污点，只有验证通过的服务配 toleration，这样即使漏写调度约束，默认调度也不会把服务扔过去；二是凡是只在一侧验证过的服务，用 nodeSelector 或 nodeAffinity 显式绑定架构；三是镜像层面做区分，多架构 manifest 用同一个 tag，架构专属镜像用后缀区分，别混用。配套还要做两件事：节点池分开扩容，监控告警加架构维度。这五件事做完，误调度的概率才能压到可接受。

6. 什么情况下干脆不该考虑 ARM？

五个明确的否决条件：有无法替换的闭源 x86 组件且厂商给不出 ARM 版本计划；业务强依赖 x86 特定指令集扩展（如 AVX-512 一类的向量化实现）且代码不可重写；系统只有单机构型、无法水平扩展，迁移后反而放大了单机故障的爆炸半径；依赖的硬件没有 arm64 驱动；团队没有能力长期维护两套架构的镜像、流水线与排障流程。满足任意一条，把迁移计划往后放，先把依赖问题解决掉再说。

这些判断的出处

本文关于容器镜像多架构、manifest list 与 image index 的机制描述，依据 OCI Image Specification 与 Docker 官方 manifest 文档；镜像架构的验证命令（buildx imagetools inspect、skopeo、crane）来自各自工具的官方用法说明。调度层面的架构标签、污点与容忍机制，依据 Kubernetes 官方文档中关于 kubernetes.io/arch 标签与节点亲和性的说明。跨架构执行失败的机制描述，依据 Linux 内核对 ELF 文件 machine 字段的装载校验行为。

关于平台形态（核心密度、内存通道、PCIe 与 IO 扩展）的判断属于工程经验归纳，不同厂商、不同代际的平台差异很大，任何性能与容量结论都需要结合自己的业务负载，用真实流量灰度验证后再下结论，不要直接套用本文的定性判断去推算容量。

文中涉及的服务器档位与报价，均引自一万网络官网（https://www.idc10000.net/）公开页面，具体以签约时最新报价与合同为准；官网未列明的机型与配置，属于预估价格范畴，需以咨询为准。一万网络深耕 IDC 19 年（成立于 2007 年），可提供服务器架构选型层面的配置参考与上架、运维支持。