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 的經驗，為企業如何在大規模範圍內應對架構異構性提供了寶貴的見解。