如果说推荐算法、大数据技术是支撑字节跳动业务发展的技术能力，那么其迭代创新的核心技术理念是什么？

10月27日，“稀土开发者大会”上，火山引擎总经理谭岱以《数据驱动x敏捷开发，业务快速增长的双引擎》为主题，深度解码字节跳动业务快速发展的两大技术理念——数据驱动与敏捷开发，分享了如何构建数据驱动的飞轮、如何通过全栈云原生架构支撑大规模应用敏捷开发等内容。

以下为谭岱演讲实录：

大家好，我是字节跳动火山引擎业务负责人谭岱。很高兴今天收到稀土开发者大会的邀请，能够和大家分享和探讨字节跳动的技术理念和实践。

是企业的数字增长引擎

在开始分享之前，我先来向大家介绍一下 。

火山引擎是字节跳动旗下的企业级技术服务平台，是字节跳动技术团队对外提供技术服务的统一窗口。我们希望通过火山引擎把字节跳动的技术、产品和服务对外开放，包括云、AI、大数据、推荐等，帮助不同行业的企业实现自身的增长和数字化转型。

大家知道，字节跳动一直在践行技术中台的技术文化。所以在做技术ToB的过程中，我们也采取了这种机制，让技术中台直接把自己的产品商业化。所以火山引擎对外开放的技术和工具，跟字节跳动的技术中台是完全一样的。比如推荐，我们用的推荐平台、工具、方法论跟今日头条、抖音是一样的。这样，我们就可以用我们内部最好的能力去对外提供服务。

这是火山引擎整体的产品技术体系，分为统一的基础服务、技术中台、智能应用和行业解决方案四层，这四层从下到上分别满足了企业从运维、研发、产品、运营到营销等不同行业、不同业务场景的需求。

这是我们过去一年来字节跳动内部技术不断商业化的结果。在这个过程中，我们一直在思考字节跳动是如何一步步发展到现在的，支撑业务快速发展的技术理念是什么？今天我想跟大家分享一下我的理解。我觉得这个过程里面有两个非常重要的理念：数据驱动和敏捷开发。

数据驱动：构建数据驱动的飞轮

首先说数据驱动，亚马逊有一个著名的飞轮理论：公司的各个业务模块应该有机地结合在一起，相互促进，就像齿轮啮合一样。每个飞轮从静止到转动都需要付出努力，但因为它们是结合在一起的，所以每一次转动都不会白费。一旦一个齿轮开始转动，整个系统就会随之转动，而且会转得越来越快。

构建数据驱动的飞轮

回到数据驱动的话题，我们想也是如此。数据驱动不是一蹴而就的，也不是用一个工具、建几个报表就能实现的，而是一个不断解决问题的过程，最终形成多个系统自动转动，形成数据的飞轮效应。飞轮效应一旦形成，就会转得越来越快，数据驱动会成为日常内部协作的习惯，最终成为业务增长的动力。

围绕这一目标，我们可以把飞轮的构建分为业务流程数字化、数字化协作、数据驱动的业务优化、客观的分析评估四个关键步骤。

这些步骤之间存在一个有机的推广过程：

业务流程数字化是第一步，也是最关键的一步。业务流程数字化得越充分，对业务的描述就越准确，从而利于后续步骤。所以我们需要不断把线下活动线上化，把线上活动细化，全部用数字化的方式表达出来。

业务流程数字化之后，第二步是数字化协同。第一步是通过数据治理等手段，把底层数据标准化、统一化。第二步是让更多的人参与进来，所以需要借助数据可视化等工具，让不同的角色（开发、运维、用户、管理者等）加入到数字化协同的流程中来。

数字化协同最直接的影响就是效率的提升，协同越好，对业务的理解就越及时、越全面，用数据支撑上层业务的优化就越客观。

优化的效果一定不能靠猜测或者感觉，而需要客观的分析和评估。一方面可以通过A/B 等方式，通过数据精准评估业务带来的实际收益，另一方面还要进一步从多维度关联原因。

最后完成这四个步骤之后，我们就可以在业务优化和评估的过程中积累更多的数据，从而形成一个闭环，实现飞轮的转动。

数据字节驱动飞轮

这是一个比较抽象的描述，我们来看看字节跳动的具体情况：

这就是字节跳动构建整个数据驱动飞轮的过程。在这个过程中，我们把“业务流程数字化”、“数字化协同”、“客观分析评价”三个理念固化为统一的数据中台能力，以支撑针对不同应用的数据优化。同时中台的能力也能进一步优化业务的不同维度，包括增长、体验、变现等。

接下来我们讨论数据中台与应用优化。

应用型数据中心

我刚才其实提到了数据中台，它最大的一个功能就是帮助各类应用、业务基于数据驱动进行优化。所以建设数据中台有一个很重要的概念，就是一定要为应用而建。从数据出发，用数据来验证。说到数据验证，最重要的其实就是A/B测试。我们之前也在不同的场合强调过字节跳动对A/B测试的重视，包括抖音、今日头条这些名字也是通过A/B测试得来的。

对于评估来说，测试只是第一步，我们还需要进一步分析结果，因此我们搭建了相应的数据运营平台、智能数据洞察、客户数据平台等工具，帮助产品和运营对数据进行深度分析。

在底层，我们也构建了一套完整的数据采集、研发、治理套件，针对每天产生的大规模、批量、实时的数据，提高数据开发的效率。

所以我们可以这么说，在最底层我们更关注数据开发的效率和规模，而在最顶层我们关注的是数据分析过程中整个产品和操作的易用性和交互性。要实现易用性、交互性和底层规模、效率之间的一个连接，我们需要一个非常强大的数据分析引擎，这就是我们的引擎。

源于一个开源项目，所以有后缀。但其实是基于字节跳动的大规模数据场景，经过大量需求改造，最终形成的云原生的大规模数据分析平台。

我刚才提到，数据驱动是字节跳动的一个重要技术理念。我们每天有几十PB的新增数据，几万人需要从各个维度、各个细节去分析这些数据，这里面有很多性能、实时性的问题需要解决，背后的支撑是关键。

目前它服务于字节跳动内部几乎所有业务线，也是ABI系统、UBA系统、画像系统、A/B测试等分析系统的核心引擎，整体规模达到3万台服务器，日均查询量达数千万次。

面对刚才说的大规模挑战，我们做了五个层次的深度转型：

第一是支持流式数据。对于分析来说，我们对实时性要求非常高，所以我们支持实时数据的处理。这样可以为实时数据和离线数据提供一个统一的分析平台，支持批流一体化。

第二是计算和存储的分离。因为我们的规模非常大，要支撑几万人，基于几十PB的新增数据，高效快速的做几千万的实时查询，这是一个很大的挑战。通过计算和存储的分离，可以更好的解决性能问题。分离之后，计算层可以独立弹性扩缩容。存储方面，可以对接分布式存储系统，包括HDFS、S3等。这样一方面可以解决存储稳定性的问题，另一方面可以解决扩展的问题。

除了计算和存储的分离之外，我们在运维、安全等方面也做了很多工作，进一步弥补社区版本缺失的功能。

最后，我们实现了多级资源隔离。不同的部门、不同的角色每天都会进行各种分析，对权限、时效性的要求也不同。通过租户隔离、读写分离、异构计算资源，可以有效满足不同部门、不同角色在大规模集中资源配置中的需求。

通过以上五个大层面的优化，我们能够支撑整个字节跳动数据驱动的核心步骤。

应用程序优化

刚才讲了数据中台的一些实践，接下来讲如何通过数据驱动的方式来优化应用和业务，这里我以获客为例。

当然，无论是增长场景还是其他场景，如果要做好数据驱动的优化，首要的就是设计好指标体系。因为如果指标不对，你做再多也是错的。

对于增长，我们认为最重要的两个指标是“正向的投入产出”和“健康的用户规模”。

正投入输出，简单来说就是ROI>1，看起来很简单，但如何正确、精准的计算ROI，并且以每个用户的粒度去跟进长期的ROI，其实才是难点和关键。

当然，我们不能只看短期的投资回报率，还要看用户的长期健康状况，包括留存率、LT等。

设定了这些关键指标之后，其实可以利用指标去寻找对应的优化增长策略，这个增长策略不仅要满足正向指标，还要有可持续、可拓展、可复制的模式，这样业务增长模式就转化为可衡量、可追溯的数据驱动模式。

最后用一张图充分说明基于数据驱动、中台和应用优化构建整体飞轮的案例。

在这样的过程中，实验的速度非常关键。如果别人一天只能做10个实验，而你能做100个，结果不言而喻。从小的创意实验到大型APP功能的迭代开发，速度都起着非常重要的作用。这呼应了我要讲的第二个理念，敏捷开发。

敏捷开发：全栈云原生架构支撑大规模应用

说到敏捷开发，我们可以看到市面上有各种不同层次的解决方案，比如低代码等等。但今天我主要想跟大家聊聊云原生，因为不管是SaaS层还是PaaS层的解决方案，都离不开底层一整套云原生架构的支撑。

字节跳动的全栈云原生架构

这里我们简单回顾一下云基础设施技术的发展历史。相信很多人都熟悉这个赛道。大家可以看到，2013年是一个重要的转折点。2013年之后，随着、K8s等技术的兴起和普及，云从以基础设施为中心，走向以应用为中心；从以资源服务化，走向以平台服务化。字节跳动诞生于2012年，所以很幸运没有历史包袱，直接拥抱了最新的云原生技术。

我跟大家分享一组数字（2021年2月份的数据）：在字节跳动内部业务中，服务器节点数近百万；同时在线的微服务数超过8万个，并以每月2000个的速度增长；容器数超过750万个；每天的增量超过60PB。

从这些数字可以看出，我们面临的服务量非常大，而且增长很快。所以从基础设施的角度，我们认为有三个方面需要考虑：

第一是如何支撑海量服务。随着应用的微服务化，治理对象从单一应用变成了数量更多的微服务，这使得全局治理变得更加困难，包括搭建全局的配置中心和更灵活的全局网络、运行时的选择、配备完善的安全机制，以及如何把整个流程端到端的打通。

第二个挑战是如何让基础设施在大规模调度和运维下更加稳定。目前单个集群的平均规模在 5000 多个节点，大型集群有上万个节点。如此大规模下，我们需要考虑多种问题，比如在大规模镜像分发场景下如何预热镜像、如何管理联邦集群；在弱网环境下如何实现云边协同；在异构环境下如何实现机器学习场景下的 GPU 调度等。

第三是线上线下混部。因为规模这么大，成本自然就高，所以我们要提高利用率。线上线下混部是一个非常重要的手段。特别是对于字节跳动的业务本身来说，高峰和低谷非常明显。比如抖音的高峰是在晚上，其他时间 QPS 就没有那么高了。所以我们设计了一套线上线下混部机制，一方面可以降低成本，另一方面可以更好地应对极端情况下业务规模增长的问题。

同时在底层我们也构建了整体的容器+多云解决方案。

在多云方面，不但我们的计算可以是多云的，我们的有状态存储也可以是多云的，这样我们可以非常灵活的应对各种突发事件，比如年初春晚的抢红包活动、818新购物节等等。

此图从架构体系的角度进一步阐述全栈云原生体系的架构。

第一，在底层，有一套完整的云原生基础设施，通过统一的底层提供新一代高性能的计算、存储、网络解决方案，这其实是保障业务稳定、敏捷的基石。

服务平台层基于云原生基础，用于抽象业务开发中一些通用的平台和服务能力，包括高性能的微服务框架、基于服务网格的微服务治理能力、边缘计算平台能力等，服务平台的构建是为了让开发者能够更加敏捷地开发业务逻辑，将精力集中在业务逻辑上，而不用过多考虑资源、平台、服务间通信、治理等问题。

平台层上面是整个研发体系的建设，在这个层面上我们希望通过各种工具、流程机制和组织，帮助字节跳动灵活地支撑各业务线的快速开发和开发管理。

这三层设施的两边是重要的云原生安全体系和SRE服务支撑体系。

第一是云原生的安全体系，相比于传统的安全体系，需要进行不同层次的扩展，一是向左扩展，不仅仅关注运行时安全，还需要结合进程，关注应用全生命周期的安全；二是向下扩展，不仅仅关注容器的安全，还要关注宿主机的安全。

第二个是SRE体系，支撑快速发展过程中整个业务的稳定性。

因为时间有限，我挑选了两个比较有意思的话题来分享，一个是微服务，一个是移动开发，一方面比较有代表性，另一方面也覆盖了大部分业务开发场景。

服务器端——微服务、服务治理和

我们先来看微服务，可以用四点来概括字节跳动微服务的现状：

规模庞大，增长迅速。刚才提到字节跳动目前有 8 万个微服务，但 2018 年，微服务总量大概只有七八千个，所以三年增长了近 10 倍，而且还在增长。在这个过程中，我们自然遇到了很多挑战。

在线微服务90%以上运行在容器中，对于业务线来说，资源是不可见的，可见的只有PaaS和容器。这带来很多便利，有利于新技术核心功能的推进，但也带来很多挑战，特别是在调度复杂度方面。

技术体系以语言为基础，根据最新的调查统计，字节跳动内部语言是主要语言，超过55%的服务都使用这种语言，排名第二的是其他语言。

Mesh的全面落地与应用。字节跳动是国内最早在生产中规模使用Mesh的公司之一。

你可以看到字节跳动在微服务方面的推进非常快，甚至可以说相当激进。背后的原因是在字节跳动，速度和效率是我们研发团队要解决的头等大事。每天新增应用和新增用户增长非常快，研发要解决产能问题。这也是我们积极采用微服务架构的原因。但是这么大的规模，做这么快的迭代，对稳定性和信任自然会造成非常大的影响。

为了应对这些困难和矛盾，我们在实现端到端微服务架构时做了各种有针对性的优化：

首先在语言层面，因为是广大开发者使用的语言，所以我们做了很多框架层面的优化，比如RPC框架、HTTP框架等。我们已经通过开源的方式将这些框架回馈给社区——9月初，字节跳动就将它们开源，帮助更多开发者构建云原生的微服务架构。

第二是海量服务的治理。我们基于理念构建了自己的服务网格体系，把服务治理能力固化在字节跳动内部平台。一方面帮助我们解决多服务的兼容问题，另一方面通过稳定的框架和基于 Mesh 治理的理念，实现了全局流量治理的整体构建，单元化、系统化。

最后通过工具和方法的落地与实践，提升研发的效率，进一步提升运维的可观察性。

让我们逐一展开来说。

首先说一下框架，一个是RPC框架，一个是HTTP框架，这些框架都集成了我们自研的高性能网络库，解决了网络上的一些性能和交互问题，同时支持多种消息协议（/），多种交互方式（Ping-Pong//），并且能够提供更加灵活自主的代码生成器。

这是与 gRPC 性能的对比，我们选取​​了两组，一组是基于与协议的对比，可以看出两种方式都有比较好的性能，特别是在 TP99 延迟方面，随着并发连接数的增加，优势越来越大。

这是与业界一些框架的对比，包括平均延迟，QPS，以及不同大小包的对比结果。我们现将这两个框架以开源的方式提供给公众，欢迎各位开发者下载使用，与我们交流，提供意见。

接下来我们看服务网格的治理，前面提到，由于我们业务的类型和体量，在实现微服务架构时会面临很多挑战，比如语言碎片化、服务异构、协议异构、安全性、可观测性、问题追溯调用等，因此我们采用了服务网格的模型来进行整体的微服务治理。

上图中绿色框为控制平面，虚线框为数据平面。我们通过服务网格将控制平面与数据平面分离，消除了单点故障的可能。比如当数据平面流量过大、出现性能问题时，不会影响控制平面的路由策略；反之，当控制平面策略超负荷时，也不会影响数据平面的转发。

图中的每个虚拟盒子都是一个 Pod。与传统服务相比，我们的服务网格通过多种方式管理流量，例如熔断、限流、超时重试、缩减等。将这些功能从每个服务中分离出来，形成代理，并通过这些代理来实现服务间的治理。这样做的好处是每个服务只需关注自己的业务逻辑，而不必担心全局的调度和通信问题，使开发更简单、更高效。

当然这种非侵入式的模型带来很多的便利，但是也带来很多的挑战，其中最大的挑战就是额外的性能开销，所以我们做了很多工作来解决服务网格的最终性能优化。这样的优化是多层次的：

在网络和内核层面，我们使用共享内存或系统调用来实现真正的零拷贝。

我们也会优化基础库和组件架构，去掉一些不必要的交互，即使在编译阶段，我们也可以在不修改任何代码的情况下，通过更好的全静态编译，实现 2% 的性能提升。

最终通过这种整体的、多层次的组合优化，我们既享受到了服务网格带来的便利，又保证了性能。

移动端——极致体验的移动APP开发

刚刚讲了微服务框架和服务治理，接下来我们讲一下移动开发。

字节跳动是一家原生移动端的公司，我们的业务绝大部分都是通过APP开展的，目前我们运营了100多个APP，有上千人的移动应用开发团队。

要支撑这么大规模的研发团队和相应业务的发展，必须建立业界领先的移动应用开发平台，并通过大量的实践和各种极端场景的打磨不断优化。所以我们很早就建立了公司级的移动研发平台，代号：MARS，统一支撑各类上层业务应用的开发。今天大家使用的抖音、今日头条等APP都是基于MARS开发迭代的。

从层次结构来看，MARS 可分为五个部分：

第一是项目管理，通过抽象字节内部研发特点，我们建立了统一的项目管理平台，支撑日常业​​务迭代管理，特别是发布等特殊流程的优化。

其次，在应用开发阶段，效率非常关键。我们采用低代码的方式，进一步提升效率。比如我们为设计人员提供了通过设计直接生成代码的方式。对于运营人员、研发人员，我们采用这种可见可用的方式，帮助业务人员通过拖拽的方式，更加轻松便捷地构建业务应用。

然后针对传统的编码和研发阶段，我们输出了完整的端到端开发平台，涵盖APP、前端、小程序等不同端。

此外在质量控制方面，我们还提供了一站式全链路测试平台，基于大量真机模拟实际线上场景，最大程度发现潜在异常。

最后还有全链路监控平台，可以覆盖“终端-网络-后端应用-基础环境”的全应用链路监控，帮助研发人员精准定位和解决问题。

通过以上对于微服务和移动开发平台Mars的介绍，我想大家应该对字节跳动的敏捷开发有了更加形象的认识。

回到今天分享的主题，在字节跳动技术发展的背后，数据驱动和敏捷开发是两个重要的概念，但是这两个概念并不是割裂开的，两者是融合的。因为对于数据驱动来说，我们需要更多的实验来找到好的方案去推广，找到不好的点去改进。而敏捷开发可以保证每天都能进行大量的实验。反过来，通过数据驱动，我们可以在里面找到有价值的东西，同时积累更多的数据，从而为整个业务的快速发展构建闭环。

这里分享几个数据：在字节跳动内部，我们每天上线1500个新实验，总共有80多万个实验，同时有1万多个实验在运行，覆盖500多个业务线和各种场景，包括个性化场景、推送场景、建站场景、服务器场景、广告营销场景等等。

我们的底层技术、平台技术、业务层技术正是因为这两个理念的不断积累和迭代，最终驱动了业务的快速发展。

其实道理很简单，就像人们常说的练武要快，不练武就要快。道理很简单，但是要做好这些事情，需要不断积累工具平台和方法，并把这些方法变成日常习惯，最终形成业务发展的动力。

以上就是我对字节跳动在数据驱动和敏捷开发方面的技术实践的总结和分享，希望对大家有所启发。这里提到的很多技术基本都在火山引擎的外部产品中实现了。也期待大家使用这些产品，给予反馈，创造更大的价值。

谢谢你们！