火山引擎，不走寻常路的底气

迈不过友情╰ 2024-02-05 18:13 29阅读 0赞

> 转载：https://baijiahao.baidu.com/s?id=1764113509942259731&wfr=spider&for=pc

**导语：**

在大模型热的当下，火山引擎选择了一个与众不同的角度——为需要训练大模型的企业提供最好的机器学习平台。

这包括，支持万卡级大模型训练、微秒级延迟网络，让大模型训练更稳更快。

而对于“火山引擎做不做大模型”这个问题，火山引擎的总裁谭待回答的很巧妙：“国内有数十家做大模型的企业，大多已经在火山引擎云上。我们将接入多家大模型，为企业和消费者提供更丰富的AI应用”。

一切的一切，都显示出，火山引擎是一个不走寻常路的云计算企业。

![img][]

**1、超级业务产生的超级云**

4月18日的火山引擎在其举办的“原动力大会”上，推出了许多充满吸引力的新增产品和服务列表。

这包括但不限于，火山引擎展示了云技术、云服务和云场景方面的最新探索、应用与实践，在敏捷迭代、数据驱动、体验创新层面发布了新品。

2020年6月22日，火山引擎才正式上线。而且，笔者一直没有搞清楚的是，它为啥不干脆就叫“字节云”，以至于在不了解的人面前需要频频解释——火山引擎，就是字节云。

但是，不足3年时间，就拿出如此丰富的产品线，这是否过于奇幻？

至少，2020年加入火山引擎时，谭待看到了希望所在。

加入之前，他关注的两个点，都从字节跳动副总裁杨震原那里得到了满意的回答：

**第一：专心做toB的业务；**

**第二：字节在云计算领域积累的能力，都可以适时对外开放；**

“如果单纯从字节云目前的市场份额来看，的确还是在前五之外。但我是用另外一种计算方式来看待这个问题的”，谭待告诉笔者：“如果把字节自身业务所用的云计算的基础设施、云原生能力，以及对云的理解都算上，那么我们可能已经是国内云市场隐形的前3名，而这个行业的铁律就是，超级规模产生超级云。”

“云这件事情极其依赖规模，所以你看，并不是所有的巨头都有云业务，本质还是规模不够大”，谭待说：“规模可以锻炼调度能力、摊薄平均成本，更重要的是极限条件下可以打磨出云的边界。所以国内真正能做大的云企业，一只手就数得出来，而我认为字节有独特的竞争力和机会。”

在字节启动一个新的项目相当于一次内部创业，谭待等人在2020年疫情严峻的几个月里，用飞书文档的方式写出了火山引擎的第一版bp，并在见面困难重重的情况下开始了第一轮面试，火山引擎就此诞生，并一步步的走向开放。

其实，在火山引擎成立之前，就有一家著名的手机厂商找到字节跳动，希望对浏览器和应用商店的算法做一些优化，在其中运用字节的个性化推荐算法。字节跳动略为迟疑地接下了这一“份外之事”，却意外获得了良好效果。

这次合作深深启发了字节跳动——多年来，字节跳动凭借着直面用户的理念、数据驱动的工作模式获得了健康持续的增长，如果把这背后沉淀出的技术能力对外输出，能够对行业产生巨大的价值。

而火山引擎的正式立项，则证明其走上了商业化落地的快车道。

**2、不仅仅是“字节同款”这么简单**

在官方介绍中，对“火山引擎”是这么解释的——是字节跳动旗下的云计算服务平台。依托于字节跳动技术能力、增长理念与运营方法论，为企业客户提供技术服务。

有人认为，这里面最大的魅力，在于“依托于字节跳动技术能力、增长理念与运营方法论”这句话，更有赞美者直接称火山引擎的产品是“字节同款”，贬低者则称之为“富二代”、“拼爹”。

的确，依赖于数据驱动的字节跳动创造了一个世界级的成长奇迹，以至于外界对其成功的秘奥，无不希望一窥究竟。

在行业里更有一批字节的铁粉，例如理想汽车的创始人李想，在引入字节的协同工具飞书后，不忘在各种场合安利，溢美之词溢于言表，比如——“我们研究了各种各样先进组织，最后找到了一个离我们很近的——字节公司”，他还指出——飞书作为一款承载了先进管理理念的协作工具，在信息流通效率和组织文化建设方面都给理想带来了不少改变……

所以，笔者又对谭待提出了两个灵魂之问。

**第一个问题是，这样不会把字节的核心机密泄露出去？**

谭待对此的看法是，基本不会。

“字节的发展有很多因素，包括领导力、内容、运营、技术甚至是时机和运气，这种成功在我看来不是通过几项技术的输出就可以复现的”，谭待说。

在谭待看来，好的技术会自然的流动。比如百度的搜索做得最好，但现在能应用搜索技术的公司也不少；字节的推荐做得好，但现在大部分互联网公司都会或多或少的用推荐技术……而且，技术还会随着技术人员的开花散叶而自然流动，也会随着开源文化去流动，所有的好公司仅就技术方面，彼此之间都会存在你中有我、我中有你的情况。

所以，我们现在在字节云的客户列表中，也可以看到一些与字节存在泛竞争关系的企业。

这就好比，目前比亚迪是中国汽车卖的最好的企业，但这并不妨碍比亚迪也对外销售自己的电池——刀片电池的确是比亚迪的核心技术之一，但并不是比亚迪成功的唯一要素，所以比亚迪可以放心大胆地卖自己的电池——当然，笔者认为，这还是需要敢于做技术输出的企业有极大的自信。

**第二个问题则是，字节会按照什么样的标准去释放技术？**

谭待的回答则是，好的技术、优秀的技术，特别必须是在字节的内部PK中取胜的技术。

事实上，在toB的企业中，一直存在两种路线。

**第一种路线是，一套技术栈自用，一套技术栈外售。**

出现第一种情况的企业，一般来说历史都比较悠久，比如bat，它们是从非云时代过来的，然后一点点的上云，有很长的一段“两条腿走路”的特定历史阶段。所以，最后也自然形成了自用和外售的两条技术-研发-管理路径。

这样的优点是，管理起来比较轻松，内外分明。缺点则是，在后期往往会在很多技术路线上出现分叉，在必要的时候需要强力整合；有时候也会出现，外部客户看中了某项内部能力，经过讨论这个能力是可以外放的，但需要测试和产品化，这往往容易失去先机。

\*\*另一种路线是，从一开始，所有的技术栈就只有一个，对内和对外的技术不仅是同款，而且是同源的。\*\*这样最开始的代价是管理成本比较高，因为整个架构是天然去中心化的、分布式的，而不是科层式的。这就需要有一整套配称的协同机制，而字节跳动就是这种模式的典范。（由此多说一句，飞书的发展其实是为了满足这种管理的需求才产生的）

所以才有一句话——没有一个字节的高管知道自己的所有员工坐在哪里。

但这并非终极，谭待指出，真正能够拿出去商品化的产品，“它首先是在字节的内部pk中取胜的。字节在技术和研发的管理上，能够实现‘小前台、大中台’，前提是中台的能力够强。而这来自于机制的设置——字节比较早的就实现了内部结算的机制。”

“我们所有的技术和产品，实际上都是可以在内部平台上‘买到’的，而且实打实的要做内部结算的。这比任何考核都公平，也都严酷。只有那些真正在内部广受欢迎的、过硬的技术才能卖出去，所以它在市场上出现以前，其实就已经经过我们内部市场的检验了”，谭待说。

**3、彩蛋**

事实上，当一个客户从火山引擎买走某项技术或者功能时，往往会得到一些附赠的“彩蛋”，从而使这笔交易变得极富性价比。

比如，“埋点”就是用好推荐技术的重要know-how。

**所谓的“埋点分析”，是在需要采集数据的“操作节点”上，对特定的事件进行捕获、处理和分析，进而分析全量行为，满足了企业对海量数据的去粗取精，实现产品、服务快速优化迭代的需求。**

比如，同样是播放一段视频，到底是用户点击“收藏”的价值更大，还是用户停留的时长价值更大？这很难说，所以某种意义上讲，埋点是一种重要的技巧，而且很难标准化。

那么，这时候如果字节的工程师愿意去提供一些埋点的技巧，那么对中小企业来说，可能是它们运营很久也无法捕获到的一些特定的、重要的知识。

再举一个例子，BI（Business Intelligence）即商务智能，它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确地提供报表并提出决策依据，帮助企业做出明智的业务经营决策。

字节跳动作为一家数据驱动的公司，拥有大量的好用的数据工具，更重要的是形成了一种依赖数据进行业务推进的文化，在这里每天有6万员工会使用BI工具驱动自己的工作。

“很多用户渴望这样的一种能力，但这种能力不是仅仅买一些工具就可以实现的。比如，你的组织力是否能够让三分之一的员工养成使用BI的习惯和文化？或者，你的数据底座是否支持你实时的提取数据并有效的分析”，谭待说：“所以我们卖给客户的不只是工具，工具是实践能力的固化，但还要理念契合才会驱动这种能力，所以客户从我们这里也会得到理念的启发。”

所以，字节之所以能不断的吸引新的用户，不仅仅是因为工具做的足够好，而且还在于用好这种工具需要的理念传承，也能在无形中帮助用户有新的启发，而这是无价也无形的“彩蛋”。

当然，这些无形的财富，必须通过具体的产品才能传承，于是在火山引擎的产品列表中，就有了“数据飞轮”这个产品。

![img][img 1]

简而言之，这就是外界最想要的、基于字节跳动10年实践打造的用于实践数据驱动的工作台，它实际上解决的是：“以数据消费促数据生产，以数据消费助业务发展”这样一个核心命题。

但是，构建数据飞轮有两个关键要素，**一是数据飞轮本身的“数据驱动”理念，一个则是合适的产品服务，让模式落地。因此，火山引擎也是从数据产品和咨询服务两大方面切入，帮助企业落地数据飞轮，并真正转起来。**

从去年发布数智平台VeDI开始，火山引擎就在持续开放字节跳动内部数据技术与工具能力，并不断推出产品，如帮助企业进行 Serverless 智能湖仓构建，通过极致性能和Serverless全托管等能力，为企业带来数据基础设施建设的降本增效；推出管理驾驶舱Plus，快速响应管理者去看实时数据和事实决策的需求。

而类似这样的产品，在4.18的发布会上，还有不少。

**4、从同源、同款到同池**

另一个让笔者感到震撼的是，4月18日，火山引擎宣布与字节国内业务大规模并池，实现内外资源的大规模内外实时复用。

这意味着，火山引擎可在特定时间内向企业客户快速交付超大量规模资源，调度可达分钟级10w核CPU，保障敏捷弹性和更极致的降本增效。

谭待表示，目前字节国内拥有上亿核CPU集群、数十EB的企业存储，拥有庞大的云计算能力。而此次火山引擎与之并池，将提升火山引擎的云计算规模和能力，为合作伙伴带来更为优质的云服务能力。

应该说，这比会上的另一个焦点——为大模型提供算力平台，更令笔者震撼。

**它的关键在于，字节跳动在理念上的突破，以及其社会意义和未来指征。**

多年以前，笔者访问滴滴出行的时候，曾经遇到一个问题——每天的早晨和傍晚，都有无数人因为打不到车和加价问题而骂滴滴，但在上午和下午，又有大量的车辆空驶。

这个陷入死循环的问题，让滴滴的高管去找到了经济学家周其仁。

周其仁指出了问题的所在，这是运输行业乃至服务业的一个经典问题——企业如果按需求波峰去采购固定运力，则必然亏损；如果按波谷去采购运力则必然无法满足需求。

周其仁给出的是经济学界已有的答案——弹性运力，这个答案是后来一系列的拼车、顺风车等等业务开展的基础。

在我们生活的数字世界里，问题同样存在。企业用高价购买的算力，在波峰时不够用，在波谷时很浪费。所以，某种程度上，云计算赋予的这种敏捷、弹性的能力，从微观上是一个对用户很有性价比的解决方案，从宏观上是对日益稀缺的资源的良好复用。

但在事实环境中，特别是在中国，很少有企业敢于真正的把所有的数据都放在公有的云上，尽管混合云的部署成本更高，甚至有违云计算的本意。

而字节的做法，从技术层面讲，证明了其云计算的能力，包括自研的服务器、自研的OS等。其自研虚拟网络，可将传输延迟降低50%；自研mGPU，将部署密度提升超过500%，为上层应用带来更高资源利用率。

同时也说明了，字节作为诞生在云原生时代的企业，基础架构是基于云原生的理念发展起来的，内部计算体系容器化超过95%，只有如此，才能实现内外资源大规模的共池、流转和调度。

但这些与其社会意义相比，就显得过于具体。

小说家丹·布朗在其作品《地狱》中塑造了一个生物学怪杰的形象，此人因为相信地球人口突破80亿后会迅速导致地球毁灭，而不惜开发一种使人类绝育的病毒……

小说毕竟只是小说，但它指出的问题不容忽视——既随着人口的不断增长，我们将越来越面临资源稀缺的问题，无论是脑机接口、元宇宙还是生物编辑技术，其实都是或多或少在某种意义上为了求解这个问题。

根据国际数据公司（IDC）的预测，到2025年，全球数据量将达到175ZB，而且近90％的数据都是非结构化的。这些数据需要大量的计算能力才能被分析和处理，因此需要消耗大量的能源。同时，随着AI算法不断升级和发展，它们的复杂性和计算量也在不断增加。

据估计，目前AI的能源消耗占全球能源消耗的约3％。根据一份报告，到2025年，AI将消耗15％的全球电力供应。这意味着，AI的快速发展将对能源消耗和环境产生巨大的影响。

而AI仅仅是庞大数据世界的一部分，从某种程度上说，如果我们不采取更激进的节约资源的机制，我们通过数字化、智能化创造的社会效益，可能会为其环境压力所抵消，甚至更糟。

### 而火山引擎的“并池”做法的社会意义在于，通过对技术的极致追求，实现了资源的最大化可复用，从而为我们探索一个更富有共享精神和集约效益的未来，创造了一个具有精神象征意义的里程碑，其动机可能是商业的，但其效益是社会的。 ###

--------------------

## 字节-抖音-火山，技术篇 ##

*  字节跳动内部一直在践行**技术中台的技术文化**。让技术中台直接实现自身产品的商业化。比如说推荐，用的就是今日头条、抖音的同款推荐平台、工具和方法论。通过这种方式，我们可以把内部最好的能力对外进行服务。
 *  火山引擎整体的产品技术体系，一共分为四层，分别是：**统一基础服务、技术中台、智能应用和行业解决方案**。这四层从下至上，分别满足企业从运维、研发、产品、运营到营销，在不同行业、不同业务场景下的需求。
 *  \*\*构建数据驱动的飞轮。\*\*数据驱动就会成为日常内部协同的习惯，最终成为业务增长的源动力。建设飞轮分为四个关键步骤，**业务过程数字化、数字化协同、数据驱动业务优化、客观的分析评估。**
 *  在**数据驱动、敏捷开发**两方面技术实践的概括与分享，详见下文图表。

--------------------

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

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

以下为谭待的演讲实录：

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

**火山引擎是企业的数字化增长引擎**

在开始分享之前，我先向大家介绍一下火山引擎。

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

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

![img][img 2]

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

这是过去一年里，我们不断把字节跳动内部技术商业化后形成的结果，而在这个过程中我们一直在思考，字节跳动是怎么一步一步发展至今的，这背后支撑着业务快速发展的技术理念是什么？今天我想和大家分享下我的理解，我认为在这个过程中，有两大理念非常重要，分别是：数据驱动、敏捷开发。

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

首先和大家聊聊数据驱动。亚马逊有一个著名的飞轮理论：一个公司各个业务模块之间应当有机地组合，相互推动，就像是咬合的齿轮一样。每一个飞轮从静止到转动起来需要花费力气，但是由于他们组合在一起，所以每一圈的转动都不会白费。一旦有一个齿轮转动起来，整个系统都会跟着转动，越转越快。

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

回到数据驱动这个话题，我们认为同样如此。数据驱动不是一蹴而就的，不是用了一个工具，或者说建了几张报表就做起来了，而是在整个过程中，不停地去解决一个个问题，最终形成多个体系，让他自动转起来，形成数据的飞轮效应。一旦飞轮效应形成，越到后面转得越快。数据驱动就会成为日常内部协同的习惯，最终成为业务增长的源动力。

![在这里插入图片描述][cf609431271d47a6b3c284b1cf59d7cb.png]

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

这几个步骤之间是一个有机推动的过程：

**业务过程的数字化**是第一步，也是非常关键的一步。业务过程的数字化越充分，对业务的描述就越精准，才能有利于后面步骤的展开。所以，我们需要不断地将离线活动在线化，在线活动精细化，全部通过数字化的方式进行表达。

实现了业务过程的数字化之后，第二步就是 **数字化协同**。第一要通过数据治理等手段让底层数据得到规范、统一的表达。第二是要让更多的人参与进来，所以需要通过数据可视化等工具让不同的角色（开发人员、运营人员、使用人员、管理者等等）使用起来，加入数字化协同的过程。

数字化协同能力，最直接的影响是效率的提升。协同得越好，就能越及时、全面地获取业务的认知，也就能在数据上更客观地支持上层业务的 **优化**。

优化的效果一定不是拍脑袋，也不是凭感觉，而是用 **客观的分析评估**。一方面，可以用A/B测试等方式通过数据来精准评估业务带来的实际收益，另一方面，我们也要进一步多维度的关联原因。

最后，走完这四步后，在业务优化和评估过程中，我们又能沉淀更多的数据，这就形成了闭环，实现了飞轮的转动。

**字节的数据驱动飞轮**

刚刚是一个偏抽象的描述，下面我们再结合字节跳动的具体情况来看：

*  业务过程数字化，主要是对于不同触点的数据埋点，比如APP、小程序、运营页等等；
 *  数字化协同，是多角色对数据应用的协同加工。比如研发如何做好数据开发、数据治理，运营更好更快的用好数据等；
 *  数字驱动业务优化，主要是根据数据，根据数据产生的insights，对产品、算法进行优化，比如对推荐系统策略的优化，面向不同用户群体运营的优化等；
 *  客观的分析评估，一方面通过A/B测试，对不同的、新的迭代进行客观评估，另一方面则是通过ABI进一步地进行数据洞察，能够积累对于的insights，从而促进整个流程的转动。

这就是字节跳动构建整个数据驱动飞轮的过程，在这个过程中，我们把“业务过程数字化”、“数字化协同”、“客观的分析评估”这三个沉淀下来，固化成数据中台统一的能力，去支持不同应用的数据优化，同时中台能力，还能对业务不同维度，包括增长、体验、变现等等实现进一步的优化。

下面我们就数据中台和应用优化，进行展开。

**面向应用的数据中台**

![在这里插入图片描述][58623bebe0264eb5a15717ecbf788208.png]

刚才其实也提到了数据中台，它最大的一个作用是帮助各个应用、业务基于数据驱动进行优化。所以做数据中台有一个很重要的理念，那就是一定要面向应用来构建。从数据开始，用数据来做验证。那么谈到数据的验证，那最重要的其实就是A/B测试。之前我们也在不同场合强调过字节对于A/B测试的重视，包括抖音、头条的起名也是通过A/B测试得来的。

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

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

所以可以说在底层，我们更关注数据开发的效率和规模，而在上层，我们关注的是整个产品和运营在做数据分析过程中的易用性、可交互性。要实现易用性、可交互性和底层规模和效率的一个连接，我们需要一个非常强大的数据分析引擎，那就是我们的ByteHouse。

![在这里插入图片描述][529db7451c97430091468f029b0c93f1.png]

ByteHouse起源于开源的clickhouse项目，所以有了House的后缀。但它其实是根据字节跳动大规模数据场景，进行了非常多的需求改造，最终形成的一个云原生的大规模数据分析平台。

刚刚提到，数据驱动是字节跳动的重要技术理念，每天我们有数十PB的新增数据，有数万多人要从各种维度各种细节，对这些数据进行分析。这里面就有很多性能问题、实时问题需要解决，背后就是靠ByteHouse支持的。

目前为止，ByteHouse几乎服务于字节内所有的业务线，也是ABI系统、UBA系统、画像系统、A/B测试等分析系统的核心引擎。整体规模达到了三万台服务器，每天查询有几千万次。

![在这里插入图片描述][cfe7d8bcd09c4cf5a530ef12f07c6012.png]

面对刚才说的大规模挑战，我们在ByteHouse上主要做了五个层次的深度改造：

第一是支持流式数据。对分析而言，我们对实时性的要求非常高，所以我们通过Kafka支持了对实时数据的处理。这样通过ByteHouse可以实现对实时和离线的数据提供统一的分析平台，支持批流一体。

第二是计算和存储的分离。因为我们的规模实在太大了，如何在数十PB新增数据基础上，支持数万人，高效快速地做千万次的即时查询，是一个很大的挑战。通过计算和存储的分离，我们能更好地解决性能问题。分离之后，计算层可以单独地进行弹性的扩缩容。在存储一块，可以和分布式存储系统进行对接，包括HDFS、S3等等。这样一方面能解决存储的稳定性问题，另一方面也能解决扩容问题。

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

最后一个很重要的是我们做了多级的资源隔离。因为每天有不同的部门、角色在做各种各样的分析，那么权限、时效性的要求都不一样。那么通过租户的隔离、读写的分离以及异构的计算资源，就能很好地满足不同部门、不同角色在大规模集中式地使用资源分配的问题。

通过以上这五个大的层次上优化，所以我们能够基于ByteHouse去支撑起整个字节跳动数据驱动里的核心步骤。

**应用优化**

![在这里插入图片描述][fa8ccac3319946ff940d77bf242fc105.png]

刚才讲了数据中台的一些实践，接下来再讲讲怎么去通过数据驱动来做应用和业务的优化。这里以增长获客来举例。

当然不管是增长场景还是其他场景，如果要做好数据驱动优化，首先最关键的就是设计好指标体系。因为指标不对，做的再多都是错的。

那么对于增长而言，我们认为最重要的有两个指标——「正向的投入产出」和「健康的用户规模」。

正向的投入产出，简单来说就是ROI>1。看起来非常简单，但怎么把ROI算对、算准以及精细到每个用户粒度跟进长期的 ROI，其实是难点和关键。

当然我们也不能只看短期的ROI，还要看长期的用户的健康度，包括留存，LT等等。

设定了这些关键指标之后，其实就可以通过指标去找到对应的优化增长策略。这个增长策略不仅要满足指标的正向，同时也要具备可持续、可规模化、可复制的模式。这样就把业务的增长模式转化成了可衡量、可跟踪的数据驱动模式。

最后用一张图去完整地阐述数据驱动、基于中台和应用优化，来构建整体飞轮的案例。

*  首先基于数据做用户定向，定义好目标，找到对产品最关键的人群；
 *  找到之后，去做对应的创意、内容，然后让这些最优质最吸引的内容在不同渠道触达到客户，形成转换并产生新的数据。而且我们有数字化记录的过程，能够准确地归因，精细化地追踪效果；
 *  在优化过程中，会有很多创意。我们通过A/B测试高速迭代，看看哪个创意更合适。而在评估的过程中，也会出现更多的数据，从而又补充了整个策略方案，最终就形成一个数据驱动的增长飞轮。

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

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

说到敏捷开发，我们可以看到市面各种各样不同层次的解决方案，比如说低代码，aPaaS等等。不过今天主要想和大家聊的还是云原生这块，因为无论是SaaS层还是PaaS层的方案，在底层都离不开一整套云原生架构的支持。

**字节跳动全栈云原生化架构**

![在这里插入图片描述][e7f51465289e446798ecbd9c62a897d2.png]

这里也简单回顾下云基础技术的发展历史，相信很多人也比较熟悉这段轨迹了。可以看到，13年是一个重要的拐点。13年之后，随着Docker、K8s等技术的兴起和普及，云从 **以基础设施为中心，走向以应用为中心；从资源服务化走向平台服务化，而字节跳动刚好诞生在2012年，因此非常幸运没有什么历史包袱，直接拥抱了最新的云原生技术。**

![在这里插入图片描述][26db35b19ca94fa29a1d39487e80cd07.png]

给大家分享一组数字（2021年2月份统计）：字节跳动内部业务中，服务器的节点数近百万；同时在线的微服务数有8w+，并且在以每月2000的数量增长；容器数750w+；每日新增量60多PB。

从这些数字大家也可以看得出，我们面临的是一个非常大规模的，而且还在不断快速上涨的服务体量的挑战。所以从基础架构的视角，我们认为有三个方面的问题需要考虑：

**第一是如何支撑海量服务**。随着应用微服务化，治理对象由单体应用转变为数量更庞大的微服务，这导致全局治理难度更加大，包括构建全局的配置中心以及更灵活的全局网络、运行时的选择、配备完善的安全机制，以及如何端到端的和整个DevOps流程进行打通。

**第二是在大规模调度运维下的挑战，如何让基础设施更加稳定**。目前内部平均单集群规模是5000多节点，大的集群有数万台。在这么大体量的情况下，需要考虑各种各样的问题，比如在大规模镜像分发的场景下，怎么做镜像预热、多集群的联邦管理的问题；在弱网环境下，云边协同的问题；在异构的环境下，机器学习的场景里面的GPU调度问题。

**第三，是在线/离线的混部**。因为这么大的规模，成本自然也很大，所以我们要做好利用率的提升。在线/离线的混部是非常重要的手段。特别是字节跳动业务本身，其实波峰和波谷都很明显。比如抖音高的峰值就在晚上，其他时候的QPS就没有这么高。所以我们设计了一套在线/离线混部的机制，一方面可以降低成本，一方面能够更好地应对极端情况下业务规模增长的难题。

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

在多云方面，我们不仅计算能够做到多云，有状态的存储也能够做到多云，这样我们就能够非常灵活的去应对各种的突发情况，比如年初的春晚抢红包，以及818新潮购物节等等。

![在这里插入图片描述][ffaaf0e414424a83b461abcb65161ed4.png]

这张图从架构体系角度，进一步来阐释全栈云原生的体系结构。

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

在云原生基础之上是服务平台层，它要解决的是业务开发中的一些通用平台和服务能力的抽象。这里面包含了高性能的微服务框架、基于服务网格的微服务治理能力，以及Serverless、边缘计算平台的能力。服务平台构建就是为了让开发人员更敏捷、专注地开发业务逻辑，而能更少地考虑资源、平台、服务间通信和治理。

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

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

第一个是云原生安全的体系。那么相比传统的安全体系，它要做到不同层次的延伸，一个是左延，不仅关注运行时的安全，我们也需要和DevOps的流程结合在一起，去关注应用整个生命周期的安全。第二个就是下延，不仅只关注到容器的安全，还要关注到主机的安全。

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

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

**服务器端——微服务、服务治理与DevOps**

![在这里插入图片描述][ff679646e0a040faa959023b2b4d6e9e.png]

首先来看微服务。我们可以用四个点来形容字节跳动微服务的现状：

**规模庞大且增长迅速**。刚才介绍过字节跳动现在的微服务数是8万，但在2018年，整个微服务数大概只有7000到8000，所以三年其实翻了近10倍，并且还在不断的增长。在这个过程中，我们自然遇到了非常多的挑战。

**在线微服务超过90％都运行在容器里**。对于业务线，是看不到资源的，看到的只是PaaS、容器。这带来很多便利性，有利于新技术的核心功能推广，但同时也有很多挑战，尤其是调度复杂性这方面。

**技术体系以Golang语言为主**。根据最新的调查统计，字节跳动内部Golang是主要语言，超过55％的服务都采用了Golang，排名第二的语言是NodeJS，然后是其他的语言。

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

大家可以发现整个字节跳动在微服务的使用上是非常快的，甚至可以说是比较激进的。这背后，是因为在字节跳动，速度和效率是我们研发要解决的Top1问题。每天新应用和新用户增长都非常快，研发必须要解决好产能问题。这也是我们激进地采取微服务架构的原因。但这么大的规模下，做这么快的迭代，自然会对稳定性、信任带来非常大的冲击。

![在这里插入图片描述][5d6004f418f44d249248ad56a89e6313.png]

为了应对这些困难和矛盾，我们在端到端落地微服务架构时，针对性地做了各项优化：

首先是语言层面， **Golang**是主力使用的语言，因此在Golang层面做了很多框架层面的优化，比如RPC框架、HTTP框架。这些框架我们已经通过开源的方式回馈到社区——9月初，字节跳动开源CloudWeGo，帮助更多开发者搭建云原生微服务架构。

第二则是针对海量服务的治理，我们基于 **ServiceMesh**的概念构建了自己的服务网格体系，将服务治理的能力固化到字节内部平台上，一方面帮助我们多元多服务的兼容问题，另一方面通过Golang稳定的框架和以Mesh治理为基础的理念，我们实现了全局 **流量的治理、单元化和体系化**的整体建设。

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

![在这里插入图片描述][4c6f58175287462db399e6de3b9d885b.png]

下面我们就一个个展开。

首先是Golang框架这块，一个是Kitex，这是RPC的框架。另一个是Hertz，是HTTP的框架。这些框架背后集成了我们自研的高性能的网络库，去解决网络上的一些性能、交互上的问题。同时我们支持多消息协议（Thrift/Protobuf）和多交互方式（Ping-Pong/Oneway/Streaming），能提供更加灵活自主的代码生成器。

![在这里插入图片描述][d8a924ce9900453fbc40e68579a7f267.png]

这是Kitex和gRPC性能的对比，我们选了两组，分别是基于Thrift和Protobuf协议的对比。可以看到在两种方式下，Kitex都有比较好的性能表现。特别是在在TP99延迟上，随着并发连接数的增大，Kitex表现出的优势是越来越大。

![在这里插入图片描述][0b387fb6042046538a4fcaed2c79418a.png]

这是Hertz和业界一些框架的对比，包括平均时延、QPS，以及在不同Size包的情况下的对比结果。这两个框架我们现在都通过开源的方式在对外提供，所以欢迎各位开发者去下载使用，和我们交流，提供意见。

![在这里插入图片描述][21fa27f4db3a45f38d4bbec26359f5f9.png]

接下来我们看服务网格的治理。刚才谈到过因为本身的业务类型、业务体量，所以我们在实践微服务的架构中，面临着非常多挑战，比如语言碎片化、服务异构、协议异构，还有安全、可观测性、问题追查调用等等。所以我们采取了基于服务网格模式，来进行整体的微服务治理。

上图绿色方框是控制面，虚框是数据面。我们通过服务网格将控制平面和数据平面进行了分离，消除了单点故障的可能。比如当数据平面流量过大出现性能问题时，就不会影响到控制平面的路由策略；反过来也是，当控制平面策略负载过重时也不会影响数据平面的转发。

图中每个虚框是一个pod，与传统的服务相比，我们的服务网格是通过sidecar方式进行流量治理，比如熔断、限流、超时重试、降低等，把这些功能从每个服务中剥离出来形成一个代理，通过这些代理实现服务间的治理。这样的好处是能够让每个服务只关注自己的业务逻辑，不需要管全局的调度和通讯问题，让开发更简单、高效。

![在这里插入图片描述][d32ac861a6aa4d6dba44b2e919c3f193.png]

当然这种ServiceMesh无侵入性的模式带来了很多便利，但是实际上也带来了很多挑战。最大一个挑战就是额外的性能开销，所以我们做了大量的工作去解决服务网格的极致性能优化。这样的一个优化是多个层次的：

在网络和内核层面，我们用共享内存或者系统调用的方式来实现真正的zero copy。

也会在基础库、组件架构层面的优化，去除一些不必要的交互。甚至在编译阶段，我们通过更好的全静态的编译，不需要任何代码的修改，就能够获得2%左右的性能提升。

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

**移动端——极致体验的移动APP研发**

刚才讲的是微服务框架和服务治理的内容，接下来我们再来说一说移动开发。

对于字节来说，可以算是一个移动原生的企业，我们绝大部分的业务也都是通过APP在承载的。截止目前，我们已经运营超过100款APP，公司内部也有数千人的移动应用研发团队。

要支撑如此大规模的研发团队和对应业务的发展，我们必须建立一套行业领先的移动应用开发平台，并且要通过大量的实践和各种极端场景的打磨来不断优化。因此我们很早就建立了公司级的移动研发平台，代号：MARS，通过它来统一支撑上层各个业务应用的开发工作。如今大家在用的抖音、头条等APP都是基于MARS进行开发和迭代。

从层次角度，MARS整体可以分为5个板块：

1.  首先是项目管理，通过抽象字节内部的研发特点，我们建立了统一的项目管理平台用于支撑日常业务迭代管理，特别是发版等特殊流程的优化。
2.  其次在应用开发环节，这一步效率是很关键的，我们针对效率采用低代码的方式来进行进一步的提升。比如针对设计人员提供了通过设计直接生成代码的方式。对于运营人员、研发人员，我们采取了这种可见即可得的方式，通过拖拉拽去帮助业务人员能更容易更便捷地构建业务应用。
3.  然后面向传统的编码和研发阶段，我们面向APP、前端以及小程序等不同的端都输出了一套完整的端到端的开发平台。
4.  另外在质量管控，我们也提供了一站式全链路测试平台，基于海量真机真实模拟线上实际场景，最大限度检测潜在异常。
5.  最后是全链路监控平台，能够覆盖“终端-网络-后台应用-基础环境”的完整应用链路监控，帮助研发人员精准定位问题，解决问题。

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

回到今天分享的主题，在整个字节技术发展的背后，数据驱动和敏捷开发是两个重要的理念，但这两个理念并不是割裂的，二者是一体的。因为对于数据驱动而言，我们需要有更多的实验，来找到好的方案进行推广，找到不好的点进行改进。而敏捷开发就能保证每天都有大量的实验能够进行。反过来通过数据驱动，我们又能够去找到里面有价值的东西，同时也能沉淀更多的数据，这样就构建了整个业务高速发展的闭环。

![在这里插入图片描述][7eff09f768ed40b0bf4ce3eaaddc6d17.png]

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

而我们底层的技术、平台的技术，还有业务层的技术，也正是因为这两个理念在不断的积累和迭代，最终去推动业务的高速发展。

其实道理非常简单，就像大家说天下武功唯快不破一样，道理都是很简单的道理，但是要做好这些事情的背后，我们需要工具平台和方法的不断积累，以及把这些方法形成日常的习惯，最终形成业务推动的原动力。

以上就是我对字节跳动在数据驱动、敏捷开发两方面技术实践的概括与分享。希望对大家有所启发。里面提到的很多技术，基本都在火山引擎上实现了对外产品化，也非常期待大家能使用这些产品，反馈意见，创造更大价值。

[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/3354608261a547bcad21ada9b22f9422.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/baf95e681bc0425dbd7075dcc603afcf.png
[img 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/ea0902c4a3f443a5be3f504de11388c9.png
[cf609431271d47a6b3c284b1cf59d7cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/c673d7a2a60b4b61aab32dafe0340445.png
[58623bebe0264eb5a15717ecbf788208.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/9c88cef4d6fa4b60b6690eddba269134.png
[529db7451c97430091468f029b0c93f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/02c45e66196b4331891fe7af7e26bce8.png
[cfe7d8bcd09c4cf5a530ef12f07c6012.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/87dd5d577c1d48e19b8ac4c1f02b8dac.png
[fa8ccac3319946ff940d77bf242fc105.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/4c55d8f187dc4cff932b95998db27104.png
[e7f51465289e446798ecbd9c62a897d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/a83684edccbf4d958794320d10ab0889.png
[26db35b19ca94fa29a1d39487e80cd07.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/a3b1f3c3c0ac432999ac1976fe2e1e7e.png
[ffaaf0e414424a83b461abcb65161ed4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/8fe170a5b1ac4ad68c8cf93d582790e9.png
[ff679646e0a040faa959023b2b4d6e9e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/dd886f9bf6064facac07936dc6efb732.png
[5d6004f418f44d249248ad56a89e6313.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/4296332f334c4bada7b0f141eabe9a60.png
[4c6f58175287462db399e6de3b9d885b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/85de0874a3ce4b95859c754716678779.png
[d8a924ce9900453fbc40e68579a7f267.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/6f405fbf6d0e4aec94abc89d78301169.png
[0b387fb6042046538a4fcaed2c79418a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/e655115892a3469f8bdb8215d21716eb.png
[21fa27f4db3a45f38d4bbec26359f5f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/b1c9ded31e674d489f85dde0f0368061.png
[d32ac861a6aa4d6dba44b2e919c3f193.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/56a19da5573c452a9a7987d2819163c0.png
[7eff09f768ed40b0bf4ce3eaaddc6d17.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/39c97013b14f41f384e502f241ee5f69.png