字节跳动的多云云原生实践之路

作者 | 火山引擎云原生平台负责人 沈健

2022 年，火山引擎联合咨询机构 IDC 对超过 4500 个云消耗大于 100 万的企业进行调研，发现使用多云架构的企业占比达到 88%，达到历史新高。另据麦肯锡的报告，到 2025 年，依然会有 42% 的企业保留有私有云。在负载分布层面，边缘云占比在逐步上升，根据 IDC 报告，25 年超过 30% 的数据需要边缘实时处理。

造成这些现象背后的原因是复杂的，既有业务形态和成本管控的原因，也有数据安全和监管要求的考虑。对于企业来说，随着云上迁移的业务变多、复杂度变高，分布式云也成为各类组织必须迎接的挑战。如何做好多云策略，如何平衡好负载，如何保障安全，只有构建好适合自身的分布式云架构，才能真正做到“用好云”。

在 7 月举办的 ArchSummit 全球架构师峰会上，火山引擎云原生平台负责人沈健围绕“字节跳动的多云实践之路”为主题进行了分享，介绍了字节跳动实行多云云原生战略的原因、过程和最终成果。

业务需求驱动多云架构建设

云服务经过十几年的演进，如今在企业的应用已经发展出了多云、混合云、分布式云、边缘云、行业云等多种形态。面对业界层出不穷的新概念，很多人会困扰：它们的区别是什么？

在云服务商眼中，按照中国信通院发布的定义，所谓分布式云，是一种将云服务按需部署到不同地理位置，提供统一管理能力的云计算模式。它摒弃了公有云、私有云、混合云、多云等分类，首次将地理位置作为考量因素，为用户提供不同位置的云资源统一管理平面，能够增强混合多云一致性管理、拓展边缘计算服务能力、实现云服务统一托管治理。

但对于真正意义上需要用云的企业，不同云形态的含义则更加场景化：业务本身需要什么样的云，开发团队有能力用好什么形态的云，企业运维团队的云管理能力成熟度发展到了什么阶段……虽然大家都在谈云，但关注点是全然不同的。

字节跳动在发展过程中，也慢慢发展成了多云的状态：无论是中心云、私有云、边缘云，它们都是多云的一种形态，分布式云则是多云之上更高层次的一个形态。这种变化是和业务发展密切相关的：

2017-2018 年，抖音经历快速发展，DAU 增长破亿。在这种场景下，由于单朵公有云、私有云的资源供给都存在时间周期，技术团队很难预估全年具体需要多少资源量，灵活从其他云厂商补充云资源成了一个必要的解决方案。

视频直播业务盛行期间，为了更好地保障直播效果，技术团队需要采购对直播网络较友好的云资源——它们往往是地域性的、边缘性的，在业务驱动下，区域云、边缘云也进入了字节跳动的云计算资源池。

早期业务出海期间，建设自主数据中心会给新业务带来巨大的成本压力，再加上各国不同的数据安全合规要求，在拓展海外业务的时候，我们也基本上都使用了海外的云资源。

随着业务持续增长，出于成本、安全、信创的考虑，避免厂商绑定的重要性也日益凸显。长期使用单一供应商会存在云产品涨价、服务质量下降、技术架构不够灵活等风险，考虑到没有一朵云是 100% 无故障的，技术团队也更愿意选用更多的云供应商提供服务。

由于上述问题的存在，字节跳动的技术团队坚定地选择了多云作为基础架构发展的主要路径。当然，这也带来了一些实践层面的挑战：

• 部署 / 运维复杂度：应用 / 服务多云部署方式，容器、主机、云上服务等不同类型的部署方式都额外增加了部署和运维的难度

• 打通 / 互操作性：网络打通、身份 / 权限打通、运维打通、数据访问打通、流量管理

• 数据管理 / 合规难度：数据离散分布之后数据资产的管理难度加大，数据合规挑战加大、数据泄漏风险和追踪难度加大

• 成本控制复杂度：业务、成本、资产的管理难度

字节跳动的多云实践

在业务发展驱动下，字节跳动的多云实践在不同时期有不同的侧重点，驱动着云原生架构的逐步发展：

2016 年，今日头条等业务快速发展，字节跳动基础架构团队启动 TCE（Toutiao Cloud Engine）平台建设，用一个统一的云平台管理之前业务中台各自维护的资源池，解决了应用的快速部署问题和管理问题。

2017 年，随着外部竞争态势的复杂化，快速迭代、快速推出新功能变得迫切，我们开始引入微服务架构，通过微服务的灵活性和服务网格的统一治理能力，提供多样性适配，让每个技术人员都能快速投入到业务发展中去。

2019 年，抖音、今日头条等业务达到较大规模，频繁的营销活动要求底层有海量云资源供应，在这一阶段，基础架构大力推进了“推广搜”的云原生化，把物理机服务与在线服务进行全面融合，实现统一容器化调度。

2020 年，为进一步控制资源使用成本，技术团队实现了常态化在离线混部，在面对高峰流量时能够快速进行资源出让，保障业务稳定性。同时，数据库、缓存等存储系统也开始进行云原生化改造，加速了更大范围资源池的统管和融合。

从上述演进不难看出，云原生架构这些年要解决的难题之一就是巨大的资源缺口。大量资源短缺会不可避免地导致“集群建设 — 应用搬迁 — 腾挪资源”，进而带来不小的运维成本和稳定性问题。

为了解决这一问题，早在 2019 年，我们就开始进行集群联邦建设，通过解耦应用和集群的绑定关系，将各个业务线的资源并池，以应对分布式云带来的挑战。到 2021 年，字节跳动正式实现了全场景应用编排和资源管理的标准化和统一化，目前联邦集群已管理近 50 万节点，即便面对超过 10 万的微服务数、每天 3 万多次的变更数，也能为业务提供持续、稳定的保障。

多云下的海量算力实践

如今再看字节跳动的底层算力平台，它可以被分为分布式云原生平台和计算平台体系两部分。

其中分布式云原生平台汇集所有公有云集群、IDC 集群和汇聚集群（区域性 / 边缘集群），由 开源编排引擎 KubeAdmiral 统一管理。通过分布式的集群编排，在不采取任何其他措施的情况下，字节跳动的常态运维水位可以从 85%-90% 提高到 95%，资源利用率提升非常显著。

为了缓解运维复杂度问题，技术团队也开发了一个基于分布式编排引擎的统一调度器 Godel。这是一个融合调度器，能管理在离线资源，调度在离线任务，同时它也针对大规模场景进行了很多性能上的优化。

资源管控系统 Katalyst 采用 Kubernetes Native 的方式进行重构，能提供更强的资源管理能力、调度能力、抽象能力和数据能力。通过这些能力，技术团队可以更好地按级划分应用使用的资源，实施精细化的资源出让策略、多维度的资源隔离能力、多层级的负载驱逐策略，让整体混部变得更健壮。

在这些核心中间件之上，是持续交付、服务网格、应用引擎等服务，这些服务可以识别资源在哪个部门、哪条业务线使用，再通过流量分发引擎调度，实现全局性的资源和流量管理。

计算平台体系则是针对字节跳动内部存在的海量离线业务，这类业务存在资源离散的问题：各个云上的存储、各个机房的 HDFS、各个机器学习任务使用的 NAS……为了进行统一管理和使用，技术团队推出了大数据文件存储 CloudFS，提供对接多云对象存储能力，无论用户在哪里、用户想访问的数据在哪里，它都能提供本地缓存加速。

离线业务存在的第二个问题是大数据作业无法享受云原生的好处：传统大数据引擎不是针对云原生设计，难以直接云原生部署，各计算引擎和任务需要进行深度改造才能支持原先在 YARN 上的各种特性，改造成本巨大。基于此背景，字节跳动推出了基于云原生的 YARN 解决方案 —— Serverless YARN，它 100% 兼容 Hadoop YARN 协议， Hadoop 生态下的大数据作业无需修改即可透明迁移到云原生系统上，在线资源和离线资源间可以高效灵活转换、分时复用，集群整体资源利用率得到显著提升。

在这些系统之上，我们又建设了一个关键模块——多数据中心离线统一资源湖 ResLake。它作为一个融合了计算 + 存储 + 网络的巨大离线算力湖，方便批计算、流计算、AI 训练等任务接入，让技术团队可以进一步加强跨机房资源管控、加强热点数据治理、提升多集群多队列用户体验、提升多机房资源利用率。按照最新数据，在 ResLake 的作用下，技术团队实现了超过 1.4 的作业加速比，队列跨机房流量优化也超过 30%。

降低运维部署复杂度

对于在线业务，分布式云原生平台就变得至关重要了。举个例子，直播业务之前在各种云上都开了 Kubernetes 资源，在分布式云原生平台上线后，新平台如果需要对这些一开始就游离在外的资源进行纳管，就必须具备对存量应用的无缝接管特性：不仅需要无改造、无运行影响地转移应用，也要能连接多基础设施 Kubernetes 集群，方便集群接入。

除了资源统一，在应用管理方面，分布式云原生平台也提供灵活的跨云分发策略，包含集群名称、标签、污点容忍调度，以及依赖资源的跟随分发。技术团队也着重锤炼和打磨了平台的开源兼容性，使其能完全兼容 Kubernetes 生态，支持原生 Kubernetes 及 CRD 资源、Helm 等应用定义。

在日常运维管理方面，字节跳动内部有一套统一的可观测体系，提供在离线应用的监控能力。如前文所述，我们的在离线业务是通过各种各样的中间件被混合在一起的，在这种情况下，我们可以轻松做到统一可观测，帮助业务团队快速定位问题、解决问题。

除此之外，字节跳动的分布式云原生平台也提供统一的应用治理。业务应用的实例可以多云多活的部署在不同云上的 Kubernetes 容器服务中，通过多集群的应用、流量、存储等的统一治理，实现高可用容灾，提升整个业务系统的故障弹性和可靠性标准。

降低成本之资源利用率

在统一资源底座后，技术团队接下来要面对的就是如何长期地提高资源利用率。我们把业务负载按时延容忍度和可重入性进行划分，在下图的两个象限中进行合理分布：

依据这样的分级分类，我们就能判断各个应用对哪些资源相对更敏感，在遇到一些特殊情况时，能够根据不同业务的优先级进行有梯度的分级去除，确保高优先级、高时延敏感任务的稳定运行。

此外，隔离能力也是非常重要的一个因素。因为计算机系统本身是一个分布式系统，它包含 CPU、硬盘、存储和网络，字节跳动内部也针对这些不同的算力资源采用了一些隔离机制，比如 CPU 会有一些 cache 隔离、系统级的唤醒能力，硬盘方面则实现了 cgroup 级别的内存回收，以及通过用户态的 advisor 机制实现兜底强杀。

技术团队也有尝试借助一些机器学习的能力，使得不同算力能按照不同要求，更精准有效地去匹配这些隔离机制，从而减轻各业务间的干扰影响。

目前，通过这些机制，字节跳动的混部方案已覆盖数十万机器，天极平均利用率高达 63%，部分核心业务集群也实现了整机天级利用率从 23% 到 60% 的提升。

分布式云的下一阶段

回到落地多云给企业带来的实践层面挑战，除了部署 / 运维复杂度、打通 / 互操作性和成本控制复杂度，最后一点就是数据管理 / 合规难度。随着国际格局愈发复杂，多云 / 分布式云也出现了一些亟待解决的下一阶段发展问题。

一方面，近年来 AI 兴起，以 GPU、FPGA、ASIC 为代表的 AI 芯片被广泛应用，并与 CPU 组合来满足高吞吐量、高并发和并发互联的需求。各式各样专有芯片的产生，对算力造成了巨大挑战：如何更好地匹配算力、如何更好地感知不同的算力、如何结合效率 / 成本 / 用户体验做出更加智能精准的判断、如何实现对应的调度……这是分布式云下一阶段在算力调度侧要解决的重要问题之一。

另一方面，近年来各个企业也开始越来越重视数据合规，如何对联通的数据进行隐私保护也成了一个重要课题。当前比较流行的方案是隐私增强计算（Privacy-enhancing Computation），包含三个主要流派：

• 联邦学习：一种分布式机器学习算法，在不交换原始数据的前提下，完成共享模型训练。联邦学习可以帮助多个参与方共享数据价值，实现数据可用但不可见；

• 可信执行环境：基于硬件的安全机制，将参与计算的代码和数据加载至一个受 CPU 保护的可信环境中，在机密性和完整性上提供保护；

• 多方安全计算：在运行时，多个参与方各自拥有私有数据，他们通过非明文的数据交互，来实现约定的对整体数据全集的某种计算（如联合查询、联合建模等）。

上述变化都对企业级云平台的管理能力提出了更高的要求：一是要 有能力解决应用的研发和管理问题，为用户提供一致的云原生体验，包括开发框架的跨云能力、整体效率问题和底层成本问题；二是 需要具备一定的开放接入能力，这是一个面向应用、面向开发者、面向企业的真正意义上友好的多元化增强平台所需要解决的问题。

这些问题都会伴随底层问题的破解被一一解决，并走向持续发展。