火山引擎是企業(yè)的數(shù)字化增長引擎

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

　　火山引擎是字節(jié)跳動旗下的企業(yè)級技術(shù)服務(wù)平臺,，是字節(jié)跳動技術(shù)團(tuán)隊對外提供技術(shù)服務(wù)的統(tǒng)一窗口,，我們希望通過火山引擎，把字節(jié)跳動的技術(shù),、產(chǎn)品和服務(wù)對外開放,，包括云、AI,、大數(shù)據(jù),、推薦等等，來幫助不同行業(yè)中的企業(yè)實現(xiàn)自身增長和數(shù)字化轉(zhuǎn)型,。

　　大家知道,，字節(jié)跳動內(nèi)部一直在踐行技術(shù)中臺的技術(shù)文化。所以我們在做技術(shù)ToB過程中,，也采取了這種機(jī)制,，讓技術(shù)中臺直接實現(xiàn)自身產(chǎn)品的商業(yè)化。因此,，火山引擎對外開放的技術(shù)和工具,，與字節(jié)跳動技術(shù)中臺完全同源。比如說推薦,，用的就是今日頭條,、抖音的同款推薦平臺、工具和方法論,。通過這種方式,，我們可以把內(nèi)部最好的能力對外進(jìn)行服務(wù)。

　　這是火山引擎整體的產(chǎn)品技術(shù)體系,，一共分為四層,，分別是：統(tǒng)一基礎(chǔ)服務(wù)、技術(shù)中臺,、智能應(yīng)用和行業(yè)解決方案,。這四層從下至上，分別滿足企業(yè)從運(yùn)維,、研發(fā),、產(chǎn)品,、運(yùn)營到營銷，在不同行業(yè),、不同業(yè)務(wù)場景下的需求,。

　　這是過去一年里，我們不斷把字節(jié)跳動內(nèi)部技術(shù)商業(yè)化后形成的結(jié)果,，而在這個過程中我們一直在思考,，字節(jié)跳動是怎么一步一步發(fā)展至今的，這背后支撐著業(yè)務(wù)快速發(fā)展的技術(shù)理念是什么,？今天我想和大家分享下我的理解,，我認(rèn)為在這個過程中，有兩大理念非常重要,，分別是：數(shù)據(jù)驅(qū)動,、敏捷開發(fā)。

　　數(shù)據(jù)驅(qū)動：構(gòu)建數(shù)據(jù)驅(qū)動的飛輪

　　首先和大家聊聊數(shù)據(jù)驅(qū)動,。亞馬遜有一個著名的飛輪理論：一個公司各個業(yè)務(wù)模塊之間應(yīng)當(dāng)有機(jī)地組合,，相互推動，就像是咬合的齒輪一樣,。每一個飛輪從靜止到轉(zhuǎn)動起來需要花費(fèi)力氣,，但是由于他們組合在一起，所以每一圈的轉(zhuǎn)動都不會白費(fèi),。一旦有一個齒輪轉(zhuǎn)動起來,，整個系統(tǒng)都會跟著轉(zhuǎn)動，越轉(zhuǎn)越快,。

　　構(gòu)建數(shù)據(jù)驅(qū)動的飛輪

　　回到數(shù)據(jù)驅(qū)動這個話題,，我們認(rèn)為同樣如此。數(shù)據(jù)驅(qū)動不是一蹴而就的,，不是用了一個工具,，或者說建了幾張報表就做起來了，而是在整個過程中,，不停地去解決一個個問題,，最終形成多個體系，讓他自動轉(zhuǎn)起來,，形成數(shù)據(jù)的飛輪效應(yīng),。一旦飛輪效應(yīng)形成，越到后面轉(zhuǎn)得越快,。數(shù)據(jù)驅(qū)動就會成為日常內(nèi)部協(xié)同的習(xí)慣,，最終成為業(yè)務(wù)增長的源動力。

　　圍繞這一目標(biāo)，我們可以把建設(shè)飛輪分為四個關(guān)鍵步驟,，業(yè)務(wù)過程數(shù)字化,、數(shù)字化協(xié)同、數(shù)據(jù)驅(qū)動業(yè)務(wù)優(yōu)化,、客觀的分析評估,。

　　這幾個步驟之間是一個有機(jī)推動的過程：

　　業(yè)務(wù)過程的數(shù)字化是第一步，也是非常關(guān)鍵的一步,。業(yè)務(wù)過程的數(shù)字化越充分,，對業(yè)務(wù)的描述就越精準(zhǔn)，才能有利于后面步驟的展開,。所以，我們需要不斷地將離線活動在線化,，在線活動精細(xì)化,，全部通過數(shù)字化的方式進(jìn)行表達(dá)。

　　實現(xiàn)了業(yè)務(wù)過程的數(shù)字化之后,，第二步就是數(shù)字化協(xié)同,。第一要通過數(shù)據(jù)治理等手段讓底層數(shù)據(jù)得到規(guī)范、統(tǒng)一的表達(dá),。第二是要讓更多的人參與進(jìn)來,，所以需要通過數(shù)據(jù)可視化等工具讓不同的角色（開發(fā)人員、運(yùn)營人員,、使用人員,、管理者等等）使用起來，加入數(shù)字化協(xié)同的過程,。

　　數(shù)字化協(xié)同能力,，最直接的影響是效率的提升。協(xié)同得越好,，就能越及時,、全面地獲取業(yè)務(wù)的認(rèn)知，也就能在數(shù)據(jù)上更客觀地支持上層業(yè)務(wù)的優(yōu)化,。

　　優(yōu)化的效果一定不是拍腦袋,，也不是憑感覺，而是用客觀的分析評估,。一方面,，可以用A/B測試等方式通過數(shù)據(jù)來精準(zhǔn)評估業(yè)務(wù)帶來的實際收益，另一方面,，我們也要進(jìn)一步多維度的關(guān)聯(lián)原因,。

　　最后，走完這四步后，在業(yè)務(wù)優(yōu)化和評估過程中,，我們又能沉淀更多的數(shù)據(jù),，這就形成了閉環(huán)，實現(xiàn)了飛輪的轉(zhuǎn)動,。

　　剛剛是一個偏抽象的描述,，下面我們再結(jié)合字節(jié)跳動的具體情況來看：

　　業(yè)務(wù)過程數(shù)字化，主要是對于不同觸點(diǎn)的數(shù)據(jù)埋點(diǎn),，比如APP,、小程序、運(yùn)營頁等等,；

　　數(shù)字化協(xié)同,，是多角色對數(shù)據(jù)應(yīng)用的協(xié)同加工。比如研發(fā)如何做好數(shù)據(jù)開發(fā),、數(shù)據(jù)治理,，運(yùn)營更好更快的用好數(shù)據(jù)等；

　　數(shù)字驅(qū)動業(yè)務(wù)優(yōu)化,，主要是根據(jù)數(shù)據(jù),，根據(jù)數(shù)據(jù)產(chǎn)生的insights，對產(chǎn)品,、算法進(jìn)行優(yōu)化,，比如對推薦系統(tǒng)策略的優(yōu)化，面向不同用戶群體運(yùn)營的優(yōu)化等,；

　　客觀的分析評估,，一方面通過A/B測試，對不同的,、新的迭代進(jìn)行客觀評估,，另一方面則是通過ABI進(jìn)一步地進(jìn)行數(shù)據(jù)洞察，能夠積累對于的insights,，從而促進(jìn)整個流程的轉(zhuǎn)動,。

　　這就是字節(jié)跳動構(gòu)建整個數(shù)據(jù)驅(qū)動飛輪的過程，在這個過程中,，我們把“業(yè)務(wù)過程數(shù)字化”,、“數(shù)字化協(xié)同”、“客觀的分析評估”這三個沉淀下來,，固化成數(shù)據(jù)中臺統(tǒng)一的能力,，去支持不同應(yīng)用的數(shù)據(jù)優(yōu)化，同時中臺能力,，還能對業(yè)務(wù)不同維度,，包括增長,、體驗、變現(xiàn)等等實現(xiàn)進(jìn)一步的優(yōu)化,。

　　下面我們就數(shù)據(jù)中臺和應(yīng)用優(yōu)化,，進(jìn)行展開。

　　面向應(yīng)用的數(shù)據(jù)中臺

　　剛才其實也提到了數(shù)據(jù)中臺,，它最大的一個作用是幫助各個應(yīng)用,、業(yè)務(wù)基于數(shù)據(jù)驅(qū)動進(jìn)行優(yōu)化。所以做數(shù)據(jù)中臺有一個很重要的理念,，那就是一定要面向應(yīng)用來構(gòu)建,。從數(shù)據(jù)開始，用數(shù)據(jù)來做驗證,。那么談到數(shù)據(jù)的驗證,，那最重要的其實就是A/B測試。之前我們也在不同場合強(qiáng)調(diào)過字節(jié)對于A/B測試的重視,，包括抖音,、頭條的起名也是通過A/B測試得來的。

　　對于評估而言,，測試只是第一步，我們還需要進(jìn)一步對結(jié)果進(jìn)行分析,，因此構(gòu)建了相應(yīng)的數(shù)據(jù)運(yùn)營平臺,、智能數(shù)據(jù)洞察和客戶數(shù)據(jù)平臺等工具，幫助產(chǎn)品和運(yùn)營可以深入分析數(shù)據(jù),。

　　而在底層,，面向每天產(chǎn)生的大規(guī)模、批量,、實時的數(shù)據(jù),，我們也建設(shè)了一套完整的數(shù)據(jù)采集、研發(fā)和治理的套件,，提升數(shù)據(jù)開發(fā)的效率,。

　　所以可以說在底層，我們更關(guān)注數(shù)據(jù)開發(fā)的效率和規(guī)模,，而在上層,，我們關(guān)注的是整個產(chǎn)品和運(yùn)營在做數(shù)據(jù)分析過程中的易用性、可交互性,。要實現(xiàn)易用性,、可交互性和底層規(guī)模和效率的一個連接，我們需要一個非常強(qiáng)大的數(shù)據(jù)分析引擎,，那就是我們的ByteHouse,。

　　ByteHouse起源于開源的clickhouse項目，所以有了House的后綴。但它其實是根據(jù)字節(jié)跳動大規(guī)模數(shù)據(jù)場景,，進(jìn)行了非常多的需求改造,，最終形成的一個云原生的大規(guī)模數(shù)據(jù)分析平臺。

　　剛剛提到,，數(shù)據(jù)驅(qū)動是字節(jié)跳動的重要技術(shù)理念,，每天我們有數(shù)十PB的新增數(shù)據(jù)，有數(shù)萬多人要從各種維度各種細(xì)節(jié),，對這些數(shù)據(jù)進(jìn)行分析,。這里面就有很多性能問題、實時問題需要解決,，背后就是靠ByteHouse支持的,。

　　目前為止，ByteHouse幾乎服務(wù)于字節(jié)內(nèi)所有的業(yè)務(wù)線,，也是ABI系統(tǒng),、UBA系統(tǒng)、畫像系統(tǒng),、A/B測試等分析系統(tǒng)的核心引擎,。整體規(guī)模達(dá)到了三萬臺服務(wù)器，每天查詢有幾千萬次,。

　　面對剛才說的大規(guī)模挑戰(zhàn),，我們在ByteHouse上主要做了五個層次的深度改造：

　　第一是支持流式數(shù)據(jù)。對分析而言,，我們對實時性的要求非常高,，所以我們通過Kafka支持了對實時數(shù)據(jù)的處理。這樣通過ByteHouse可以實現(xiàn)對實時和離線的數(shù)據(jù)提供統(tǒng)一的分析平臺,，支持批流一體,。

　　第二是計算和存儲的分離。因為我們的規(guī)模實在太大了,，如何在數(shù)十PB新增數(shù)據(jù)基礎(chǔ)上,，支持?jǐn)?shù)萬人，高效快速地做千萬次的即時查詢,，是一個很大的挑戰(zhàn),。通過計算和存儲的分離，我們能更好地解決性能問題,。分離之后,，計算層可以單獨(dú)地進(jìn)行彈性的擴(kuò)縮容。在存儲一塊,，可以和分布式存儲系統(tǒng)進(jìn)行對接,，包括HDFS,、S3等等。這樣一方面能解決存儲的穩(wěn)定性問題,，另一方面也能解決擴(kuò)容問題,。

　　在計算和存儲的分離之外，我們在運(yùn)維,、安全方面做了很多工作,，以進(jìn)一步去彌補(bǔ)社區(qū)版本功能的缺失。

　　最后一個很重要的是我們做了多級的資源隔離,。因為每天有不同的部門,、角色在做各種各樣的分析，那么權(quán)限,、時效性的要求都不一樣,。那么通過租戶的隔離、讀寫的分離以及異構(gòu)的計算資源,，就能很好地滿足不同部門,、不同角色在大規(guī)模集中式地使用資源分配的問題。

　　通過以上這五個大的層次上優(yōu)化,，所以我們能夠基于ByteHouse去支撐起整個字節(jié)跳動數(shù)據(jù)驅(qū)動里的核心步驟,。

　　剛才講了數(shù)據(jù)中臺的一些實踐，接下來再講講怎么去通過數(shù)據(jù)驅(qū)動來做應(yīng)用和業(yè)務(wù)的優(yōu)化,。這里以增長獲客來舉例,。

　　當(dāng)然不管是增長場景還是其他場景，如果要做好數(shù)據(jù)驅(qū)動優(yōu)化,，首先最關(guān)鍵的就是設(shè)計好指標(biāo)體系,。因為指標(biāo)不對,，做的再多都是錯的,。

　　那么對于增長而言，我們認(rèn)為最重要的有兩個指標(biāo)——「正向的投入產(chǎn)出」和「健康的用戶規(guī)?！?。

　　正向的投入產(chǎn)出，簡單來說就是ROI>1,?？雌饋矸浅：唵危趺窗裄OI算對,、算準(zhǔn)以及精細(xì)到每個用戶粒度跟進(jìn)長期的 ROI,，其實是難點(diǎn)和關(guān)鍵。

　　當(dāng)然我們也不能只看短期的ROI,，還要看長期的用戶的健康度,，包括留存,，LT等等。

　　設(shè)定了這些關(guān)鍵指標(biāo)之后,，其實就可以通過指標(biāo)去找到對應(yīng)的優(yōu)化增長策略,。這個增長策略不僅要滿足指標(biāo)的正向，同時也要具備可持續(xù),、可規(guī)?；⒖蓮?fù)制的模式,。這樣就把業(yè)務(wù)的增長模式轉(zhuǎn)化成了可衡量,、可跟蹤的數(shù)據(jù)驅(qū)動模式。

　　最后用一張圖去完整地闡述數(shù)據(jù)驅(qū)動,、基于中臺和應(yīng)用優(yōu)化,，來構(gòu)建整體飛輪的案例。

　　首先基于數(shù)據(jù)做用戶定向,，定義好目標(biāo),，找到對產(chǎn)品最關(guān)鍵的人群；

　　找到之后,，去做對應(yīng)的創(chuàng)意,、內(nèi)容，然后讓這些最優(yōu)質(zhì)最吸引的內(nèi)容在不同渠道觸達(dá)到客戶,，形成轉(zhuǎn)換并產(chǎn)生新的數(shù)據(jù),。而且我們有數(shù)字化記錄的過程，能夠準(zhǔn)確地歸因,，精細(xì)化地追蹤效果,；

　　在優(yōu)化過程中，會有很多創(chuàng)意,。我們通過A/B測試高速迭代,，看看哪個創(chuàng)意更合適。而在評估的過程中,，也會出現(xiàn)更多的數(shù)據(jù),，從而又補(bǔ)充了整個策略方案，最終就形成一個數(shù)據(jù)驅(qū)動的增長飛輪,。

　　在這樣的過程里面,，實驗的速度是非常關(guān)鍵的。如果別人一天只能做10個實驗,，你能做100個,，那結(jié)果不言而喻。小到創(chuàng)意的實驗,，大到APP功能的迭代開發(fā),，速度在里面都起到非常大的作用,。而這就呼應(yīng)了我想講的第二個理念，敏捷開發(fā),。

　　敏捷開發(fā)：全棧云原生架構(gòu)支撐大規(guī)模應(yīng)用

　　說到敏捷開發(fā),，我們可以看到市面各種各樣不同層次的解決方案，比如說低代碼,，aPaaS等等,。不過今天主要想和大家聊的還是云原生這塊，因為無論是SaaS層還是PaaS層的方案,，在底層都離不開一整套云原生架構(gòu)的支持,。

　　字節(jié)跳動全棧云原生化架構(gòu)

　　這里也簡單回顧下云基礎(chǔ)技術(shù)的發(fā)展歷史，相信很多人也比較熟悉這段軌跡了,?？梢钥吹剑?3年是一個重要的拐點(diǎn),。13年之后,，隨著Docker、K8s等技術(shù)的興起和普及,，云從以基礎(chǔ)設(shè)施為中心,，走向以應(yīng)用為中心；從資源服務(wù)化走向平臺服務(wù)化,，而字節(jié)跳動剛好誕生在2012年,，因此非常幸運(yùn)沒有什么歷史包袱，直接擁抱了最新的云原生技術(shù),。

　　給大家分享一組數(shù)字（2021年2月份統(tǒng)計）：字節(jié)跳動內(nèi)部業(yè)務(wù)中,，服務(wù)器的節(jié)點(diǎn)數(shù)近百萬；同時在線的微服務(wù)數(shù)有8w+,，并且在以每月2000的數(shù)量增長,；容器數(shù)750w+；每日新增量60多PB,。

　　從這些數(shù)字大家也可以看得出,，我們面臨的是一個非常大規(guī)模的,，而且還在不斷快速上漲的服務(wù)體量的挑戰(zhàn),。所以從基礎(chǔ)架構(gòu)的視角，我們認(rèn)為有三個方面的問題需要考慮：

　　第一是如何支撐海量服務(wù),。隨著應(yīng)用微服務(wù)化,，治理對象由單體應(yīng)用轉(zhuǎn)變?yōu)閿?shù)量更龐大的微服務(wù)，這導(dǎo)致全局治理難度更加大,，包括構(gòu)建全局的配置中心以及更靈活的全局網(wǎng)絡(luò),、運(yùn)行時的選擇,、配備完善的安全機(jī)制，以及如何端到端的和整個DevOps流程進(jìn)行打通,。

　　第二是在大規(guī)模調(diào)度運(yùn)維下的挑戰(zhàn),，如何讓基礎(chǔ)設(shè)施更加穩(wěn)定。目前內(nèi)部平均單集群規(guī)模是5000多節(jié)點(diǎn),，大的集群有數(shù)萬臺,。在這么大體量的情況下，需要考慮各種各樣的問題,，比如在大規(guī)模鏡像分發(fā)的場景下,，怎么做鏡像預(yù)熱、多集群的聯(lián)邦管理的問題,；在弱網(wǎng)環(huán)境下,，云邊協(xié)同的問題；在異構(gòu)的環(huán)境下,，機(jī)器學(xué)習(xí)的場景里面的GPU調(diào)度問題,。

　　第三，是在線/離線的混部,。因為這么大的規(guī)模,，成本自然也很大，所以我們要做好利用率的提升,。在線/離線的混部是非常重要的手段,。特別是字節(jié)跳動業(yè)務(wù)本身，其實波峰和波谷都很明顯,。比如抖音高的峰值就在晚上,，其他時候的QPS就沒有這么高。所以我們設(shè)計了一套在線/離線混部的機(jī)制,，一方面可以降低成本,，一方面能夠更好地應(yīng)對極端情況下業(yè)務(wù)規(guī)模增長的難題。

　　同時,，在底層,，我們還構(gòu)建了一個容器+多云的整體解決方案。

　　在多云方面,，我們不僅計算能夠做到多云,，有狀態(tài)的存儲也能夠做到多云，這樣我們就能夠非常靈活的去應(yīng)對各種的突發(fā)情況,，比如年初的春晚搶紅包,，以及818新潮購物節(jié)等等。

　　這張圖從架構(gòu)體系角度,，進(jìn)一步來闡釋全棧云原生的體系結(jié)構(gòu),。

　　首先在最底層,，是一套完整的云原生基礎(chǔ)設(shè)施。通過統(tǒng)一的底層去提供新一代的高性能計算存儲和網(wǎng)絡(luò)的解決方案,，這其實是保證業(yè)務(wù)穩(wěn)定和敏捷的基石,。

　　在云原生基礎(chǔ)之上是服務(wù)平臺層，它要解決的是業(yè)務(wù)開發(fā)中的一些通用平臺和服務(wù)能力的抽象,。這里面包含了高性能的微服務(wù)框架,、基于服務(wù)網(wǎng)格的微服務(wù)治理能力，以及Serverless,、邊緣計算平臺的能力,。服務(wù)平臺構(gòu)建就是為了讓開發(fā)人員更敏捷、專注地開發(fā)業(yè)務(wù)邏輯,，而能更少地考慮資源,、平臺、服務(wù)間通信和治理,。

　　在平臺層之上是整個研發(fā)體系的構(gòu)建,。這一層我們是希望通過各種各樣的工具、流程機(jī)制和組織,，能夠去幫字節(jié)跳動靈活地支撐全部業(yè)務(wù)線的快速開發(fā)和開發(fā)管理工作,。

　　這中間三層設(shè)施的兩邊是重要的云原生安全體系和SRE服務(wù)支撐體系。

　　第一個是云原生安全的體系,。那么相比傳統(tǒng)的安全體系,，它要做到不同層次的延伸，一個是左延,，不僅關(guān)注運(yùn)行時的安全,，我們也需要和DevOps的流程結(jié)合在一起，去關(guān)注應(yīng)用整個生命周期的安全,。第二個就是下延,，不僅只關(guān)注到容器的安全，還要關(guān)注到主機(jī)的安全,。

　　第二個就是SRE體系,，它來支撐整個業(yè)務(wù)高速發(fā)展過程中的穩(wěn)定性。

　　因為時間有限,，我挑了兩個比較有意思的話題來進(jìn)一步的分享,。一個是微服務(wù)，一個是移動開發(fā),。一方面比較有代表性,，另一方面這兩者覆蓋了大部分業(yè)務(wù)研發(fā)的場景,。

　　服務(wù)器端——微服務(wù),、服務(wù)治理與DevOps

　　首先來看微服務(wù),。我們可以用四個點(diǎn)來形容字節(jié)跳動微服務(wù)的現(xiàn)狀：

　　規(guī)模龐大且增長迅速。剛才介紹過字節(jié)跳動現(xiàn)在的微服務(wù)數(shù)是8萬,，但在2018年,，整個微服務(wù)數(shù)大概只有7000到8000，所以三年其實翻了近10倍,，并且還在不斷的增長,。在這個過程中，我們自然遇到了非常多的挑戰(zhàn),。

　　在線微服務(wù)超過90％都運(yùn)行在容器里,。對于業(yè)務(wù)線，是看不到資源的,，看到的只是PaaS,、容器。這帶來很多便利性,，有利于新技術(shù)的核心功能推廣,，但同時也有很多挑戰(zhàn)，尤其是調(diào)度復(fù)雜性這方面,。

　　技術(shù)體系以Golang語言為主,。根據(jù)最新的調(diào)查統(tǒng)計，字節(jié)跳動內(nèi)部Golang是主要語言,，超過55％的服務(wù)都采用了Golang,，排名第二的語言是NodeJS，然后是其他的語言,。

　　Service Mesh的全面落地和應(yīng)用,。字節(jié)跳動是國內(nèi)最早在生產(chǎn)環(huán)節(jié)大規(guī)模使用Service Mesh的公司之一。

　　大家可以發(fā)現(xiàn)整個字節(jié)跳動在微服務(wù)的使用上是非?？斓?，甚至可以說是比較激進(jìn)的。這背后,，是因為在字節(jié)跳動,，速度和效率是我們研發(fā)要解決的Top1問題。每天新應(yīng)用和新用戶增長都非?？?，研發(fā)必須要解決好產(chǎn)能問題。這也是我們激進(jìn)地采取微服務(wù)架構(gòu)的原因,。但這么大的規(guī)模下,，做這么快的迭代，自然會對穩(wěn)定性、信任帶來非常大的沖擊,。

　　為了應(yīng)對這些困難和矛盾,，我們在端到端落地微服務(wù)架構(gòu)時，針對性地做了各項優(yōu)化：

　　首先是語言層面,，Golang是主力使用的語言,，因此在Golang層面做了很多框架層面的優(yōu)化，比如RPC框架,、HTTP框架,。這些框架我們已經(jīng)通過開源的方式回饋到社區(qū)——9月初，字節(jié)跳動開源CloudWeGo,，幫助更多開發(fā)者搭建云原生微服務(wù)架構(gòu),。

　　第二則是針對海量服務(wù)的治理，我們基于ServiceMesh的概念構(gòu)建了自己的服務(wù)網(wǎng)格體系,，將服務(wù)治理的能力固化到字節(jié)內(nèi)部平臺上,，一方面幫助我們多元多服務(wù)的兼容問題，另一方面通過Golang穩(wěn)定的框架和以Mesh治理為基礎(chǔ)的理念,，我們實現(xiàn)了全局流量的治理,、單元化和體系化的整體建設(shè)。

　　最后是通過落地和實踐DevOps工具和方法來提升研發(fā)的效率,，進(jìn)一步提升運(yùn)維的可觀測性,。

　　下面我們就一個個展開。

　　首先是Golang框架這塊,，一個是Kitex,，這是RPC的框架。另一個是Hertz,，是HTTP的框架,。這些框架背后集成了我們自研的高性能的網(wǎng)絡(luò)庫，去解決網(wǎng)絡(luò)上的一些性能,、交互上的問題,。同時我們支持多消息協(xié)議（Thrift/Protobuf）和多交互方式（Ping-Pong/Oneway/Streaming），能提供更加靈活自主的代碼生成器,。

　　這是Kitex和gRPC性能的對比,，我們選了兩組，分別是基于Thrift和Protobuf協(xié)議的對比,?？梢钥吹皆趦煞N方式下，Kitex都有比較好的性能表現(xiàn),。特別是在在TP99延遲上,，隨著并發(fā)連接數(shù)的增大,，Kitex表現(xiàn)出的優(yōu)勢是越來越大。

　　這是Hertz和業(yè)界一些框架的對比,，包括平均時延,、QPS，以及在不同Size包的情況下的對比結(jié)果,。這兩個框架我們現(xiàn)在都通過開源的方式在對外提供,，所以歡迎各位開發(fā)者去下載使用,，和我們交流,，提供意見。

　　接下來我們看服務(wù)網(wǎng)格的治理,。剛才談到過因為本身的業(yè)務(wù)類型,、業(yè)務(wù)體量，所以我們在實踐微服務(wù)的架構(gòu)中,，面臨著非常多挑戰(zhàn),，比如語言碎片化、服務(wù)異構(gòu),、協(xié)議異構(gòu),，還有安全、可觀測性,、問題追查調(diào)用等等,。所以我們采取了基于服務(wù)網(wǎng)格模式，來進(jìn)行整體的微服務(wù)治理,。

　　上圖綠色方框是控制面,，虛框是數(shù)據(jù)面。我們通過服務(wù)網(wǎng)格將控制平面和數(shù)據(jù)平面進(jìn)行了分離,，消除了單點(diǎn)故障的可能,。比如當(dāng)數(shù)據(jù)平面流量過大出現(xiàn)性能問題時，就不會影響到控制平面的路由策略,；反過來也是,，當(dāng)控制平面策略負(fù)載過重時也不會影響數(shù)據(jù)平面的轉(zhuǎn)發(fā)。

　　圖中每個虛框是一個pod,，與傳統(tǒng)的服務(wù)相比,，我們的服務(wù)網(wǎng)格是通過sidecar方式進(jìn)行流量治理，比如熔斷,、限流,、超時重試、降低等,，把這些功能從每個服務(wù)中剝離出來形成一個代理,，通過這些代理實現(xiàn)服務(wù)間的治理,。這樣的好處是能夠讓每個服務(wù)只關(guān)注自己的業(yè)務(wù)邏輯，不需要管全局的調(diào)度和通訊問題,，讓開發(fā)更簡單,、高效。

　　當(dāng)然這種ServiceMesh無侵入性的模式帶來了很多便利,，但是實際上也帶來了很多挑戰(zhàn),。最大一個挑戰(zhàn)就是額外的性能開銷，所以我們做了大量的工作去解決服務(wù)網(wǎng)格的極致性能優(yōu)化,。這樣的一個優(yōu)化是多個層次的：

　　在網(wǎng)絡(luò)和內(nèi)核層面,，我們用共享內(nèi)存或者系統(tǒng)調(diào)用的方式來實現(xiàn)真正的zero copy。

　　也會在基礎(chǔ)庫,、組件架構(gòu)層面的優(yōu)化,，去除一些不必要的交互。甚至在編譯階段,，我們通過更好的全靜態(tài)的編譯,，不需要任何代碼的修改，就能夠獲得2%左右的性能提升,。

　　最終通過這種整體的,、多層次的組合優(yōu)化，我們既享受到了服務(wù)網(wǎng)格帶來的便利,，也保證了性能,。

　　移動端——極致體驗的移動APP研發(fā)

　　剛才講的是微服務(wù)框架和服務(wù)治理的內(nèi)容，接下來我們再來說一說移動開發(fā),。

　　對于字節(jié)來說,，可以算是一個移動原生的企業(yè)，我們絕大部分的業(yè)務(wù)也都是通過APP在承載的,。截止目前,，我們已經(jīng)運(yùn)營超過100款A(yù)PP，公司內(nèi)部也有數(shù)千人的移動應(yīng)用研發(fā)團(tuán)隊,。

　　要支撐如此大規(guī)模的研發(fā)團(tuán)隊和對應(yīng)業(yè)務(wù)的發(fā)展,，我們必須建立一套行業(yè)領(lǐng)先的移動應(yīng)用開發(fā)平臺，并且要通過大量的實踐和各種極端場景的打磨來不斷優(yōu)化,。因此我們很早就建立了公司級的移動研發(fā)平臺,，代號：MARS，通過它來統(tǒng)一支撐上層各個業(yè)務(wù)應(yīng)用的開發(fā)工作,。如今大家在用的抖音,、頭條等APP都是基于MARS進(jìn)行開發(fā)和迭代。

　　從層次角度,，MARS整體可以分為5個板塊：

　　首先是項目管理,，通過抽象字節(jié)內(nèi)部的研發(fā)特點(diǎn),，我們建立了統(tǒng)一的項目管理平臺用于支撐日常業(yè)務(wù)迭代管理，特別是發(fā)版等特殊流程的優(yōu)化,。

　　其次在應(yīng)用開發(fā)環(huán)節(jié),，這一步效率是很關(guān)鍵的，我們針對效率采用低代碼的方式來進(jìn)行進(jìn)一步的提升,。比如針對設(shè)計人員提供了通過設(shè)計直接生成代碼的方式,。對于運(yùn)營人員、研發(fā)人員,，我們采取了這種可見即可得的方式,，通過拖拉拽去幫助業(yè)務(wù)人員能更容易更便捷地構(gòu)建業(yè)務(wù)應(yīng)用。

　　然后面向傳統(tǒng)的編碼和研發(fā)階段,，我們面向APP,、前端以及小程序等不同的端都輸出了一套完整的端到端的開發(fā)平臺,。

　　另外在質(zhì)量管控,，我們也提供了一站式全鏈路測試平臺，基于海量真機(jī)真實模擬線上實際場景,，最大限度檢測潛在異常,。

　　最后是全鏈路監(jiān)控平臺，能夠覆蓋“終端-網(wǎng)絡(luò)-后臺應(yīng)用-基礎(chǔ)環(huán)境”的完整應(yīng)用鏈路監(jiān)控,，幫助研發(fā)人員精準(zhǔn)定位問題,，解決問題。

　　通過以上對微服務(wù),、移動開發(fā)平臺Mars的介紹,，我想大家對字節(jié)跳動敏捷開發(fā)應(yīng)該有了一個更生動的認(rèn)識。

　　回到今天分享的主題,，在整個字節(jié)技術(shù)發(fā)展的背后,，數(shù)據(jù)驅(qū)動和敏捷開發(fā)是兩個重要的理念，但這兩個理念并不是割裂的,，二者是一體的,。因為對于數(shù)據(jù)驅(qū)動而言，我們需要有更多的實驗,，來找到好的方案進(jìn)行推廣,，找到不好的點(diǎn)進(jìn)行改進(jìn)。而敏捷開發(fā)就能保證每天都有大量的實驗?zāi)軌蜻M(jìn)行,。反過來通過數(shù)據(jù)驅(qū)動,，我們又能夠去找到里面有價值的東西，同時也能沉淀更多的數(shù)據(jù),，這樣就構(gòu)建了整個業(yè)務(wù)高速發(fā)展的閉環(huán),。

　　這里也分享一些數(shù)據(jù),，在字節(jié)跳動內(nèi)部，我們每天新上的實驗有1500個,，實驗總量有80多萬個,，同時運(yùn)行的實驗有1萬多個，覆蓋了內(nèi)部500多個業(yè)務(wù)線以及各種各樣的場景,。包括個性化的場景,、推送的場景、建站的場景,、服務(wù)端的場景,、廣告營銷的場景等等。

　　而我們底層的技術(shù),、平臺的技術(shù),，還有業(yè)務(wù)層的技術(shù)，也正是因為這兩個理念在不斷的積累和迭代,，最終去推動業(yè)務(wù)的高速發(fā)展,。

　　其實道理非常簡單，就像大家說天下武功唯快不破一樣,，道理都是很簡單的道理,，但是要做好這些事情的背后，我們需要工具平臺和方法的不斷積累,，以及把這些方法形成日常的習(xí)慣,，最終形成業(yè)務(wù)推動的原動力。

　　以上就是我對字節(jié)跳動在數(shù)據(jù)驅(qū)動,、敏捷開發(fā)兩方面技術(shù)實踐的概括與分享,。希望對大家有所啟發(fā)。里面提到的很多技術(shù),，基本都在火山引擎上實現(xiàn)了對外產(chǎn)品化,，也非常期待大家能使用這些產(chǎn)品，反饋意見,，創(chuàng)造更大價值,。

　　謝謝大家！