火山引擎是企業(yè)的數(shù)字化增長(zhǎng)引擎
在開始分享之前,我先向大家介紹一下火山引擎。
火山引擎是字節(jié)跳動(dòng)旗下的企業(yè)級(jí)技術(shù)服務(wù)平臺(tái),,是字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)對(duì)外提供技術(shù)服務(wù)的統(tǒng)一窗口,,我們希望通過火山引擎,,把字節(jié)跳動(dòng)的技術(shù),、產(chǎn)品和服務(wù)對(duì)外開放,,包括云、AI,、大數(shù)據(jù),、推薦等等,來幫助不同行業(yè)中的企業(yè)實(shí)現(xiàn)自身增長(zhǎng)和數(shù)字化轉(zhuǎn)型,。
大家知道,,字節(jié)跳動(dòng)內(nèi)部一直在踐行技術(shù)中臺(tái)的技術(shù)文化。所以我們?cè)谧黾夹g(shù)ToB過程中,,也采取了這種機(jī)制,,讓技術(shù)中臺(tái)直接實(shí)現(xiàn)自身產(chǎn)品的商業(yè)化。因此,,火山引擎對(duì)外開放的技術(shù)和工具,,與字節(jié)跳動(dòng)技術(shù)中臺(tái)完全同源。比如說推薦,,用的就是今日頭條,、抖音的同款推薦平臺(tái)、工具和方法論,。通過這種方式,,我們可以把內(nèi)部最好的能力對(duì)外進(jìn)行服務(wù)。
這是火山引擎整體的產(chǎn)品技術(shù)體系,,一共分為四層,,分別是:統(tǒng)一基礎(chǔ)服務(wù)、技術(shù)中臺(tái),、智能應(yīng)用和行業(yè)解決方案,。這四層從下至上,分別滿足企業(yè)從運(yùn)維,、研發(fā),、產(chǎn)品、運(yùn)營(yíng)到營(yíng)銷,,在不同行業(yè),、不同業(yè)務(wù)場(chǎng)景下的需求。
這是過去一年里,,我們不斷把字節(jié)跳動(dòng)內(nèi)部技術(shù)商業(yè)化后形成的結(jié)果,,而在這個(gè)過程中我們一直在思考,字節(jié)跳動(dòng)是怎么一步一步發(fā)展至今的,,這背后支撐著業(yè)務(wù)快速發(fā)展的技術(shù)理念是什么,?今天我想和大家分享下我的理解,,我認(rèn)為在這個(gè)過程中,,有兩大理念非常重要,,分別是:數(shù)據(jù)驅(qū)動(dòng)、敏捷開發(fā),。
數(shù)據(jù)驅(qū)動(dòng):構(gòu)建數(shù)據(jù)驅(qū)動(dòng)的飛輪
首先和大家聊聊數(shù)據(jù)驅(qū)動(dòng),。亞馬遜有一個(gè)著名的飛輪理論:一個(gè)公司各個(gè)業(yè)務(wù)模塊之間應(yīng)當(dāng)有機(jī)地組合,相互推動(dòng),,就像是咬合的齒輪一樣,。每一個(gè)飛輪從靜止到轉(zhuǎn)動(dòng)起來需要花費(fèi)力氣,但是由于他們組合在一起,,所以每一圈的轉(zhuǎn)動(dòng)都不會(huì)白費(fèi),。一旦有一個(gè)齒輪轉(zhuǎn)動(dòng)起來,整個(gè)系統(tǒng)都會(huì)跟著轉(zhuǎn)動(dòng),,越轉(zhuǎn)越快,。
構(gòu)建數(shù)據(jù)驅(qū)動(dòng)的飛輪
回到數(shù)據(jù)驅(qū)動(dòng)這個(gè)話題,我們認(rèn)為同樣如此,。數(shù)據(jù)驅(qū)動(dòng)不是一蹴而就的,,不是用了一個(gè)工具,或者說建了幾張報(bào)表就做起來了,,而是在整個(gè)過程中,,不停地去解決一個(gè)個(gè)問題,最終形成多個(gè)體系,,讓他自動(dòng)轉(zhuǎn)起來,,形成數(shù)據(jù)的飛輪效應(yīng)。一旦飛輪效應(yīng)形成,,越到后面轉(zhuǎn)得越快,。數(shù)據(jù)驅(qū)動(dòng)就會(huì)成為日常內(nèi)部協(xié)同的習(xí)慣,最終成為業(yè)務(wù)增長(zhǎng)的源動(dòng)力,。
圍繞這一目標(biāo),,我們可以把建設(shè)飛輪分為四個(gè)關(guān)鍵步驟,業(yè)務(wù)過程數(shù)字化,、數(shù)字化協(xié)同,、數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)優(yōu)化、客觀的分析評(píng)估,。
這幾個(gè)步驟之間是一個(gè)有機(jī)推動(dòng)的過程:
業(yè)務(wù)過程的數(shù)字化是第一步,,也是非常關(guān)鍵的一步。業(yè)務(wù)過程的數(shù)字化越充分,,對(duì)業(yè)務(wù)的描述就越精準(zhǔn),,才能有利于后面步驟的展開。所以,,我們需要不斷地將離線活動(dòng)在線化,,在線活動(dòng)精細(xì)化,,全部通過數(shù)字化的方式進(jìn)行表達(dá)。
實(shí)現(xiàn)了業(yè)務(wù)過程的數(shù)字化之后,,第二步就是數(shù)字化協(xié)同,。第一要通過數(shù)據(jù)治理等手段讓底層數(shù)據(jù)得到規(guī)范、統(tǒng)一的表達(dá),。第二是要讓更多的人參與進(jìn)來,,所以需要通過數(shù)據(jù)可視化等工具讓不同的角色(開發(fā)人員、運(yùn)營(yíng)人員,、使用人員,、管理者等等)使用起來,加入數(shù)字化協(xié)同的過程,。
數(shù)字化協(xié)同能力,,最直接的影響是效率的提升。協(xié)同得越好,,就能越及時(shí),、全面地獲取業(yè)務(wù)的認(rèn)知,也就能在數(shù)據(jù)上更客觀地支持上層業(yè)務(wù)的優(yōu)化,。
優(yōu)化的效果一定不是拍腦袋,,也不是憑感覺,而是用客觀的分析評(píng)估,。一方面,,可以用A/B測(cè)試等方式通過數(shù)據(jù)來精準(zhǔn)評(píng)估業(yè)務(wù)帶來的實(shí)際收益,另一方面,,我們也要進(jìn)一步多維度的關(guān)聯(lián)原因,。
最后,走完這四步后,,在業(yè)務(wù)優(yōu)化和評(píng)估過程中,,我們又能沉淀更多的數(shù)據(jù),這就形成了閉環(huán),,實(shí)現(xiàn)了飛輪的轉(zhuǎn)動(dòng),。
剛剛是一個(gè)偏抽象的描述,下面我們?cè)俳Y(jié)合字節(jié)跳動(dòng)的具體情況來看:
業(yè)務(wù)過程數(shù)字化,,主要是對(duì)于不同觸點(diǎn)的數(shù)據(jù)埋點(diǎn),,比如APP、小程序,、運(yùn)營(yíng)頁等等,;
數(shù)字化協(xié)同,是多角色對(duì)數(shù)據(jù)應(yīng)用的協(xié)同加工,。比如研發(fā)如何做好數(shù)據(jù)開發(fā),、數(shù)據(jù)治理,,運(yùn)營(yíng)更好更快的用好數(shù)據(jù)等;
數(shù)字驅(qū)動(dòng)業(yè)務(wù)優(yōu)化,,主要是根據(jù)數(shù)據(jù),根據(jù)數(shù)據(jù)產(chǎn)生的insights,,對(duì)產(chǎn)品,、算法進(jìn)行優(yōu)化,比如對(duì)推薦系統(tǒng)策略的優(yōu)化,,面向不同用戶群體運(yùn)營(yíng)的優(yōu)化等,;
客觀的分析評(píng)估,一方面通過A/B測(cè)試,,對(duì)不同的,、新的迭代進(jìn)行客觀評(píng)估,另一方面則是通過ABI進(jìn)一步地進(jìn)行數(shù)據(jù)洞察,,能夠積累對(duì)于的insights,,從而促進(jìn)整個(gè)流程的轉(zhuǎn)動(dòng)。
這就是字節(jié)跳動(dòng)構(gòu)建整個(gè)數(shù)據(jù)驅(qū)動(dòng)飛輪的過程,,在這個(gè)過程中,,我們把“業(yè)務(wù)過程數(shù)字化”、“數(shù)字化協(xié)同”,、“客觀的分析評(píng)估”這三個(gè)沉淀下來,,固化成數(shù)據(jù)中臺(tái)統(tǒng)一的能力,去支持不同應(yīng)用的數(shù)據(jù)優(yōu)化,,同時(shí)中臺(tái)能力,,還能對(duì)業(yè)務(wù)不同維度,包括增長(zhǎng),、體驗(yàn),、變現(xiàn)等等實(shí)現(xiàn)進(jìn)一步的優(yōu)化。
下面我們就數(shù)據(jù)中臺(tái)和應(yīng)用優(yōu)化,,進(jìn)行展開,。
面向應(yīng)用的數(shù)據(jù)中臺(tái)
剛才其實(shí)也提到了數(shù)據(jù)中臺(tái),它最大的一個(gè)作用是幫助各個(gè)應(yīng)用,、業(yè)務(wù)基于數(shù)據(jù)驅(qū)動(dòng)進(jìn)行優(yōu)化,。所以做數(shù)據(jù)中臺(tái)有一個(gè)很重要的理念,那就是一定要面向應(yīng)用來構(gòu)建,。從數(shù)據(jù)開始,,用數(shù)據(jù)來做驗(yàn)證。那么談到數(shù)據(jù)的驗(yàn)證,,那最重要的其實(shí)就是A/B測(cè)試,。之前我們也在不同場(chǎng)合強(qiáng)調(diào)過字節(jié)對(duì)于A/B測(cè)試的重視,,包括抖音、頭條的起名也是通過A/B測(cè)試得來的,。
對(duì)于評(píng)估而言,,測(cè)試只是第一步,我們還需要進(jìn)一步對(duì)結(jié)果進(jìn)行分析,,因此構(gòu)建了相應(yīng)的數(shù)據(jù)運(yùn)營(yíng)平臺(tái),、智能數(shù)據(jù)洞察和客戶數(shù)據(jù)平臺(tái)等工具,幫助產(chǎn)品和運(yùn)營(yíng)可以深入分析數(shù)據(jù),。
而在底層,,面向每天產(chǎn)生的大規(guī)模、批量,、實(shí)時(shí)的數(shù)據(jù),,我們也建設(shè)了一套完整的數(shù)據(jù)采集、研發(fā)和治理的套件,,提升數(shù)據(jù)開發(fā)的效率,。
所以可以說在底層,我們更關(guān)注數(shù)據(jù)開發(fā)的效率和規(guī)模,,而在上層,,我們關(guān)注的是整個(gè)產(chǎn)品和運(yùn)營(yíng)在做數(shù)據(jù)分析過程中的易用性、可交互性,。要實(shí)現(xiàn)易用性,、可交互性和底層規(guī)模和效率的一個(gè)連接,我們需要一個(gè)非常強(qiáng)大的數(shù)據(jù)分析引擎,,那就是我們的ByteHouse,。
ByteHouse起源于開源的clickhouse項(xiàng)目,所以有了House的后綴,。但它其實(shí)是根據(jù)字節(jié)跳動(dòng)大規(guī)模數(shù)據(jù)場(chǎng)景,,進(jìn)行了非常多的需求改造,最終形成的一個(gè)云原生的大規(guī)模數(shù)據(jù)分析平臺(tái),。
剛剛提到,,數(shù)據(jù)驅(qū)動(dòng)是字節(jié)跳動(dòng)的重要技術(shù)理念,每天我們有數(shù)十PB的新增數(shù)據(jù),,有數(shù)萬多人要從各種維度各種細(xì)節(jié),,對(duì)這些數(shù)據(jù)進(jìn)行分析。這里面就有很多性能問題,、實(shí)時(shí)問題需要解決,,背后就是靠ByteHouse支持的。
目前為止,ByteHouse幾乎服務(wù)于字節(jié)內(nèi)所有的業(yè)務(wù)線,,也是ABI系統(tǒng),、UBA系統(tǒng)、畫像系統(tǒng),、A/B測(cè)試等分析系統(tǒng)的核心引擎,。整體規(guī)模達(dá)到了三萬臺(tái)服務(wù)器,每天查詢有幾千萬次,。
面對(duì)剛才說的大規(guī)模挑戰(zhàn),,我們?cè)贐yteHouse上主要做了五個(gè)層次的深度改造:
第一是支持流式數(shù)據(jù)。對(duì)分析而言,,我們對(duì)實(shí)時(shí)性的要求非常高,,所以我們通過Kafka支持了對(duì)實(shí)時(shí)數(shù)據(jù)的處理,。這樣通過ByteHouse可以實(shí)現(xiàn)對(duì)實(shí)時(shí)和離線的數(shù)據(jù)提供統(tǒng)一的分析平臺(tái),,支持批流一體。
第二是計(jì)算和存儲(chǔ)的分離,。因?yàn)槲覀兊囊?guī)模實(shí)在太大了,,如何在數(shù)十PB新增數(shù)據(jù)基礎(chǔ)上,支持?jǐn)?shù)萬人,,高效快速地做千萬次的即時(shí)查詢,,是一個(gè)很大的挑戰(zhàn)。通過計(jì)算和存儲(chǔ)的分離,,我們能更好地解決性能問題,。分離之后,計(jì)算層可以單獨(dú)地進(jìn)行彈性的擴(kuò)縮容,。在存儲(chǔ)一塊,,可以和分布式存儲(chǔ)系統(tǒng)進(jìn)行對(duì)接,包括HDFS,、S3等等,。這樣一方面能解決存儲(chǔ)的穩(wěn)定性問題,另一方面也能解決擴(kuò)容問題,。
在計(jì)算和存儲(chǔ)的分離之外,,我們?cè)谶\(yùn)維、安全方面做了很多工作,,以進(jìn)一步去彌補(bǔ)社區(qū)版本功能的缺失,。
最后一個(gè)很重要的是我們做了多級(jí)的資源隔離。因?yàn)槊刻煊胁煌牟块T,、角色在做各種各樣的分析,,那么權(quán)限、時(shí)效性的要求都不一樣。那么通過租戶的隔離,、讀寫的分離以及異構(gòu)的計(jì)算資源,,就能很好地滿足不同部門、不同角色在大規(guī)模集中式地使用資源分配的問題,。
通過以上這五個(gè)大的層次上優(yōu)化,,所以我們能夠基于ByteHouse去支撐起整個(gè)字節(jié)跳動(dòng)數(shù)據(jù)驅(qū)動(dòng)里的核心步驟。
剛才講了數(shù)據(jù)中臺(tái)的一些實(shí)踐,,接下來再講講怎么去通過數(shù)據(jù)驅(qū)動(dòng)來做應(yīng)用和業(yè)務(wù)的優(yōu)化,。這里以增長(zhǎng)獲客來舉例。
當(dāng)然不管是增長(zhǎng)場(chǎng)景還是其他場(chǎng)景,,如果要做好數(shù)據(jù)驅(qū)動(dòng)優(yōu)化,,首先最關(guān)鍵的就是設(shè)計(jì)好指標(biāo)體系。因?yàn)橹笜?biāo)不對(duì),,做的再多都是錯(cuò)的,。
那么對(duì)于增長(zhǎng)而言,我們認(rèn)為最重要的有兩個(gè)指標(biāo)——「正向的投入產(chǎn)出」和「健康的用戶規(guī)?!?。
正向的投入產(chǎn)出,簡(jiǎn)單來說就是ROI>1,??雌饋矸浅:?jiǎn)單,但怎么把ROI算對(duì),、算準(zhǔn)以及精細(xì)到每個(gè)用戶粒度跟進(jìn)長(zhǎng)期的 ROI,,其實(shí)是難點(diǎn)和關(guān)鍵。
當(dāng)然我們也不能只看短期的ROI,,還要看長(zhǎng)期的用戶的健康度,,包括留存,LT等等,。
設(shè)定了這些關(guān)鍵指標(biāo)之后,,其實(shí)就可以通過指標(biāo)去找到對(duì)應(yīng)的優(yōu)化增長(zhǎng)策略。這個(gè)增長(zhǎng)策略不僅要滿足指標(biāo)的正向,,同時(shí)也要具備可持續(xù),、可規(guī)模化,、可復(fù)制的模式,。這樣就把業(yè)務(wù)的增長(zhǎng)模式轉(zhuǎn)化成了可衡量、可跟蹤的數(shù)據(jù)驅(qū)動(dòng)模式,。
最后用一張圖去完整地闡述數(shù)據(jù)驅(qū)動(dòng),、基于中臺(tái)和應(yīng)用優(yōu)化,來構(gòu)建整體飛輪的案例。
首先基于數(shù)據(jù)做用戶定向,,定義好目標(biāo),,找到對(duì)產(chǎn)品最關(guān)鍵的人群;
找到之后,,去做對(duì)應(yīng)的創(chuàng)意,、內(nèi)容,然后讓這些最優(yōu)質(zhì)最吸引的內(nèi)容在不同渠道觸達(dá)到客戶,,形成轉(zhuǎn)換并產(chǎn)生新的數(shù)據(jù),。而且我們有數(shù)字化記錄的過程,能夠準(zhǔn)確地歸因,,精細(xì)化地追蹤效果,;
在優(yōu)化過程中,會(huì)有很多創(chuàng)意,。我們通過A/B測(cè)試高速迭代,,看看哪個(gè)創(chuàng)意更合適。而在評(píng)估的過程中,,也會(huì)出現(xiàn)更多的數(shù)據(jù),,從而又補(bǔ)充了整個(gè)策略方案,,最終就形成一個(gè)數(shù)據(jù)驅(qū)動(dòng)的增長(zhǎng)飛輪,。
在這樣的過程里面,實(shí)驗(yàn)的速度是非常關(guān)鍵的,。如果別人一天只能做10個(gè)實(shí)驗(yàn),,你能做100個(gè),那結(jié)果不言而喻,。小到創(chuàng)意的實(shí)驗(yàn),,大到APP功能的迭代開發(fā),速度在里面都起到非常大的作用,。而這就呼應(yīng)了我想講的第二個(gè)理念,,敏捷開發(fā)。
敏捷開發(fā):全棧云原生架構(gòu)支撐大規(guī)模應(yīng)用
說到敏捷開發(fā),,我們可以看到市面各種各樣不同層次的解決方案,,比如說低代碼,aPaaS等等,。不過今天主要想和大家聊的還是云原生這塊,,因?yàn)闊o論是SaaS層還是PaaS層的方案,在底層都離不開一整套云原生架構(gòu)的支持,。
字節(jié)跳動(dòng)全棧云原生化架構(gòu)
這里也簡(jiǎn)單回顧下云基礎(chǔ)技術(shù)的發(fā)展歷史,,相信很多人也比較熟悉這段軌跡了。可以看到,,13年是一個(gè)重要的拐點(diǎn),。13年之后,隨著Docker,、K8s等技術(shù)的興起和普及,,云從以基礎(chǔ)設(shè)施為中心,走向以應(yīng)用為中心,;從資源服務(wù)化走向平臺(tái)服務(wù)化,,而字節(jié)跳動(dòng)剛好誕生在2012年,因此非常幸運(yùn)沒有什么歷史包袱,,直接擁抱了最新的云原生技術(shù),。
給大家分享一組數(shù)字(2021年2月份統(tǒng)計(jì)):字節(jié)跳動(dòng)內(nèi)部業(yè)務(wù)中,服務(wù)器的節(jié)點(diǎn)數(shù)近百萬,;同時(shí)在線的微服務(wù)數(shù)有8w+,,并且在以每月2000的數(shù)量增長(zhǎng);容器數(shù)750w+,;每日新增量60多PB,。
從這些數(shù)字大家也可以看得出,我們面臨的是一個(gè)非常大規(guī)模的,,而且還在不斷快速上漲的服務(wù)體量的挑戰(zhàn),。所以從基礎(chǔ)架構(gòu)的視角,我們認(rèn)為有三個(gè)方面的問題需要考慮:
第一是如何支撐海量服務(wù),。隨著應(yīng)用微服務(wù)化,,治理對(duì)象由單體應(yīng)用轉(zhuǎn)變?yōu)閿?shù)量更龐大的微服務(wù),這導(dǎo)致全局治理難度更加大,,包括構(gòu)建全局的配置中心以及更靈活的全局網(wǎng)絡(luò),、運(yùn)行時(shí)的選擇、配備完善的安全機(jī)制,,以及如何端到端的和整個(gè)DevOps流程進(jìn)行打通,。
第二是在大規(guī)模調(diào)度運(yùn)維下的挑戰(zhàn),如何讓基礎(chǔ)設(shè)施更加穩(wěn)定,。目前內(nèi)部平均單集群規(guī)模是5000多節(jié)點(diǎn),,大的集群有數(shù)萬臺(tái)。在這么大體量的情況下,,需要考慮各種各樣的問題,,比如在大規(guī)模鏡像分發(fā)的場(chǎng)景下,怎么做鏡像預(yù)熱,、多集群的聯(lián)邦管理的問題,;在弱網(wǎng)環(huán)境下,,云邊協(xié)同的問題;在異構(gòu)的環(huán)境下,,機(jī)器學(xué)習(xí)的場(chǎng)景里面的GPU調(diào)度問題,。
第三,是在線/離線的混部,。因?yàn)檫@么大的規(guī)模,,成本自然也很大,所以我們要做好利用率的提升,。在線/離線的混部是非常重要的手段,。特別是字節(jié)跳動(dòng)業(yè)務(wù)本身,其實(shí)波峰和波谷都很明顯,。比如抖音高的峰值就在晚上,,其他時(shí)候的QPS就沒有這么高。所以我們?cè)O(shè)計(jì)了一套在線/離線混部的機(jī)制,,一方面可以降低成本,,一方面能夠更好地應(yīng)對(duì)極端情況下業(yè)務(wù)規(guī)模增長(zhǎng)的難題。
同時(shí),,在底層,,我們還構(gòu)建了一個(gè)容器+多云的整體解決方案。
在多云方面,,我們不僅計(jì)算能夠做到多云,,有狀態(tài)的存儲(chǔ)也能夠做到多云,這樣我們就能夠非常靈活的去應(yīng)對(duì)各種的突發(fā)情況,,比如年初的春晚搶紅包,,以及818新潮購物節(jié)等等,。
這張圖從架構(gòu)體系角度,,進(jìn)一步來闡釋全棧云原生的體系結(jié)構(gòu)。
首先在最底層,,是一套完整的云原生基礎(chǔ)設(shè)施,。通過統(tǒng)一的底層去提供新一代的高性能計(jì)算存儲(chǔ)和網(wǎng)絡(luò)的解決方案,這其實(shí)是保證業(yè)務(wù)穩(wěn)定和敏捷的基石,。
在云原生基礎(chǔ)之上是服務(wù)平臺(tái)層,,它要解決的是業(yè)務(wù)開發(fā)中的一些通用平臺(tái)和服務(wù)能力的抽象。這里面包含了高性能的微服務(wù)框架,、基于服務(wù)網(wǎng)格的微服務(wù)治理能力,,以及Serverless、邊緣計(jì)算平臺(tái)的能力,。服務(wù)平臺(tái)構(gòu)建就是為了讓開發(fā)人員更敏捷,、專注地開發(fā)業(yè)務(wù)邏輯,,而能更少地考慮資源、平臺(tái),、服務(wù)間通信和治理,。
在平臺(tái)層之上是整個(gè)研發(fā)體系的構(gòu)建。這一層我們是希望通過各種各樣的工具,、流程機(jī)制和組織,,能夠去幫字節(jié)跳動(dòng)靈活地支撐全部業(yè)務(wù)線的快速開發(fā)和開發(fā)管理工作。
這中間三層設(shè)施的兩邊是重要的云原生安全體系和SRE服務(wù)支撐體系,。
第一個(gè)是云原生安全的體系,。那么相比傳統(tǒng)的安全體系,它要做到不同層次的延伸,,一個(gè)是左延,,不僅關(guān)注運(yùn)行時(shí)的安全,我們也需要和DevOps的流程結(jié)合在一起,,去關(guān)注應(yīng)用整個(gè)生命周期的安全,。第二個(gè)就是下延,不僅只關(guān)注到容器的安全,,還要關(guān)注到主機(jī)的安全,。
第二個(gè)就是SRE體系,它來支撐整個(gè)業(yè)務(wù)高速發(fā)展過程中的穩(wěn)定性,。
因?yàn)闀r(shí)間有限,,我挑了兩個(gè)比較有意思的話題來進(jìn)一步的分享。一個(gè)是微服務(wù),,一個(gè)是移動(dòng)開發(fā),。一方面比較有代表性,另一方面這兩者覆蓋了大部分業(yè)務(wù)研發(fā)的場(chǎng)景,。
服務(wù)器端——微服務(wù),、服務(wù)治理與DevOps
首先來看微服務(wù)。我們可以用四個(gè)點(diǎn)來形容字節(jié)跳動(dòng)微服務(wù)的現(xiàn)狀:
規(guī)模龐大且增長(zhǎng)迅速,。剛才介紹過字節(jié)跳動(dòng)現(xiàn)在的微服務(wù)數(shù)是8萬,,但在2018年,整個(gè)微服務(wù)數(shù)大概只有7000到8000,,所以三年其實(shí)翻了近10倍,,并且還在不斷的增長(zhǎng)。在這個(gè)過程中,,我們自然遇到了非常多的挑戰(zhàn),。
在線微服務(wù)超過90%都運(yùn)行在容器里。對(duì)于業(yè)務(wù)線,,是看不到資源的,,看到的只是PaaS,、容器。這帶來很多便利性,,有利于新技術(shù)的核心功能推廣,,但同時(shí)也有很多挑戰(zhàn),尤其是調(diào)度復(fù)雜性這方面,。
技術(shù)體系以Golang語言為主,。根據(jù)最新的調(diào)查統(tǒng)計(jì),字節(jié)跳動(dòng)內(nèi)部Golang是主要語言,,超過55%的服務(wù)都采用了Golang,,排名第二的語言是NodeJS,然后是其他的語言,。
Service Mesh的全面落地和應(yīng)用,。字節(jié)跳動(dòng)是國(guó)內(nèi)最早在生產(chǎn)環(huán)節(jié)大規(guī)模使用Service Mesh的公司之一。
大家可以發(fā)現(xiàn)整個(gè)字節(jié)跳動(dòng)在微服務(wù)的使用上是非??斓?,甚至可以說是比較激進(jìn)的。這背后,,是因?yàn)樵谧止?jié)跳動(dòng),,速度和效率是我們研發(fā)要解決的Top1問題。每天新應(yīng)用和新用戶增長(zhǎng)都非???,研發(fā)必須要解決好產(chǎn)能問題。這也是我們激進(jìn)地采取微服務(wù)架構(gòu)的原因,。但這么大的規(guī)模下,,做這么快的迭代,自然會(huì)對(duì)穩(wěn)定性,、信任帶來非常大的沖擊,。
為了應(yīng)對(duì)這些困難和矛盾,我們?cè)诙说蕉寺涞匚⒎?wù)架構(gòu)時(shí),,針對(duì)性地做了各項(xiàng)優(yōu)化:
首先是語言層面,,Golang是主力使用的語言,因此在Golang層面做了很多框架層面的優(yōu)化,,比如RPC框架、HTTP框架,。這些框架我們已經(jīng)通過開源的方式回饋到社區(qū)——9月初,,字節(jié)跳動(dòng)開源CloudWeGo,幫助更多開發(fā)者搭建云原生微服務(wù)架構(gòu),。
第二則是針對(duì)海量服務(wù)的治理,,我們基于ServiceMesh的概念構(gòu)建了自己的服務(wù)網(wǎng)格體系,,將服務(wù)治理的能力固化到字節(jié)內(nèi)部平臺(tái)上,一方面幫助我們多元多服務(wù)的兼容問題,,另一方面通過Golang穩(wěn)定的框架和以Mesh治理為基礎(chǔ)的理念,,我們實(shí)現(xiàn)了全局流量的治理、單元化和體系化的整體建設(shè),。
最后是通過落地和實(shí)踐DevOps工具和方法來提升研發(fā)的效率,,進(jìn)一步提升運(yùn)維的可觀測(cè)性。
下面我們就一個(gè)個(gè)展開,。
首先是Golang框架這塊,,一個(gè)是Kitex,這是RPC的框架,。另一個(gè)是Hertz,,是HTTP的框架。這些框架背后集成了我們自研的高性能的網(wǎng)絡(luò)庫,,去解決網(wǎng)絡(luò)上的一些性能,、交互上的問題。同時(shí)我們支持多消息協(xié)議(Thrift/Protobuf)和多交互方式(Ping-Pong/Oneway/Streaming),,能提供更加靈活自主的代碼生成器,。
這是Kitex和gRPC性能的對(duì)比,我們選了兩組,,分別是基于Thrift和Protobuf協(xié)議的對(duì)比,。可以看到在兩種方式下,,Kitex都有比較好的性能表現(xiàn),。特別是在在TP99延遲上,隨著并發(fā)連接數(shù)的增大,,Kitex表現(xiàn)出的優(yōu)勢(shì)是越來越大,。
這是Hertz和業(yè)界一些框架的對(duì)比,包括平均時(shí)延,、QPS,,以及在不同Size包的情況下的對(duì)比結(jié)果。這兩個(gè)框架我們現(xiàn)在都通過開源的方式在對(duì)外提供,,所以歡迎各位開發(fā)者去下載使用,,和我們交流,提供意見,。
接下來我們看服務(wù)網(wǎng)格的治理,。剛才談到過因?yàn)楸旧淼臉I(yè)務(wù)類型、業(yè)務(wù)體量,,所以我們?cè)趯?shí)踐微服務(wù)的架構(gòu)中,,面臨著非常多挑戰(zhàn),,比如語言碎片化、服務(wù)異構(gòu),、協(xié)議異構(gòu),,還有安全、可觀測(cè)性,、問題追查調(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)性能問題時(shí),就不會(huì)影響到控制平面的路由策略,;反過來也是,,當(dāng)控制平面策略負(fù)載過重時(shí)也不會(huì)影響數(shù)據(jù)平面的轉(zhuǎn)發(fā)。
圖中每個(gè)虛框是一個(gè)pod,,與傳統(tǒng)的服務(wù)相比,,我們的服務(wù)網(wǎng)格是通過sidecar方式進(jìn)行流量治理,比如熔斷,、限流,、超時(shí)重試、降低等,,把這些功能從每個(gè)服務(wù)中剝離出來形成一個(gè)代理,,通過這些代理實(shí)現(xiàn)服務(wù)間的治理。這樣的好處是能夠讓每個(gè)服務(wù)只關(guān)注自己的業(yè)務(wù)邏輯,,不需要管全局的調(diào)度和通訊問題,,讓開發(fā)更簡(jiǎn)單、高效,。
當(dāng)然這種ServiceMesh無侵入性的模式帶來了很多便利,,但是實(shí)際上也帶來了很多挑戰(zhàn)。最大一個(gè)挑戰(zhàn)就是額外的性能開銷,,所以我們做了大量的工作去解決服務(wù)網(wǎng)格的極致性能優(yōu)化,。這樣的一個(gè)優(yōu)化是多個(gè)層次的:
在網(wǎng)絡(luò)和內(nèi)核層面,我們用共享內(nèi)存或者系統(tǒng)調(diào)用的方式來實(shí)現(xiàn)真正的zero copy,。
也會(huì)在基礎(chǔ)庫,、組件架構(gòu)層面的優(yōu)化,去除一些不必要的交互,。甚至在編譯階段,,我們通過更好的全靜態(tài)的編譯,不需要任何代碼的修改,,就能夠獲得2%左右的性能提升,。
最終通過這種整體的、多層次的組合優(yōu)化,,我們既享受到了服務(wù)網(wǎng)格帶來的便利,,也保證了性能。
移動(dòng)端——極致體驗(yàn)的移動(dòng)APP研發(fā)
剛才講的是微服務(wù)框架和服務(wù)治理的內(nèi)容,,接下來我們?cè)賮碚f一說移動(dòng)開發(fā),。
對(duì)于字節(jié)來說,可以算是一個(gè)移動(dòng)原生的企業(yè),,我們絕大部分的業(yè)務(wù)也都是通過APP在承載的,。截止目前,我們已經(jīng)運(yùn)營(yíng)超過100款A(yù)PP,,公司內(nèi)部也有數(shù)千人的移動(dòng)應(yīng)用研發(fā)團(tuán)隊(duì),。
要支撐如此大規(guī)模的研發(fā)團(tuán)隊(duì)和對(duì)應(yīng)業(yè)務(wù)的發(fā)展,我們必須建立一套行業(yè)領(lǐng)先的移動(dòng)應(yīng)用開發(fā)平臺(tái),,并且要通過大量的實(shí)踐和各種極端場(chǎng)景的打磨來不斷優(yōu)化,。因此我們很早就建立了公司級(jí)的移動(dòng)研發(fā)平臺(tái),代號(hào):MARS,,通過它來統(tǒng)一支撐上層各個(gè)業(yè)務(wù)應(yīng)用的開發(fā)工作,。如今大家在用的抖音、頭條等APP都是基于MARS進(jìn)行開發(fā)和迭代,。
從層次角度,,MARS整體可以分為5個(gè)板塊:
首先是項(xiàng)目管理,通過抽象字節(jié)內(nèi)部的研發(fā)特點(diǎn),,我們建立了統(tǒng)一的項(xiàng)目管理平臺(tái)用于支撐日常業(yè)務(wù)迭代管理,,特別是發(fā)版等特殊流程的優(yōu)化。
其次在應(yīng)用開發(fā)環(huán)節(jié),,這一步效率是很關(guān)鍵的,,我們針對(duì)效率采用低代碼的方式來進(jìn)行進(jìn)一步的提升。比如針對(duì)設(shè)計(jì)人員提供了通過設(shè)計(jì)直接生成代碼的方式,。對(duì)于運(yùn)營(yíng)人員,、研發(fā)人員,我們采取了這種可見即可得的方式,,通過拖拉拽去幫助業(yè)務(wù)人員能更容易更便捷地構(gòu)建業(yè)務(wù)應(yīng)用,。
然后面向傳統(tǒng)的編碼和研發(fā)階段,我們面向APP、前端以及小程序等不同的端都輸出了一套完整的端到端的開發(fā)平臺(tái),。
另外在質(zhì)量管控,,我們也提供了一站式全鏈路測(cè)試平臺(tái),基于海量真機(jī)真實(shí)模擬線上實(shí)際場(chǎng)景,,最大限度檢測(cè)潛在異常,。
最后是全鏈路監(jiān)控平臺(tái),能夠覆蓋“終端-網(wǎng)絡(luò)-后臺(tái)應(yīng)用-基礎(chǔ)環(huán)境”的完整應(yīng)用鏈路監(jiān)控,,幫助研發(fā)人員精準(zhǔn)定位問題,,解決問題。
通過以上對(duì)微服務(wù),、移動(dòng)開發(fā)平臺(tái)Mars的介紹,,我想大家對(duì)字節(jié)跳動(dòng)敏捷開發(fā)應(yīng)該有了一個(gè)更生動(dòng)的認(rèn)識(shí)。
回到今天分享的主題,,在整個(gè)字節(jié)技術(shù)發(fā)展的背后,,數(shù)據(jù)驅(qū)動(dòng)和敏捷開發(fā)是兩個(gè)重要的理念,但這兩個(gè)理念并不是割裂的,,二者是一體的,。因?yàn)閷?duì)于數(shù)據(jù)驅(qū)動(dòng)而言,我們需要有更多的實(shí)驗(yàn),,來找到好的方案進(jìn)行推廣,,找到不好的點(diǎn)進(jìn)行改進(jìn)。而敏捷開發(fā)就能保證每天都有大量的實(shí)驗(yàn)?zāi)軌蜻M(jìn)行,。反過來通過數(shù)據(jù)驅(qū)動(dòng),,我們又能夠去找到里面有價(jià)值的東西,同時(shí)也能沉淀更多的數(shù)據(jù),,這樣就構(gòu)建了整個(gè)業(yè)務(wù)高速發(fā)展的閉環(huán),。
這里也分享一些數(shù)據(jù),在字節(jié)跳動(dòng)內(nèi)部,,我們每天新上的實(shí)驗(yàn)有1500個(gè),,實(shí)驗(yàn)總量有80多萬個(gè),同時(shí)運(yùn)行的實(shí)驗(yàn)有1萬多個(gè),,覆蓋了內(nèi)部500多個(gè)業(yè)務(wù)線以及各種各樣的場(chǎng)景,。包括個(gè)性化的場(chǎng)景、推送的場(chǎng)景,、建站的場(chǎng)景,、服務(wù)端的場(chǎng)景、廣告營(yíng)銷的場(chǎng)景等等,。
而我們底層的技術(shù),、平臺(tái)的技術(shù),,還有業(yè)務(wù)層的技術(shù),也正是因?yàn)檫@兩個(gè)理念在不斷的積累和迭代,,最終去推動(dòng)業(yè)務(wù)的高速發(fā)展,。
其實(shí)道理非常簡(jiǎn)單,就像大家說天下武功唯快不破一樣,,道理都是很簡(jiǎn)單的道理,,但是要做好這些事情的背后,,我們需要工具平臺(tái)和方法的不斷積累,,以及把這些方法形成日常的習(xí)慣,最終形成業(yè)務(wù)推動(dòng)的原動(dòng)力,。
以上就是我對(duì)字節(jié)跳動(dòng)在數(shù)據(jù)驅(qū)動(dòng),、敏捷開發(fā)兩方面技術(shù)實(shí)踐的概括與分享。希望對(duì)大家有所啟發(fā),。里面提到的很多技術(shù),,基本都在火山引擎上實(shí)現(xiàn)了對(duì)外產(chǎn)品化,也非常期待大家能使用這些產(chǎn)品,,反饋意見,,創(chuàng)造更大價(jià)值。
謝謝大家,!