过去十余年,云端通用算力的默认答案几乎只有 x86。如今这一惯性正在被打断:随着自研与第三方 Arm 服务器芯片在超大规模数据中心的部署规模扩大,Arm 实例从“便宜一点的替代品”逐渐变成许多工作负载的默认选项。AWS 的 Graviton 已迭代至第四代,Google 推出基于 Arm 的 Axion,微软也发布了 Cobalt 系列,一批以能效为核心卖点的芯片把 Arm 推到了云算力清单的前排。
为什么是能效与单位成本
云厂商集体押注 Arm,最直接的动因是能效。数据中心电力与散热成本持续上升,在同样的机架功率预算下,Arm 架构通常能提供更多核心数与更高的每瓦性能。对于横向扩展型的 Web 服务、容器化微服务、缓存与网关类负载,单核绝对性能往往不是瓶颈,核心密度与功耗反而更关键。
对用户而言,收益最先体现在账单上。多数云厂商的 Arm 实例定价低于同规格 x86 实例,叠加更高的并发密度,单位请求成本仍有下降空间。AWS 曾披露 Graviton 已占据其新增 CPU 容量的相当比例,这类自研芯片也帮助云厂商降低了对单一供应商的依赖。
生态短板正在补齐
Arm 上云的早期阻力主要来自软件,如今情况变化很快:
- 操作系统与容器:主流 Linux 发行版、Kubernetes 及多数基础镜像均已提供 arm64 版本;
- 语言运行时:Go、Java、Python、Node.js 等对 arm64 的支持进入成熟阶段,主流 JDK 对 Arm 的优化持续叠加;
- 数据与中间件:主流数据库、消息队列、可观测性组件陆续提供官方 Arm 构建;
- 构建工具链:Docker Buildx 等工具让多架构镜像的构建与发布成为常规流程。
对多数云原生应用来说,能否在 Arm 上跑通,已不再取决于操作系统或语言运行时,而更多取决于业务代码里那些自定义依赖。
迁移不是换个实例类型那么简单
把已有系统搬到 Arm,仍需要实打实的工程投入。首先是依赖可获得性,部分商业软件、老旧 SDK 或私有编译的二进制没有 arm64 版本;其次是性能画像会变,原本针对 x86 调优的线程池、GC 参数与向量化代码需要重新评估;此外,在多云异构环境下,调度系统要能把负载放到正确的架构上,镜像清单、节点标签与容量规划都要同步调整。
较稳妥的路径是先易后难:从无状态、依赖简单的服务切入,在持续集成中默认产出多架构镜像,用真实流量做灰度对比,再逐步扩展到数据库、大数据等更重的组件。评测先行、逐步放量,比一次性整体切换风险更低。
云算力将长期保持异构
Arm 的上升并不意味着 x86 退场。对单核性能敏感、依赖特定指令集或成熟商业软件的负载,x86 仍会是首选;GPU、DPU 等专用芯片也在同一条能效曲线上推进。更可能的图景是:云上算力长期异构,选型依据从“历史习惯”转向“单位成本与能效的实测数据”。
对技术团队而言,当下值得做的,是把多架构构建与多架构评测变成默认能力。当架构本身成为一个可切换的变量,议价空间和优化空间都会随之变大。