字节跳动云原生历程：Kubernetes 支撑业务快速发展的技术体系

1. 字节跳动云原生之路 1.1 技术体系概述

从技术体系底层逻辑来看，字节跳动采用层次清晰的技术体系，一些常见的前端业务，比如今日头条、抖音、西瓜视频等，都是建立在一系列共享的技术中台和基础设施服务之上，基础设施要不断演进平台服务能力，以适应业务的快速发展。

例如字节跳动目前有十多万个在线服务，在线集群有超过一千万个Pod，这些服务每天有超过两万个变更，平均每五天字节跳动的业务系统就会更新一次；为了处理数据报表、机器学习训练，每天有超过1.5亿个离线任务，处理几十EB的存储资源。

字节跳动的基础设施面临的业务场景规模巨大，且持续快速变化。

1.2 字节跳动云原生发展历程

在快速的变化和规模挑战之下，云原生技术，特别是云原生相关的资源调度技术在字节跳动是如何发展的？

当前的重点基础设施建设领域是基于联邦的多集群资源统一管理与调度。

1.3 字节跳动云原生发展的动机

从研发和资源效率角度：

从研发和资源效率角度：

我们将类似于云原生的技术体系分为三代：云、和......

这三代技术总体上沿着产品前向集成和资源规模化两条路径推进，这两种思路从两个不同的角度推动技术体系的演进。

从技术体系迭代来看，字节跳动技术体系未来的迭代方向可以概括为以下几个主题：

我们希望朝着这些主题努力，最终形成下一代基础设施。

2. 资源管理实践

当字节跳动大量业务完成云原生转型，实现资源统一托管之后，从全局来看，如何高效地管理和运营集团资源？这是我们面临的第一个问题。要回答好这个问题，首先需要解释一下理想的资源管理模型。

资源管理的理想状态是，我们为开发者提供统一的资源门户，用户可以通过这个门户从统一的资源池中获取资源。

在业务和应用方面，我们希望开发者能够极其灵活的获取所需的资源，像“自来水”一样获取各种形态的资源，虽然自身的资源需求复杂，形态各异，要求各异，但都可以按需获取，按需可用。

在资源管理方面，我们希望呈现给用户一个统一的资源池——完全融合的混合资源池，这个资源池拥有全局最优的资源效率，可以统一管理多个地域、多种计算架构的资源，不同业务形态、不同团队之间的资源可以灵活调配。

但到了实际的资源需求场景中，各类业务用户的资源需求极其复杂。

总体来看，字节跳动目前承载的平台租户包括在线服务、机器学习平台、数据平台、FaaS 以及一些存储业务，这些平台租户的应用模型差异很大，有无状态应用模型、有状态应用模型、批量应用等等。

除了业务场景的复杂要求外，安全、性能、容灾等也会对底层资源管理产生影响：

总体来说，统一资源管理有挑战，但也有可观的收益。在实际实施过程中，需要将运维、调度等进行合理的结合，才能实现有效的资源管理。

2.1 统一资源管理的挑战和优势

这里我们总结了统一资源管理的挑战和好处。

挑战：

收入：

2.2 资源统一解决方案

为了解决资源统一管理的问题，我们提出了三个思路：

1）抽象出可以提供的资源销售模型，方便不同业务线、业务系统精准表达自己的需求；

2）打造统一的配额管理平台，让开发者能够灵活地管理自己的资源；

3）资源分级调度体系，使单机集群能够快速、灵活地释放字节跳动内部所有计算资源。

2.2.1 资源模型抽象：QoS与弹性分类

在资源模型上，我们提供给应用程序的资源形态分为三个层级，以CPU维度为例：

目前字节跳动内部对应用的弹性资源交付的需求主要有三类：

2.2.2 层次化资源调度

如何将资源需求精准高效地传递给开发者，需要一套完整的调度体系来支撑，字节跳动采用分层的调度体系来实现调度交付。

单机调度主要是对单机资源管理的扩展：资源微拓扑感知与资源分配策略，主要解决如何让不同核的Pod统一运行在一个节点上。新增的QoS组件主要负责在容器资源管理链路上根据应用的微拓扑亲和性要求，为Pod分配包括CPU内存、GPU网卡等设备。单机拓扑结构上的信息可以通过CRD上报给调度器，由调度器中心以抢占或者调度的形式将Pod分配到合适的节点上。同时该组件在框架上可以灵活扩展。

它是实现单机策略管控的组件，能够持续观察Pod的细粒度的系统指标如何与不同业务形态的资源使用模型相结合，做出预估并决定如何在各个资源维度上为Pod分配合适的资源。

集群中心调度器需要解决的核心问题是如何在整个集群中自由调度不同形态的应用，需要满足不同调度语义的要求，充分降低集群空置率；在调度性能上，既要满足低频调度场景，又要满足批量型高吞吐调度场景；针对各类应用场景提升调度质量，也是集群中心调度器需要解决的问题。

下图从调度功能层面总结了不同场景对调度器的要求：

字节跳动目前采用的调度器是参考框架的分布式调度器，这个调度体系的主要组成部分是集中式、并行式和集中式。

其中主要负责将应用及集群内的节点资源分配到具体的节点上，主体结构与原生的调度器结构类似，主要处理 和 的调度计算逻辑，可以从不同角度解决调度结果冲突，替换原生的Pod语义，可以更方便地处理常驻任务中的按Pod调度和批处理场景中的按批调度。

当集群整体资源使用率很高的时候，乐观并发调度很容易出现调度冲突，我们的解决方案是每次响应结果中提供多个调度应用的候选节点，然后发送给他们去解决冲突，这样的设计可以降低解决冲突失败的概率。

以往的混部方案都是基于 Yarn 的联控方案，每个节点上同时运行 Yarn 和 Yarn 的管控组件，另外还有一个中心协调组件负责分配两个系统可见的资源。联控模式下，单机层面每个节点中 Agent 占用的资源量并不大，但放眼整个集群就是非常可观的资源量了。如果能实现统一的链路来管理不同形态的资源，那么资源优化的架构和效果可以大大简化和受益。

在新的统一调度架构下，我们对混合部署架构也做了一系列的调整，保留了平台层API，保留了在两个Yarn入口部署应用的能力，底层系统全部融合到了基于的管控系统上，可以实现大数据系统底层系统的平滑切换。

在新的架构下，无论是在线服务还是离线 Pod，都可以通过一个公共 API 和一个统一的调度器来进行资源调度，这不仅实现了资源分类模型中控制链路的复用，也为在线和离线服务运行在同一个集群中时，资源层如何分配、如何协同的思考提供了更多的空间。

2.2.3 全局调度

考虑到字节跳动的整体规模，单一的集群能力不足以满足管理字节跳动全球数据中心的需求，在应用间隔离、多地域灾备、算力标准化等方面，字节跳动还有更加细粒度的调度需求。

为了解决百万节点规模下全局资源和业务维度的匹配问题，字节跳动全局调度器增加了联邦层，实现大粒度的应用和资源调度匹配逻辑。

在应用方面，我们以应用优先级作为主要维度；在资源池方面，我们以机房作为主要维度。这两方面的交叉组合，形成了在应用整体粒度上可以全局调度的分配空间。应用和资源的维度都很多，如果选择的资源维度过多，全局资源就会被分割成太多碎片，不利于管理。所以在选择主要维度的时候，需要考虑对各个资源池容量的影响不能低于设定的节点数。

字节跳动现有的全局调度器主要参考了社区的V2框架，在社区的基础上我们还实现了两点扩展，第一是联邦层访问语义的透明改造，这个改造让我们的上层平台可以使用原生的资源对象来操作底层资源，从而降低平台接入联邦资源池的成本。第二是全局调度的大规模改造，让多机房的容灾业务线之间的安全隔离，以及多代际标准算力都可以统一在全局调度上实现。

3. 挑战与未来

目前，字节跳动内部各形态计算应用已实现全面云原生和资源级统一，全集团平均计算资源利用率超过40%。

虽然仍有提升空间，但利用率在可预见的未来很快将达到瓶颈，我们认为下一代基础设施仍将沿着产品前向整合和资源规模化经营两个方向持续发展。

3.1 微服务治理

在产品演进方面，以微服务治理为例，字节跳动目前有超过十万个微服务支撑系统构建，这些微服务具有复杂的依赖关系。

上图是从生产环境抓取的子业务线服务的拓扑结构，该图中的每个节点代表一个具体的微服务，节点之间的边代表服务之间的依赖关系。

在服务架构治理方面，由于这些服务分散在不同的业务团队、不同的系统，很难从全局的视角进行架构迭代，从而导致一些老旧的服务无法下线。

业务、业务系统之间的依赖关系也直接通过底层服务之间的远程调用来实现，在跨业务线交互场景下直接暴露细粒度的服务接口会大大增加服务架构治理的复杂度，往往需要多个部门的协同才能推动服务架构的演进。

因此在微服务​​的产品层面，只需要一个面向应用的解决方案来管理一个子业务线内的所有服务。

资源开销方面，业务系统之间是通过网络调用进行互联互通的，大量的数据资源会耗费在网络通信加解密上。随着微服务数量的增多，这方面的资源开销也会越来越大。目前字节跳动正在推进函数化平台化，越来越多的服务会以更细粒度的函数形式来表达自己的逻辑，微服务端会趋向于更小规模。那么架构治理和资源开销方面的挑战就会更大。

3.2 资源利用率与资源有效利用率

此前资源层面的优化都是围绕集群底层资源平均利用率展开的，通过混合部署、弹性扩缩容、分时复用等形式，我们在平均利用率上取得了不错的优化效果，但底层资源利用率与实际业务成本之间还存在较大差距，如何更直接地在应用层面解决容量成本问题是下一步我们需要重点研究的方向。

3.3 第三代基础设施产品的迭代

总结一下，下一代基础设施在微服务领域有几个关键的技术方向。