突破 Kubernetes 的 CPU 抽象，Uber 为异构服务器重新定义“一核”

Uber 引入了 标准化计算单元（Normalized Compute Units，NCU） "，以便在高度异构的服务器集群中更一致地分配 CPU。这种方法已应用于 Uber 的有状态编排平台 Odin "，它会考虑处理器之间的性能差异，而不是将每个 CPU 核心都视为具有相同性能。 Odin 管理着约 500 万个 CPU 核心，分布在本地数据中心和公有云中，其中包括多个世代的 x86 硬件和 ARM 处理器。Uber 发现，最快与最慢 CPU 核心的单线程性能可能相差近一倍。因此，同一工作负载在不同服务器上运行时，所需的物理 CPU 核心数量可能存在显著差异。 这一问题带来了两种相互冲突的风险。如果按照最慢硬件的性能分配资源，就会浪费较快服务器上的计算能力；如果按照平均使用量分配资源，那么工作负载迁移到较慢服务器时，又可能出现资源不足。对于有状态工作负载而言，由于通常无法简单地将流量迁移到另一台机器，后一种情况可能演变为可靠性问题。 Uber 的解决方案，是将工作负载所需的计算性能与提供这些性能的物理 CPU 核心数量分离。 Odin 会为每种服务器类型分配一个性能系数，并将较老一代服务器的基准值设为 100。新硬件的数值可能高得多；Uber 表示，部分服务器的性能系数接近 190。这些系数最初在硬件准入测试期间确定，随后再根据生产工作负载数据进行调整。 系统会使用这些性能系数，将 CPU 使用量转换为标准化单位。这样，Odin 就可以确定某项工作负载需要多少计算能力，再根据承载该工作负载的服务器，将这一需求换算成不同数量的物理 CPU 核心。 因此，同一项工作负载在性能较快的硬件上可能获得较少的 CPU 核心，在性能较慢的硬件上则会获得更多核心。其目标不是让核心数量保持一致，而是让实际计算能力更加接近。 Uber 还发现，不同技术栈对应的性能系数也有所不同。例如，在 Kafka 测试中，ARM、较老的本地硬件和较新的 x86 系统之间存在显著的性能差异。因此，该公司会使用生产环境中的测量数据更新性能系数，而不是只依赖合成基准测试。 对于无状态服务，服务器之间的性能差异通常可以通过负载均衡解决。流量可以被引导至负载较低或速度更快的机器。 有状态系统则没有同样的灵活性。请求可能必须到达保存特定分片或数据的服务器，将请求转移到其他位置并不能解决底层资源问题。 Uber 在文章中介绍了一些工作负载，其中 Leader 消耗的 CPU 是 Follower 的十倍以上。如果 Leader 从一台高性能服务器迁移到较慢的服务器，即使工作负载本身没有变化，其 CPU 使用率也可能大幅上升，进而造成资源压力。 Uber 已将该方案应用于 Odin 自动扩缩容工作负载中的约 140 万个 CPU 核心。对于 Kafka "，不同服务器类型之间的 CPU 利用率最初相差约 8 个百分点，利用率最高的硬件比最低的硬件高出约 50%。 引入性能感知资源分配后，这一差距缩小至约 3 个百分点，利用率最高的硬件只比最低的高约 10%。Uber 还将 Kafka 的 CPU 总分配量减少了约 8%，其中大部分缩减发生在性能更快的硬件上，因此这些节省可能更有价值。 这种方法不同于 Kubernetes 使用的 CPU 抽象 "。在 Kubernetes 中，CPU 请求以核心或毫核表示。无论底层机器的规格如何，Kubernetes 都有意将一个 CPU 单位视为绝对数量的 CPU 时间。这种抽象很适合定义可移植的工作负载，但它本身无法表达不同代际处理器之间的相对性能。 Uber 的 NCU 模型解决的是一个略有不同的问题：让资源本身具备性能感知能力。它关注的重点不只是应该在一台机器上放置多少工作负载，或者为某项工作负载分配多少 CPU，而是一次 CPU 分配实际代表了多少计算能力。 原文链接： https://www.infoq.com/news/2026/10/uber-cpu-stateful-workloads/ "