Uber 的云旅程：在 x86 世界中拥抱 ARM

2023 年 2 月，Uber 开始从本地数据中心战略性地迁移到 Oracle 云基础设施（OCI）和 Google 云平台。此次迁移的一个关键环节是将基于 ARM 的计算机集成到以 x86 为主的集群中，以降低成本、提高性价比，并在供应链不稳定的情况下确保硬件灵活性。

x86 和 ARM 架构代表了处理器设计中的两种完全不同的理念，它们的区别奠定了数十年来的计算产业格局。x86 处理器通常为计算密集型任务提供更高的峰值性能，但消耗更多电量，这使得它们在电源插座随时可用的台式机和服务器领域占据主导地位；与此同时，ARM 处理器在能效方面表现出色，提供更好的每瓦性能比，使其成为移动设备、嵌入式系统以及日益注重功耗的数据中心的首选架构。

多架构集成面临的挑战不仅在于部署新的硬件。对于 Uber 的基础设施团队来说，这意味着重新看待多年来完全基于 x86 的基础系统。这一历程也显示出架构假设可以深度渗透到技术栈的每一层中。

此次转变的基础是 Oracle Cloud Infrastructure 对 Ampere Computing 的 ARM 处理器的战略性引入。这些芯片提供了卓越的能效——这是 ARM 在移动领域的最显著优势，现已扩展到数据中心环境。对于云提供商来说，这意味着大幅节省电力和提高计算密度，从而降低能源成本和物理占用空间要求。

对于 Uber 来说，这些优势与其可持续发展目标完美契合。随着公司努力实现零排放，采用节能计算基础设施是在减少环境影响的同时改善成本结构的重要一步。

整个转换过程从主机级的准备工作开始——创建包含操作系统、内核和基本基础设施组件的 ARM 兼容镜像。主机启动后，团队开始着手构建各种管道，找出了复杂的 Web 依赖关系。Uber 的容器系统依赖于 Makisu，这是一种针对 x86 优化的工具，无法针对 ARM 进行交叉编译。

为容器镜像构建管道

团队没有重写 5,000 多个服务构建流程，而是采用了一种巧妙的引导方法。他们利用 Google Bazel 构建了 Makisu 本身的 ARM 版本，然后就可以原生构建其他服务了。这个看似简单的任务暴露了一种循环依赖关系：Makisu 在 Buildkite 上运行，而 Buildkite 在 Uber 的 Odin 平台上运行，Odin 平台又依赖主机代理——所有这些都是用 Makisu 构建的。

打破这种循环依赖关系需要使用 Bazel 的多架构特性有条不紊地重建每一层。团队从主机代理开始，然后重建 Odin 的组件，接着是 Buildkite，最后是 Makisu。这个基础启用了分布式构建管道，可以生成统一的多架构容器镜像。

虽然这种方法使构建成本翻倍（每周有超过 400,000 个容器构建），但从经济角度来看，采用 ARM 仍然是有利可图的。分布式构建系统还提供了一个关键优势：它支持逐步、受控的迁移，而不是全有或全无的方法。

部署系统需要类似的增强。Uber 实施了针对架构的放置约束和自动回退机制，如果出现兼容性问题，这些机制将恢复到 x86。这些保护措施让团队可以逐步迁移服务，同时保持生产可靠性。

成功部署他们的第一批基于 ARM 的服务标志着一个技术里程碑，证明了多架构基础设施可以在 Uber 的规模下正常工作。然而，从最初的成功到迁移数千个服务的过程还需要额外的策略和工具。

随着云提供商扩展其处理器架构选项，Uber 和 Bitmovin 等组织展示了将各种计算架构整合到大型基础设施系统中的挑战和潜在好处。Bitmovin 将其编码服务完全迁移到 ARM 处理器的历程，以及 Uber 的经验，为企业如何在大规模范围内应对架构异构性提供了宝贵的见解。

原文链接：

Uber’s Cloud Journey: Embracing ARM in an x86 World(https://www.infoq.com/news/2025/02/uber-arm-cloud/)