異質雲端架構下的運算資源分配困境
在現代大規模基礎設施中，企業為了追求更佳的成本效益與運算彈性，普遍採用多世代硬體並存的異質架構。根據技術媒體 InfoQ 的報導，叫車巨頭 Uber 目前在其自主研發的 Odin 有狀態工作負載編排平台中，管理著橫跨自建資料中心與公有雲環境的約五百萬顆 CPU 核心。這些運算資源涵蓋了多代 x86 架構處理器以及新興的 ARM 架構伺服器。然而，當運算叢集的硬體世代跨度過大時，傳統以實體核心數量為單位的排程邏輯，便會面臨嚴峻的挑戰。
Uber 的工程團隊在實務監控中發現，其叢集中效能最快與最慢的 CPU 核心之間，單執行緒效能（single-threaded performance，指單一運算核心在處理循序指令時的運算速率）差距可達到將近兩倍。這意味著即使是完全相同的軟體邏輯與處理流程，在不同世代的硬體上執行時，所需的實體核心數量可能大相逕庭。若排程系統依舊將每一顆 CPU 核心視為等價的運算單元，將必然導致資源分配上的兩難局面。
若基礎設施團隊為了避免系統癱瘓，而一律以叢集內效能最慢的舊型硬體作為資源規格的劃分基準，那麼當應用程式被部署到最新型、處理速度最快的高效能機器時，就會有大量的運算潛能被閒置，造成昂貴硬體投資的嚴重浪費。反之，若系統以叢集的平均效能水準來預估與分配核心數量，一旦該工作負載被遷移或排程到處理能力較弱的老舊伺服器上，就會立刻面臨運算資源嚴重不足（under-provisioned）的窘境。這種因硬體異質性引發的效能波動，在大規模叢集中會演變成普遍的管理痛點。
有狀態工作負載的特殊挑戰與可靠性風險
對於無狀態服務（stateless services，指應用程式本體不儲存持久化用戶數據或狀態，任何節點皆可互換處理請求的架構）而言，硬體效能不均的衝擊相對容易被掩蓋。基礎設施通常能透過前端的負載平衡器（load balancer），依據各伺服器的即時負載狀況動態調整轉發流量，將較多請求導向運算速度快或負載低的機器，快速化解效能瓶頸。
然而，在有狀態工作負載（stateful workloads，指系統需要持久保存資料狀態且各節點扮演特定角色的架構，如分散式資料庫或訊息串流佇列）中，這種流量調度手段完全無法適用。在有狀態架構中，特定的用戶請求必須精準抵達持有該筆資料分片（shard，將龐大資料庫拆分成多個獨立子集的資料單元）的實體節點上，排程器無法隨意將資料存取請求重導至其他硬體。一旦該節點底層的 CPU 運算力追趕不上湧入的資料處理需求，便會引發嚴重的延遲累積與服務可靠性危機。
以 Uber 大量使用的分散式訊息串流平台 Apache Kafka 為例，叢集中的節點通常存在主從關係。Uber 揭露的數據顯示，在特定的生產環境負載下，負責協調寫入與同步的領導者節點（Leader），其消耗的 CPU 運算資源可能是跟隨者節點（Follower）的十倍以上。如果這個承載極重負載的領導節點原本運作在高效能伺服器上，隨後因硬體維護或節點重啟而被排程遷移到舊型慢速伺服器，其 CPU 消耗率就會出現劇烈攀升。儘管系統承載的外部業務流量完全沒有增加，底層架構卻可能因為硬體運算能力的落差而瞬間陷入資源耗盡的危機，甚至觸發服務中斷。
標準化運算單元 NCU 的運作機制與動態校準
為了解決這項矛盾，Uber 在 Odin 編排平台中導入了名為標準化運算單元（Normalized Compute Units, NCU）的全新抽象層，核心目標是將工作負載所需的實質運算能力，與底層所指派的實體核心數量徹底解耦。
在 NCU 架構下，排程系統不再直接分配固定數量的 CPU 核心，而是為不同型號的伺服器賦予特定的效能因子（Performance Factor）。Uber 以叢集內某一世代的老舊伺服器作為基準點，設定其效能因子為 100；而處理效能較強的現代硬體，其效能因子則會被評定為較高的數值，部分最新規格的伺服器甚至接近 190，代表其運算吞吐能力接近基準機器的 1.9 倍。
值得注意的是，這些效能因子並非單純仰賴理論規格或合成基準測試（synthetic benchmarks，透過特定演算法測試硬體極限效能的模擬程式）來決定。Uber 發現，不同的底層軟體架構對硬體指令集與記憶體子系統的反應截然不同。舉例來說，Kafka 在實際運作時，於 ARM 處理器、舊型自建機房 x86 系統與新型公有雲 x86 伺服器之間的效能表現，與通用基準測試呈現的數據有明顯偏差。因此，Odin 系統會在硬體驗證初期先給出初始效能權重，後續再透過真實生產環境的應用負載監控數據，持續回溯修正各伺服器型號的實際效能因子。
透過這套換算體系，Odin 能夠明確定義某一項有狀態服務需要多少標準化運算量。當系統決定將該服務部署在運算速度較快的新硬體時，系統便會折減並配置較少數量的實體核心；反之，若被調度至速度較慢的舊型機器，系統則會主動配置更多核心作為補償。這項設計並非追求各伺服器上的實體核心數完全一致，而是確保無論應用程式被放置在何種硬體環境，所獲得的實質運算承載能力都能維持均等與可預測。
落地成果與對雲原生資源抽象的架構啟示
Uber 目前已將這套效能感知調度機制推廣應用於 Odin 平台下約 140 萬顆具備自動擴展能力的 CPU 核心中，並在關鍵組件 Kafka 叢集上取得了顯著的效益改善。
在導入 NCU 之前，由於硬體效能差異未被排程系統納入考量，不同伺服器類型之間的 Kafka 節點 CPU 使用率存在高達 8 個百分點的系統性落差；負載最重硬體的平均使用率，甚至比負載最輕硬體高出約 50%。在全面實施效能感知調度後，各伺服器類型之間的使用率落差迅速收斂至約 3 個百分點，最熱硬體與最冷硬體的使用率差距縮小到僅約 10%，整體運算負載分布呈現出高度平準化的狀態。此外，透過更精準的效能對應，Uber 成功將 Kafka 整體配置的實體 CPU 數量削減了約 8%，且這些節省主要集中在租賃成本或採購單價最高的新世代運算資源上，帶來了實質的營運成本效益。
這項架構實踐也為現代雲原生排程系統帶來了深層的架構啟示。在以 Kubernetes 為主流的雲原生生態系中，運算資源的宣告通常以核心數或千分之一核心（millicores）為度量衡。Kubernetes 的設計哲學是將 CPU 視為一種時間配額的絕對單位，刻意忽略底層硬體效能的個別差異，藉此換取跨平台工作負載定義的高度可攜性。
然而，Uber 的工程實踐表明，當基礎設施的規模擴展至數百萬核心，且混合了跨世代、跨架構的異質伺服器時，單純依賴抽象的時間配額已無法滿足嚴苛的有狀態架構穩定性需求。從單純關注單一機器能塞進多少工作負載，演進至主動探究每一單位資源配置究竟代表多少真實計算力，將是超大規模資料中心走向精細化營運與保障高可靠性的關鍵路徑。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。